tutego

Seit dem 17. Juni kann man Eclipse 3.4 laden. Die Eclipse Ganymede Packages sind auch aktuell etwa mit der Eclipse IDE for Java EE Developers.

Und wie geht's nun weiter? Planungen laufen für Eclipse 4.0, was auch unter dem Namen e4 läuft. Einige Links dazu:

• http://it-republik.de/jaxenter/news/Eine-Preview-auf-Eclipse-4.0-043598.html
• http://wiki.eclipse.org/E4 mit Unterlinks

Interessant dürfe Rich Ajax Platform (RAP) werden, eine Möglichkeit, mehr oder weniger direkt die SWT-Anwendungen über ein Ajax-Framework ins Web zu setzen.

Labels: Eclipse, Entwicklungsumgebung

Die Java-Collection API bietet grundlegende Sammlungen, aber es gibt immer noch Bedarf an mehr. Drei Bibliotheken stechen hier besonders raus:

• http://code.google.com/p/google-collections/
• http://commons.apache.org/collections/
• http://javolution.org/

Lese etwas über die Projekte. Beantworte folgende Fragen:

• Welche neuen Datenstrukturen enthalten Google Collections?
• Welche Autoren arbeiten an Google Collections?
• Welchen Sinn ergeben folgende Szenarien: new ReferenceMap(WEAK, STRONG), new ReferenceMap(WEAK, WEAK), new ReferenceMap(STRONG, STRONG)?
• Was kann man mit der Apache-Klasse ExtendedProperties machen?
• Wofür sind die Typen in org.apache.commons.collections.functors nötig und wie verwendet man sie ? Haben Transformer damit etwas zu tun?
• Warum spricht Javolution an vielen Stellen von "hard real-time compliant"?
• Bewerte den Benchmark http://javolution.org/doc/benchmark.html.

Labels: Die wöchentliche Dosis Java

Der binären Operator instanceof testet, ob ein Objekt Exemplar einer Klasse oder der Oberklasse ist. Wenn das Ergebnis wahr ist, lässt sich das Objekt unter dem gegeben Typen ansprechen, ist also zu-weisungskompatibel. Der rechte Operator bei instanceof, der Typname, muss jedoch immer zur Übersetzungszeit bekannt sein und kann nicht dynamisch, etwa durch eine String, festgelegt werden.

Ist der Typname zur Compilerzeit vielleicht unbekannt, kann das Class-Objekt helfen. Die Methode isInstance(Object) ist sozusagen ein dynamisches instanceof. Gilt mit dem Operator

object instanceof ReferenceType

So heißt das mit der Methode

ReferenceType-Class-Objekt.isInstance( object )

Gewöhungsbedürftig ist sicherlich die Tatsache, dass bei der Methode isInstance() die beiden Operanden umgedreht sind. Dazu ein paar Beispiele:

Component b = new JLabel();
out.println( b instanceof JLabel );                                                  // true
out.println( JLabel.class.isInstance( b ) );                                         // true
out.println( Object.class.isInstance( b ) );                                         // true
out.println( Class.forName("java.awt.Component").isInstance( b ) );                  // true
out.println( String.class.isInstance( b ) );                                         // false

Die Methode isInstance(object) ist natürlich ein wenig eingeschränkt dadurch, dass es immer ein Test-Objekt geben muss. Die Frage etwa, ob das Class-Objekt der Schnittstelle PublicKey eine ist-eine-Art von Serializable ist, kann isInstance(object) nicht beantworten, denn dann müsste es vorher ein Objekt geben. Für diesen Fall bietet das Class-Objekt noch eine zweite Funktion: isAs-signableFrom(Class).

Class<?> clazz = Serializable.class;
out.println( clazz.isAssignableFrom( String.class ) );                  // true
out.println( clazz.isAssignableFrom( Thread.class ) );                  // false
out.println( clazz.isAssignableFrom( PublicKey.class ) );               // true

Solange der Typname zur Übersetzungszeit bekannt ist, ist instanceof immer noch die beste Lösung. Doch wenn die Klasse nur durch ein Class-Objekt gegeben ist, bleibt immer noch isAssignableFrom(). Die Methode clazz.isInstance(obj) ist sozusagen eine Kurzform von clazz.isAssignableFrom(obj.getClass()).

