Ein praktisches Feature, um doppelte catch-Blöcke zu vermeiden. Es ist nun möglich mit einem Catch-Block mehrere Exception-Typen gleichzeitig zu fangen. Die Exception-Typen werden dabei mit dem ODER-Operator (|) getrennt. Im Catch-Block kann die gefangene Exception unter gemeinsamen Supertyp angesprochen werden.

   static class AException extends Exception {
        public void fooFromA() {}
    }
    static class BException extends AException {
        public void fooFromB() {}
    }
    static class CException extends AException {
        public void fooFromC() {}
    }

    public void x() {
        try {
            z();
        } catch (BException | CException e) {
            e.fooFromA();
            // e.fooFromB(); Compiler-Fehler
            // e.fooFromC(); Compiler-Fehler
        }
    }

    public void z() throws BException, CException {
        // heavy lifting
    }

“Improved Checking for Rethrown Exceptions”

Des Weiteren “merkt” sich der Compiler nun, welche Exception-Typen im try-Block geworfen können. So kann im Catch-Block ein Supertyp gefangen und weiter geworfen werden, auch wenn dieser Supertyp gar nicht in der throws-Deklaration vorkommt.

 public void y() throws BException, CException {
        try {
            z();
        } catch (Throwable e) {
            // e darf ohne Cast weiter geworfen werden, da
            // der Compiler sich "gemerkt hat", dass im
            // try-Block nur BException und CException
            // vorkommen können.
            throw e;
        }
    }

Eine gute Übersicht über alle neuen Features ist hier zu finden. Bekanntermassen wurden letztes Jahr die spannendsten Features “Closures” und “Collection Literals” in das JDK8 verschoben. Nichtsdestotrotz bietet das JDK7 mit dem JSR 334 kleine, sinnvollere Spracherweiterungen.

Binary Literals

Eins davon sind die “binary literals”. In früheren JDKs konnten numerische Literale im Quelltext in dezimaler, hexadezimaler oder oktaler Schreibweise erscheinen. Der Compiler des JDK7 erlaubt nun auch eine binäre Representation:

int answer = 0b101010;

Unterstriche in numerischen Literale

Desweiteren können Zahlen zwecks besserer Lesbarkeit im Quelltext auch mit einem Unterstrich optisch gruppiert werden. Dabei ist zu beachten, dass die Unterstriche nicht am Anfang oder am Ende eines Literals stehen dürfen.

long words1 = 0xCAFE_BABE; // ok
long words2 = 0xCAFE_BABE_; // Compiler-Fehler
long words3 = 0x_CAFE_BABE; // Compiler-Fehler

Strings im switch-Statement

Nun kann auch ein String im switch-Statement verwendet werden. Der case-Vergleich findet analog zu der java.lang.String#equals-Methode statt. Das nachfolgende Beispiel gibt “banana” auf der Konsole aus.

        final String fruit = "banana";
        switch (fruit) {
            case "Apple":
                System.out.println("Apple");
                break;
            case "Banana":
                System.out.println("Banana");
                break;
            case "banana":
                System.out.println("banana");
                break;
        }

Ob ein String-Vergleich immer eine gute Idee ist, sei dahin gestellt. Schliesslich funktioniert ein Switch-Case seit dem JDK5 auch mit dem Enum-Konstrukt.

So. Genug für heute. Im nächsten Blogpost drehen wir eine weitere Runde.

Die Präsentation zeigt, wie schicke UIs skalierbar implementiert werden können. Das tolle ist, dass RIM den kompletten Quelltext der vorgestellten Manager und Fields zur Verfügung stellt.

Der Download erfordert allerdings einen BlackBerry Developer Account.

Die kleinste Basiseinheit im UI-Framework ist net.rim.device.api.ui.Field, welches einen rechteckigen, zeichenbaren Bereich darstellt. Beispiel für ein Field ist net.rim.device.api.ui.component.EditField, welches Texteingaben ermöglicht.

Fields werden durch net.rim.device.api.ui.Manager-Instanzen verwaltet. Ein Manager ist für die Positionierung der enthaltenen Fields sowie für das Scrolling verantwortlich. Jedes Field kann zu genau einem Manager zugeordnet werden. Beispiel für einen Manager ist net.rim.device.api.ui.container.HorizontalFieldManager, der seine Fields horizontal anordnet. Manager können auch andere Manager enthalten, da sie selbst von Field ableiten.

