As to why I left, it’s difficult to answer: Just about anything I could say that would be accurate and honest would do more harm than good.

http://nighthacks.com/roller/jag/entry/time_to_move_on.

Oracle versucht, den Namen “Sun” an jeder möglichen Stelle zu ersetzen. Ab 1. September wird beispielsweise die SCJP-Zertifizierung (“Sun Certified Java Programmer”) in “Oracle Certified Professional, Java SE 6 Programmer” umbenannt. Der Namenswechsel wird auch in den Produkten selbst vorangetrieben: So gibt das Vendor-Property seit der JVM 1.6.0_21 anstelle von Sun Microsystems, Inc einfach Oracle zurück. Diese scheinbar kleine Änderung hatte für “Eclipse Helios”-Anwender OutOfMemory-Abstürze zur Folge.

Auch die technische Migration der Sun-Webseiten in die Oracle-Welt erfolgte nicht ganz reibungslos. Insbesondere gab es Unmut über geänderte JavaDoc-URLs, die unschöne Implementierungsdetails enthielten. Oracle hat jedoch schnell reagiert und die Korrekturen schnell implementiert.

Spannend ist auch die aktuell eingereichte Klage von Oracle gegen Google. Oracle wirft Google vor, Patente bei der Entwicklung von Android verletzt zu haben. Dies hat nun die Konsequenz dass Google Oracle’s Entwicklerkonferenz “Java One” boykottiert.

Insgesamt hat Oracle in diesem Jahr für (zu)viel Aufregung gesorgt und die Java-Community verunsichert. Mit Spannung wird die Keynote der Java One erwartet, in der sich Oracle’s CEO Larry Ellison zu der Zukunft von Java äußern möchte.

Wie sich herausstellte, zeigt URLEncodedPostData ein ungewöhnliches (allerdings dokumentiertes) Verhalten bei Zeilenumbrüchen. Ein linefeed (\n) wird nicht zu %0A encodiert, sondern zu %0D%0A (entspricht \r\n). Somit verhält sich die RIM-Klasse anders als der java.net.URLEncoder der Java-SE.

Als Resultat konnten Byte-Arrays, die zufälligerweise ein linefeed enthielten, nicht mehr vom Server entschlüsselt werden. Da sich dieses Verhalten nicht beeinflussen lässt, musste eine alternative URLEncoder-Klasse in das Projekt integriert werden.

Mit “jmap -dump:file=mydump” wird ein Snapshot des gesamten Java Heaps erzeugt und in einem binären Format ins aktuelle Verzeichnis abgelegt. Dieser Dump ist das Ausgangsmaterial für jhat. Ein kleiner Hinweis für die Mac-Nutzer: Unter Mac OSX funktioniert dies leider nicht. Hier muss man den Dump mit der HotSpotDiagnosticMXBean innerhalb der JConsole erzeugen.

Mit “jhat mydump” wird ein HTTP-Server gestartet, der die im Dump enthaltenen Klassen und Instanzen präsentiert. Über die Abfragesprache OQL (Object Query Language) kann der Dump auch durchsucht werden. Beispielsweise werden mit “select s from java.lang.String s where s.count >= 500” alle Strings aufgelistet, die länger als 500 Zeichen sind.

Praktisch.

Beim iPhone OS ist das Prinzip identisch: Nur der Main-Thread darf UIKit-Komponenten verändern. Hier gibt es ebenfalls eine einfache Methode (performSelectorOnMainThread) um Code auf dem Main-Thread auszuführen:

Mit dieser Zeile wird der Main-Thread veranlasst, die Methode “parserDidParse” des “delegate”-Objekts ohne Parameter aufzurufen.

An diesem Beispiel sieht man wieder, wie stark sich die Konzepte von Blackberry und dem iPhone OS ähneln.

Wird ein Screen geschlossen, wird wieder der darunterlegende Screen dargestellt. Dieses Verhalten entspricht im Übrigen genau dem UINavigationController des iPhone SDKs.

Beim “Pushen” des Screens werden dem Screen diejenigen Objekte übergeben, die er darstellen und verarbeiten muss. Hier ist beim Software-Design zu beachten, dass der Screen nicht das komplette ganze Modell kennt, sondern immer nur den spezifischen Modell-Abschnitt, den er darstellen muss. So wird eine enge Verzahnung der Screens vermieden und ein höherer Wartungs- und Wiederverwendungsgrad erreicht.

Wenn der oberste Screen Änderungen an darunterliegende Screens kommunizieren muss, so sollte dies über ein Interface geschehen, um weiterhin eine lose Koppelung der Screens sicherzustellen. Das nachfolgende vereinfachte Beispiel zeigt dieses Pattern anhand einer vereinfachten Mailapplikation.