Labels: Insel

http://lopeathal.wikispaces.com/Open+Source+Docking+Frameworks gibt einen Überblick über Docking-Frameworks:

Labels: Open Source, Swing

Die Collection-API enthält grundlegende Sammlungen für Listen, Kellerspeicher, Assoziativspeicher. Gehe über alle Operationen der folgenden Schnittstellen:

• http://java.sun.com/javase/6/docs/api/java/util/Collection.html
• http://java.sun.com/javase/6/docs/api/java/util/List.html
• http://java.sun.com/javase/6/docs/api/java/util/Queue.html
• http://java.sun.com/javase/6/docs/api/java/util/Set.html
• http://java.sun.com/javase/6/docs/api/java/util/Map.html

Finde je ein Beispiel für keySet(), retainAll(), toArray(), headSet().

Welche Implementierungseigenschaften haben die folgenden Klassen:

• http://java.sun.com/javase/6/docs/api/java/util/HashSet.html
• http://java.sun.com/javase/6/docs/api/java/util/TreeSet.html
• http://java.sun.com/javase/6/docs/api/java/util/ArrayList.html
• http://java.sun.com/javase/6/docs/api/java/util/LinkedList.html
• http://java.sun.com/javase/6/docs/api/java/util/concurrent/PriorityBlockingQueue.html
• http://java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html
• http://java.sun.com/javase/6/docs/api/java/util/concurrent/CopyOnWriteArraySet.html
• http://java.sun.com/javase/6/docs/api/java/util/concurrent/CopyOnWriteArrayList.html
• http://java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentSkipListSet.html
• http://java.sun.com/javase/6/docs/api/java/util/EnumMap.html
• http://java.sun.com/javase/6/docs/api/java/util/HashMap.html
• http://java.sun.com/javase/6/docs/api/java/util/IdentityHashMap.html
• http://java.sun.com/javase/6/docs/api/java/util/LinkedHashMap.html
• http://java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentHashMap.html
• http://java.sun.com/javase/6/docs/api/java/util/WeakHashMap.html

Fülle eine WeakHashMap mit sovielen neuen java.awt.Point-Objekten, bis es einen OutOfMemoryError gibt. Fange diesen ab und gib die Größe der WeakHashMap aus.

Laufe zum Verständnis der Implementierung folgende Szenerien im Debugger ab:

• Ein Element wird in die HashMap eingefügt, dann erfragt.
• In eine LinkedList bzw. ArrayList werden einige Elemente eingefügt, dann nach ihrer Position erfragt und gelöscht.

Labels: Die wöchentliche Dosis Java

Robert Simmons. O'Reilly. ISBN 0-596-00568-7. März 2004. 344 Seiten
Warum tut mir O'Reilly das an? Ich setze es ohne Bedenken auf Platz 1 in der Liste der Java-Bücher, die einen völlig verfehlten Titel tragen. Im Vorwort wird noch groß verkündet: „We're talking about difficult but extremely powerful and useful programming techniques like reflection, advanced data modeling, advanced GUI design, and advanced aspects of JDO, EJB and XML-based web clients. This unique book reveals the true wizardry behind the complex and often-mysterious Java environment.“ und dann kommt nur Anfängerstoff und nix von JDO, EJB oder XML. Dafür umso mehr Kindergartenthemen: Jede Klasse ist von java.lang.Object abgeleitet, ein „if“ verträgt auch komplexe Anfragen mit ZWEI Bedingungen oder dass es einen ?-Operator gibt. Echt Hardcore! Des Weiteren deklariert Felder in umständlicher Syntax int[] AN_ARRAY = new int[] {1, 2, 3, 6, 9, 18, 36}; statt einfach nur int[] AN_ARRAY = {1, 2, 3, 6, 9, 18, 36}; Und schließlich 30 Seiten Auseinandersetzung von final. Die Namen der Color-Konstanten sind klein statt groß (gibt es „erst“ seit Java 1.4) geschrieben, und warum der Autor in dem Calendar-Beispiel ausdrücklich nach GMT fragt, ist ebenfalls sonderbar, denn für das Beispiel spielt das überhaupt keine Rolle:

private Date creationDate = Calendar.getInstance(TimeZone.getTimeZone("GMT")).getTime( );

Im nächsten Kapitel über immutable kommt natürlich der Hinweis auf String (immutable) und Point, Date, StringBuffer (nicht immutable), aber wertvolle Hinweise, etwa das immutable-Typen die Entwicklung von multitheaded-Anwendungen massiv erleichtern und immutable Objekte gut in einen Pool passen (wie einige Wrapper-Objekte in Java 5) werden unter den Teppich gekehrt. Immerhin erwähnt er die Unmodified-Wrapper. Weiter zum nächsten Hardcore-Thema, der Collection-API. Mr. Simmons schreibt: „...code is an example of a good interface-based technique:“

public class SomeClass {
 HashSet someSet = new HashSet( );
 protected Set someMethod( ) {
   return this.someSet;
 }
}

Der Objekttyp von someSet sollte wohl Set statt HashSet sein. Und warum ist in dem Beispiel die Methode gerade protected? Und someSet paketsichtbar? Da steckt vermutlich Hardcore Java Design-Erfahrung im Code. Na ja, dann hakt das Kapitel noch mal eben alle Hardcode-Collection-Klassen ab. Dass Robert fail-fast von Iteratoren erklärt, ist super, aber dann der nächste Rückschlag bei set.add(new String("p->" + element)). Was soll denn das heißen? Das nächste Kapitel heißt Exception-Handling (in welchem Java-Einführungsbuch steht das bitte schön nicht?) und der Hinweis, dass finally eine gute Stelle ist, um Datenbankverbindungen zu schließen. Das folgende Kapitel ist noch viel härter. Es geht um innere Klassen. Jetzt ist es an der Zeit, sich jeden Satz ganz genau anzuschauen und sich hoch zu konzentrieren. Radio aus, Fernseher aus, Computer aus. Weiter zum nächsten Hammerthema – Konstanten und Internationalisierung. Dass Robert auch Klammern kennt, zeigt er in Anweisungen wie dieser:

double area = (Math.pow(radius, 2) * PI);

(Wie wäre es stattdessen einfach mit radius * radius * 2? Oder wollte er ein Beispiel für größtmöglichen Rechenaufwand leisten?) Um vielleicht ungenauen Pi-Belegungen von Sun über Math.PI vorzubeugen, ist es auch sinnvoller, gleich selbst PI vorzubelegen: public static final double PI = 3.141;. Ist viel viel besser! Im Kapitel werden auch Bit-Felder vorgestellt inklusive der Bit-Operatoren. Bei den anschließenden Aufzählungen und Konstanten-Objekten baut der Autor dann erst einmal das Java 5 enum nach, bis er schlussendlich im letzten Kapitel auch zu Java 5 kommt. Dann kommt aber doch noch ein interessanter Absatz über readResolve() bei der Serialisierung. Immerhin hat Robert verstanden, dass es Klassenlader gibt: „You may think that since the constant object is final and static, this will guarantee that only one instance of each constant object will be in memory. I used to think the same thing until I was blindsided by a vicious bug in a genetic research system.“ Impressive! Im 8. Kapitel geht’s um Datenmodellierung. Kein Java-Thema und auch nur ein paar Seiten. Der Ansatz: „Unterstreiche alle Nomen und du hast Klassen, unterstreiche alle Verben und du hast Methoden“ darf auch nicht fehlen. So hat Robert sicherlich große Enterprise Systeme modelliert. Kapitel 9 hat Reflection zum Thema und etwas zum java.beans Paket. Seine Lust, an alle möglichen finalen Variablen auch final dranzuschreiben, sinkt. Kapitel 10 kommt auf Proxies zu sprechen, und dass die bei CORBA und RMI vorkommen. Nachdem ein selbstgebauter Proxy sich vorstellen darf, kommt es doch noch zu Einsatz vom InvocationHandler/Proxy. Jetzt wird es langsam interessant. Kapitel 10 spricht von schwachen Referenzen. Er implementiert ein

public class WeakHashSet extends AbstractSet implements Set