Für komplexere Views müssen eigene Manager und Fields implementiert werden. Was anfangs etwas gewöhnungsbedürftig erscheint, entpuppt sich schnell als durchdachtes Konzept.

2. Crypto-API

Kernkompetenz der BlackBerry-Smartphones ist der Einsatz in Unternehmen. Dementsprechend umfangreich und mächtig ist auch die Crypto-API des SDKs. Alle Verschlüsselungsanforderungen in unseren Projekten konnten wir mit der Crypto-API lösen, ohne fremde Bibliotheken verwenden zu müssen.

3. Eclipse-Integration

Mit eines der grössten Ärgernisse in der BlackBerry-Entwicklung war die veraltete, swing-basierte Entwicklungsumgebung names “JDE”. RIM hat reagiert und ein Plugin für Eclipse entwickelt, welches seit letztem Jahr, bzw. der Version 1.1.1 auch wirklich praxistauglich funktioniert. Durch das “Code Hot Swap”-Feature, also der Austausch von COD-Files zur Laufzeit verringern sich auch die zeitraubenden Neustarts des Simulators.

Zudem muss man immer noch eigene Ant-Skripte bauen, um auf Knopfdruck ein Deployment für alle unterstützten OS-Versionen zu generieren. Hier besteht noch Verbesserungspotential.

Ein Http-Request kann über 5 verschiedene Transportwege übermittelt werden:
1. BIS (BlackBerry Internet Service)
2. BES (BlackBerry Enterprise Service)
3. WAP 2.0
4. Direct TCP – (Direkt über den APN des Netzbetreibers)
5. WiFi

Welcher Transportweg für eine Http-Verbindung genommen werden soll, muss der Entwickler selbst bestimmen und dabei gleichzeitig auch die Verfügbarkeit prüfen. Natürlich verhalten sich die Transportwege auch unterschiedlich: Beispielsweise wird man bei dem Transportweg BIS oder BES nie einen HTTP 301 oder 302 zu sehen bekommen, da die Redirects bereits in der BlackBerry-Infrastruktur aufgelöst werden.

Verschärfend kommt hinzu, dass dem Endkunden je nach Datentarif und gewählten Transport unterschiedliche Kosten entstehen können. Somit muss der Kunde in den Einstellungen der App die Möglichkeit haben, den präferierten Transportweg auszuwählen. iPhone-User und Applikationsentwickler schütteln hier einfach den Kopf. Zwar stellt RIM seit der OS-Version 5.0 eine Network-API zur Verfügung, die das ganze vereinfacht, aber für ältere OS-Versionen muss dies selbst implementiert werden.

2. Jeder schreibt sich das Logging-Framework selbst

Es soll ja tatsächlich in der Java-SE Welt noch vereinzelt Leute geben, die sich eine eigene Logger-Implementierung schreiben. In der BlackBerry-Welt macht das jeder, da die mitgelieferte EventLogger-Klasse nur rudimentäre Funktionalität bietet und sehr unglücklich zu programmieren ist. Beispiel gefällig ?

  // Register application for event logging with GUID
 EventLogger.register(0x9c805919833654d6L, SampleApp);

 // Log a numeric event.
 EventLogger.logEvent(0x9c805919833654d6L, 12, EventLogger.INFORMATION);

Im Übrigen kann ein Log maximal 16kB umfassen.

3. Anzahl der Threads bei älteren Geräten auf 16 limitiert

Eine App kann auf älteren Geräten max. 16 Threads gleichzeitig laufen lassen. Wenn eine App überdurchschnittlich komplex ist, und viele Dinge im Hintergrund erledigt (Parsing, GPS- und CellId-Lokalisierung, Laden von Kartendaten), dann muss man aufpassen, dass diese Grenze nicht überschritten wird. Ansonsten wird die Applikation unschön mit einem TooManyThreadError beendet. Dies betrifft allerdings nur die älteren Geräte. Modernere Modelle wie der Torch oder Bold können weitaus mehr Threads parallel laufen lassen.

Aber wo Schatten ist, ist auch Licht. Der nächste Blogeintrag handelt von 3 Dingen, die das BlackBerry-SDK elegant löst.

Ich konnte einen 7-seitigen Artikel beisteuern, der den Einstieg in diese Entwicklungsplattform erleichtert. Der Artikel stellt das UI-Framework vor, erläutert die Besonderheiten bei Netzwerkverbindungen und beleuchtet das Tooling sowie Fragmentierung der BlackBerry-Plattform. Viel Spaß beim Lesen …

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.