1. Mit Klick auf “Posteingang” wird ein ListScreen erzeugt und auf den Stack “gepushed”
   Auf dem Stack liegen nun zwei Screens (IndexScreen und ListScreen). Der ListScreen hält eine Referenz auf einen Vector mit allen Emails.
2. Beim Klick auf eine Email in der Liste wird eine Instanz des DetailScreens erzeugt und auf den Stack gepushed. Diese Instanz erhält eine Referenz auf das darzustellende E-Mail Objekt und den ListScreen über das Interface “DetailScreenListener”.
3. Über genau dieses Interface teilt der Detailscreen dem ListScreen mit, wenn der User auf “Löschen” geklickt hat, damit dieser aus der Liste entfernt wird

Dieses Pattern erlaubt flexibel strukturierbare Anwendungen und wird sowohl im Blackberry- als auch in iPhone-Apps eingesetzt.

“Objects are dynamically typed. In source code (at compile time), any object variable can be of type id no matter what the object’s class is. The exact class of an id variable (and therefore its particular methods and data structure) isn’t determined until the program runs. [...] To permit better compile-time type checking, and to make code more self-documenting, Objective-C allows objects to be statically typed with a class name rather than generically typed as id. It also lets you turn some of its object-oriented features off in order to shift operations from runtime back to compile time.”

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocStaticBehavior.html

Konkret bedeutet dies, das beliebige Nachrichten an Objekte verschickt werden können. Mit Hilfe von “Categories” können bestehende Klassen (beispielsweise NSString) sogar um neue Methoden erweitert werden, ohne deren Quellcode zu ändern. Zudem können größere Klassen mit Categories in mehrere Dateien aufgeteilt werden.

Aufgrund des dynamischen Verhaltens kennt Objective-C keine privaten Methoden. Zwar kann auf eine Deklaration der Methode im Interface verzichtet werden, allerdings kann die Methode dennoch aufgerufen werden.

Auch null-Referenzen verhalten sich etwas anders als gewohnt: In Java führt jeder Methodenaufruf einer null-Referenz zwangsläufig zu einer NullPointerException. In Objective-C dagegen wird in diesem Fall nil zurückgegeben, und das ohne Fehlermeldung. Die nil-Referenz hat auch eine weitere Aufgabe: In Listen (NSMutableArray) wird nil zur Markierung des Listenendes verwendet, und kann somit nicht als null-Wert genutzt werden. Für diesen Zweck gibt einen eigenen Typ namens NSNull.

Eine Garbage Collection ist nur für Mac OSX 10.5 verfügbar. iPad-, und iPhone-Entwickler müssen sich dagegen mit dem halbautomatischen Memory-Management anfreunden bzw. auseinandersetzen. Da Objective-C direkt von C ableitet, erbt die Sprache auch einige C-Artefakte wie beispielsweise den für Java-Entwickler ungewohnten Präprozessor.

Trotz dieser Hürden überzeugt Objective-C jedoch mit ihrer spannenden Kombination aus statischer Typisierung und dynamischen Binden. Das Tooling (XCode) kann leider aber noch nicht mit Eclipse mithalten. Hier besteht noch deutlicher Nachholbedarf seitens Apple.

1. cmd-shift-d (Springt schnell zu einem File, ähnlich ctrl-shift-r in Eclipse )
2. cmd-alt-up (Wechselt von .h Datei zur passenden .m Datei und umgekehrt)
3. cmd-shift-j (Refactor von Klassen, Methoden und Variablen)
4. ctrl-shift-7 (Springt zum nächsten Platzhalter)
5. cmd-shift-7 (Kommentiert markierten Code)
6. ctrl-k (Löscht aktuelle Zeile)
7. cmd-shift-e (Schaltet den Editor in der Projektansicht ein und aus)

Aber wie bekomme ich die Informationen aus der .classpath-Datei ?

Hier hilft ant4eclipse: Der “getJdtClassPath”-Task extrahiert den Classpath aus dem Eclipse-Projekt und stellt ihn für die weitere Verwendung in ant bereit. Das nachfolgende Beispiel-Skript nutzt den extrahierten Classpath und kompiliert damit die Java-Klassen:

Praktisch.

• Erklärungstext für jede Frage
• Verbesserte Listendarstellung in “MyList”
• Und ganz wichtig: Schickeres Applikationsicon

Hier gehts zum Download. Viel Spaß beim Lernen.

        <LocationMatch "^/static(.*)">
                ExpiresActive On
                ExpiresDefault "access plus 1 day"
        </LocationMatch>

Allerdings besteht die Gefahr, dass Codeänderungen aufgrund des clientseitigen Caches beim Kunden erst sich nach einem Tag manifestieren. Eine Lösung ist, den Resourcen einen Timestamp des Deployments zu geben, so dass sie quasi endlos gecached werden können. Bei einem neuen Deployment erhalten die Resourcen einen neuen Timestamp. Mehr zu Frontend Best Practises gibts hier oder auch hier.