(warum steht hier implements Set?) und schreibt einen Weak-Listener. Solch ein Konstrukt ist insbesondere in Swing-Anwendungen sehr nützlich, doch hier hätte ich den Hinweis gut gefunden, dass etwa die OpenIDE, also NetBeans, hier schon etwas anbietet. Wo jetzt andere „Hardcore“-Bücher einsteigen ist seines, oh schade, schon zu Ende. Das war eigentlich das letzte Kapitel! Denn Kapitel 12 ist das Abschlusskapitel mit Java 5 und geht auf die Neuerungen ein. Doch seien wir ehrlich: Harte Nüsse wie Generics lassen wir uns viel lieber von einem echten Crack, von Joshua Bloch, in seinem Buch erklären. Dann müssen wir uns nicht Beispiele wie dieses hier anschauen:

class SomeClass<Type> {
 Type value = null;
 public Type getValue() {
   return this.value();
 }
 public void setValue(final Type value) {
   this.value = value;
 }
}

Typvariablen sollten immer nur aus einzelnen Großbuchstaben bestehen. Bei einer Deklaration wie Type getValue() sieht sonst Type wie ein ordinären Java-Typ aus. Und warum wird value mit null initialisiert. Das ist doch klar, dass die JVM das mit null belegt. Was zeigt das Buch? Immerhin das O’Reilly den Mut hat, die schlechten Bewertungen auf der Webseite stehen zu lassen und nicht zu löschen. Meine Hochachtung. Bei Amazon sind die Bewertungen aber noch ehrlicher. Mut wird O’Reilly erst dann wirklich beweisen, wenn sie a) den Titel umformulieren, b) sich einen neuen Autor suchen, der das Buch umschreibt bzw. erweitert oder c) – die beste Option für jetzt – das Buch aus dem Sortiment nimmt. 4 Jahre nach Erscheinen wird’s Zeit dafür.

Labels: Rezension

Douglas Crockford. O'Reilly. ISBN 978-0-596-51774-8. Mai 2008. 170 Seiten

In meinem Alltag habe ich wenig mit JavaScript zu tun (von meinem Visual Foxpro nach JavaScript-Konverter einmal abgesehen), sodass mir das Buch gerade recht kam, um meine JavaScript-Kenntnisse zu vertiefen. Es ist sicherlich nicht für absolute Anfänger geschrieben, doch für Leser mit Grundkenntnissen gut geeignet, tiefer in die Sprache einzusteigen. Techniken wie den Prototyp-Ansatz der Objektorientierung beschreibt Douglas sehr genau, sicherlich etwas zu detailliert für diejenigen, die nur  mal eben" JavaScript für die Webseite einsetzen möchten. (HTML und DOM spielen kaum eine Rolle. JavaScript wird eher als allgemeine Programmiersprache behandelt und weniger als  Webseitensprache".) In seine Beispielen finde ich teilweise den Rückgriff auf Variablen und Methoden aus vorangehenden Beispielen etwas irritierend. Zum Beispiel kommt seine selbstgebaute beget()-Funktion immer wieder vor, doch ohne einen Verweis für Leser, die erst in der Mitte einsteigen und diese Funktion nicht kennen. Seiner Argumentation beim Inkrement-/Dekrement-Operator ++, --, "In my own practice, I observed that when I used ++ and --, my code tended to be too tight, too tricky, too cryptic. So, as a matter of discipline, I don't use them any more. I think that as a result, my coding style has become cleaner." bei den Bad-Parts kann ich nicht folgen, doch sonst erscheinen mit die Bad- und Awfull-Parts recht sinnvoll ausgewählt. Der
Unterschied zwischen == und === enthält tolle Beispiele; Begründungen für die Auswertung wären allerdings schön.

'' == '0'          // false 
0 == ''            // true 
0 == '0'           // true 
false == 'false'   // false 
false == '0'       // true 
false == undefined // false 
false == null      // false 
null == undefined  // true 
' \t\r\n ' == 0    // true

Im Anhang stellt der Autor JSLint vor, ein Tool zum Testen der Codequalität von JavaScript-Programmen. Das ist zwar nett, doch hätte

ich freie JavaScript-Bibliotheken (wie etwa Prototype) lieber gesehen. Das Kapitel 4 (Functions) gibt's online.

Labels: Rezension