Google App Engine Prerelease 1.3.4 SDK

Die Neuerungen in Kürze:

– Client side bulkloader available with the Python SDK that has a new  configuration syntax and wizard for easier import/export with the datastore. Can be used by enabling remote_api in your Java application
– Applications can now be configured to authenticate with OpenID by selecting the OpenID option when creating your application in the admin console. http://code.google.com/p/googleappengine/issues/detail?id=248. http://code.google.com/p/googleappengine/issues/detail?id=56
– New API to allow App Engine apps to act as OAuth service providers. ttp://code.google.com/p/googleappengine/issues/detail?id=919
– The version update check in the Java SDK now uses https.
– Allow full access to javax.el.* . http://code.google.com/p/googleappengine/issues/detail?id=3157
– Increased the timeout during deployment to 15 minutes
– Fixed an issue with JPA where an illegal cast exception was thrown during the fetch of integer fields
– MemcacheService.setNamespace() is deprecated in favor of
  MemcacheServiceFactory.getMemcacheManager(namespace)
– Support in the SDK for Java 1.5 is being deprecated. These warnings now appear  when starting the SDK

Sehr interessant ist die Remote-API (http://blog.notdot.net/2010/05/Behind-the-scenes-with-remote-api). Über Beispiele in Java werde ich Zukunft berichten.

Neue Job-Börse auch für Java-Entwickler

Wer auf der Suche nach einem neuen Job ist, kann bei webentwickler-jobs.de vorbeischauen. Die Jobbörse ist dediziert für IT-Personen und nicht breit für Softwareentenwickler, Betriebswirtschaftler, Sozialarbeiter und Kaffeekocher (wobei es einige gibt, die sagen, ITler vereinen alles…) Die Stellenanzeigen sind schön unterteilt in die Rubriken Java, Ruby on Rails, Python, PHP, Typo3, .NET und Perl. Im Bereich Java standen heute fast 350 Jobs. Die Seite und ist dazu noch werbefrei und kostenlos.

Buchkritik Pro Jakarta Commons

Harshad Oak, Apress, 1590592832, Februar 2004, 304 Seiten

Harshad Oak beschreibt in dem Buch die bekannten Jakarta Commons Bibliotheken. Nicht jede Funktion wird vorgestellt, sodass das Buch die JavaDoc nicht ersetzt. Eher versucht der Autor die Philosophie und Kernkomponenten zu vermitteln. Es gibt immer wieder komplett abgebildete Listings, die man direkt in die IDE einsetzen und mit den entsprechenden Libs im Klassenpfad direkt ausführen kann. Mich hätte gefreut, wenn hinter den println()-Zeilen gleich die Ausgabe steht, so muss nicht man immer unter das Listing schauen – das geht besser. Die Auswahl an Themen ist OK, nur sein Styleguide ist zum Teil etwas schwach, wenn er etwa Variablen iVowelCnt oder iTestLen nennt. Auch Zeilen wie

char[] aChars = new char[] { ‚a‘, ‚1‘, ‚c‘, ‚2‘, ‚e‘, ‚f‘, ‚g‘ };

überraschen mich (mal wieder). Und was ist das für eine Schreibweise in “SELECT UserName as uName, AgE FROM USER”?

Updates wären natürlich sehr schön. Java 5 spielt keine Rolle, und Java 1.4 wird als aktuell bezeichnet, sodass es NestableException einen größeren Raum einnimmt, als es müsste. An anderer Stelle gibt es den Satz “The Discovery component depends on JDK version 1.1.8 or higher”. Also wenn das nicht gegeben ist… Auch Enum könnte man sich natürlich mit Java 5 sparen. Aber das ist eine allgemeine Kritik auch an den Jakarta Commons, da kann der Autor nichts für. Heute könnte man eine Reihe on Verbesserungen vornehmen und auch Alternativen nennen. Im Bereich Date/Time etwa Joda-Time, bei Collections natürlich Google Collections, usw. Die Validator-Klasse macht mittlerweile Java Beans Validation, ein Standard von Java EE 6, quasi überflüssig und Struts Validator spielt heute keine Rolle mehr. Bei den BeanUtils wäre der Hinweise angebracht, dass man mit dynamisch generieten Bytecode schnellere Lösungen realisieren kann als über Reflection. Fürs Datenbank-Pooling gibt es auch Alternativen, sie wären gut im Kapitel 6 aufgelistet. Commons Logging ist auch nicht unproblematisch, eine tiefere Diskussion hätte der Autor bringen können. Und Thread-Pools könnten auch noch erwähnt werden. In Java 7 ersetzt Objects die Commons Klasse ObjectUtils. Zusammenfassung: Fortgeschrittene Entwickler dürften sich das Buch sparen können und kommen mit der API-Dokumentation – die sehr gut und mit vielen Beispielen bebildert ist – sehr weit. Einige der Commons-Bibliotheken sind zudem heute veraltet und spielen in neuesten Projekten keine große Rolle mehr. Die spannenden und aktuellen Themen kommen im Buch leider etwas zu flach weg.

SimpleDS 1.0 RC für die GAE/J

Dass die Low-Level-API nicht so tolle ist, habe ich unter anderem schon hier eine Alternative genannt. Eine andere ist SimpleDS, von der nun der erste Release Candidate raus ist. Siehe auch die 1.0-Ankündigung. Features:

NetBeans 6.9 Beta

Eclipse 3.6 kommt, Eclipse e4 kommt und auch neue Version von NetBeans ist auf dem Weg. Die Version 6.9 glänzt in vielen Bereichen und alle hier im Blog aufzulisten wäre zu viel. Seht selbst unter http://wiki.netbeans.org/NewAndNoteworthy69. Interessant finde ich die IDE-Unterstützung für OSGi und Nutzung proprietärer APIs wie Jersey REST Client API. Schon bei der letzten Versionen von NetBeans wurde so das Swing Application Framework beim Neue-Swing-Anwendung-Wizard eingeführt. Während die REST Client API stabil und populär ist, ist es aber das Swing App Framework nicht, denn es erfährt keine öffentliche Unterstützung. Wer also denkt, mit NetBeans eine langlebige Gui-Anwendung mit dem Swing App Framework zu erstellen, ist später vermutlich am Po gekniffen.

Insgesamt wäre ich glücklicher, wenn die Entwickler mehr an Java 7 arbeiten würden, als an einer IDE. Aber NetBean ist zumindest unverzichtbar als Java 7 IDE.

Thema der Woche: Das HTTP-Protokoll

Über HTTP tauschen Client (etwa Browser) und Server Metadaten und Nutzdaten aus.

Die ersten Schritte mit JAXB

JAXB ist eine API zum Übertragen von Objektzuständen auf XML-Dokumente und umgedreht. Anders als eine manuelle Abbildung von Java-Objekten auf XML-Dokumente oder das Parsen von XML-Strukturen und Übertragen der XML-Elemente auf Geschäftsobjekte arbeitet JAXB automatisch. Die Übertragungsregeln definieren Annotationen, die Entwickler selbst an die JavaBeans setzten können, aber JavaBeans werden gleich zusammen mit den Annotationen von einem Werkzeug aus deiner XML-Schema-Datei generiert.

Java 6 integriert JAXB 2.0, und das JDK 6 Update 4 – sehr ungewöhnlich für ein Update – aktualisiert auf JAXB 2.1.

1.1.1          Bean für JAXB aufbauen

Wir wollen einen Player deklarieren, und JAXB soll ihn anschließend in ein XML-Dokument übertragen.

com/tutego/insel/xml/jaxb/Player.java, Player

@XmlRootElement

class Player

{

private String name;

private Date   birthday;

public String getName()

{

return name;

}

public void setName( String name )

{

this.name = name;

}

public void setBirthday( Date birthday )

{

this.birthday = birthday;

}

public Date getBirthday()

{

return birthday;

}

}

Die Klassen-Annotation @XmlRootElement ist an der JavaBean nötig, wenn die Klasse das Wurzelelement eines XML-Baums bildet. Die Annotation stammt aus dem Paket javax.xml.bind.annotation.

1.1.2          JAXBContext und die Marshaller

Ein kleines Testprogramm baut eine Person auf bildet sie dann in XML ab – die Ausgabe der Abbildung kommt auf dem Bildschirm.

com/tutego/insel/xml/xml/jaxb/PlayerMarshaller.java, main()

Player johnPeel = new Player();

johnPeel.setName( „John Peel“ );

johnPeel.setBirthday( new GregorianCalendar(1939,Calendar.AUGUST,30).getTime() );

JAXBContext context = JAXBContext.newInstance( Player.class );

Marshaller m = context.createMarshaller();

m.setProperty( Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE );

m.marshal( johnPeel, System.out );

Nach dem Lauf kommt auf den Schirm:

<?xml version=“1.0″ encoding=“UTF-8″ standalone=“yes“?>

<player>

<birthday>1939-08-30T00:00:00+01:00</birthday>

<name>John Peel</name>

</player>

Alles bei JAXB beginnt mit der zentralen Klasse JAXBContext. Die statische Methode JAXBContext.newInstance() erwartet standardmäßig eine Aufzählung der Klassen, die JAXB behandeln soll. Der JAXBContext erzeugt den Marshaller zum Schreiben und Unmarshaller zum Lesen. Die Fabrikmethode createMarshaller() liefert einen Schreiberling, der mit marshal() das Wurzelobjekt in einen Datenstrom schreibt. Das zweite Argument von marshal() ist unter anderem ein OutputStream (wie System.out in unserem Beispiel), Writer oder File-Objekt.

JAXB beachtet standardmäßig alle Bean-Properties, also birthday und name, und nennt die XML-Elemente nach den Properties.

1.1.3          Ganze Objektgrafen schreiben und lesen

JAXB bildet nicht nur das zu schreiben Objekt ab, sondern auch rekursiv alle referenzierten Unterobjekte. Wir wollen den Spieler dazu in einen Raum setzen und den Raum in XML abbilden. Dazu muss der Raum die Annotation @XmlRootElement bekommen und bei Player kann sie entfernt werden, wenn nur der Raum selbst aber kleine Player als Wurzelobjekte zum Marshaller kommen.

com/tutego/insel/xml/xml/jaxb/Room.java, Room

@XmlRootElement( namespace = „http://tutego.com/“ )

public class Room

{

private List<Player> players = new ArrayList<Player>();

@XmlElement( name = „player“ )

public List<Player> getPlayers()

{

return players;

}

public void setPlayers( List<Player> players )

{

this.players = players;

}

}

Zwei Annotationen kommen vor: Da Room der Start des Objektgrafen ist, trägt es @XmlRootElement. Als Erweiterung ist das Element namespace für den Namensraum gesetzt, da bei eigenen XML-Dokumenten immer ein Namensraum genutzt werden soll. Weiterhin ist eine Annotation @XmlElement am Getter getPlayers() platziert, um den Namen des XML-Elements zu überschreiben, damit das XML-Element nicht <players> heißt, sondern <player>.

Kommen wir abschließend zu einem Beispiel, das einen Raum mit 2 Spielern aufbaut, und diesen Raum dann in eine XML-Datei schreibt. Statt allerdings JAXBContext direkt zu nutzen und einen Marshaller zum Schreiben und Unmarshaller zum Lesen zu erfragen, kommt im zweiten Beispiel die Utility-Klasse JAXB zum Einsatz, die ausschließlich statische überladene marshal() und unmarshal() Methoden anbietet.

Player john = new Player();

john.setName( „John Peel“ );

Player tweet = new Player();

tweet.setName( „Zwitscher Zoe“ );

Room room = new Room();

room.setPlayers( Arrays.asList( john, tweet ) );

File file = File.createTempFile( „room-jaxb-„, „.xml“ );

JAXB.marshal( room, file );

Room room2 = JAXB.unmarshal( file, Room.class );

System.out.println( room2.getPlayers().get( 0 ).getName() ); // John Peel

file.deleteOnExit();

Falls etwas beim Schreiben oder Lesen misslingt, werden die vorher geprüften Ausnahmen in einer DataBindingException ummantelt, die eine RuntimeException ist.

Die Ausgabe ist:

<?xml version=“1.0″ encoding=“UTF-8″ standalone=“yes“?>

<ns2:room xmlns:ns2=“http://tutego.com/“>

<player>

<name>John Peel</name>

</player>

<player>

<name>Zwitscher Zoe</name>

</player>

</ns2:room>

Da beim Spieler das Geburtsdatum nicht gesetzt war (null wird referenziert), wird es auch nicht in XML abgebildet.

Version 1.3.3 der Google App Engine

Die Neuerungen im Überblick:

Thema der Woche: Double-checked locking

Lies http://www.ibm.com/developerworks/java/library/j-dcl.html und erkläre, wo es genau bei

public static Singleton getInstance()
{
  if (instance == null)
  {
    synchronized(Singleton.class) {  //1
      if (instance == null)          //2
        instance = new Singleton();  //3
    }
  }
  return instance;

}

zu einem Problem bei nebenläufigen Threads kommen kann. Warum funktioniert es auch bei 2 synch. Blöcken nicht? Was hat das dem Memory-Modell zu tun?

Hinweis: Es geht nicht darum, ein Singleton korrekt zu implementieren, sondern das Java Memory Modell zu verstehen und Probleme aufzudecken, die sich aus der Nebenläufigkeit ergeben.

GCC 4.5 ist raus, am Java (GCJ) ändert sich nix

Die neue Version von GCC 4.5 ist raus, allerdings ohne Neuerungen am GCJ. Das ist irgendwie erstaunlich, da alle auch die Compiler-Frontends Ada einige und Fortran viele Neuerungen bekommt. Naja, Objective-C ist auch nicht mit in der Liste.

Grundsätzlich profitiert natürlich GCJ von den verbesserten Internas und Unterstützung neuer Prozessoren und Optimierungen. Aber prinzipiell muss man sich schon fragen, ob GCJ überhaupt jemals mit ernstzunehmenden Enthusiasmus entwickelt wurde. Eigentlich nie.

JUnit 4 Tutorial, Java-Tests mit JUnit

Hinweis! Eine aktuelle Version des Abschnittes gibt es im Buch „Java ist auch eine Insel. Einführung, Ausbildung, Praxis“, dem 1. Inselbuch. (War für den 2. Band vorgesehen, musste wegen der Fülle des 2. Buchs kurzerhand in den 1. Band geschoben werden. Sorry für Irritationen!)

1.1 Softwaretests

Um möglichst viel Vertrauen in die eigene Codebasis zu bekommen, bieten sich Softwaretests an. Tests sind kleine Programme, die ohne Benutzerkontrolle automatisch über die Quellcodebasis laufen und anhand von Regeln zeigen, dass gewünschte Teile sich so verhalten wie gewünscht. (Die Abwesenheit von Fehlern kann eine Software natürlich nicht zeigen, aber immer zeigt ein Testfall, dass das Programm die Vorgaben aus der Spezifikation erfüllt.)

Obwohl Softwaretests extrem wichtig sind, sind sie unter Softwareentwicklern nicht unbedingt populär. Das liegt unter anderem daran, dass sie natürlich etwas Zeit kosten, die neben der tatsächlichen Entwicklung aufgewendet werden muss. Wenn dann die eigentliche Software geändert wird, müssen auch die Testfälle oftmals mit angefasst werden, so dass es gleich zwei Baustellen gibt. Und da Entwickler eigentlich immer gestern das Feature fertig stellen sollten, fallen die Testes gerne unter den Tisch. Ein weiterer Grund ist, dass einige Entwickler sich für unfehlbare Codierungsgötter halten, die jeden Programmcode (nach ein paar Stunden debuggen) für absolut korrekt, performant und wohl duftend halten.

Wie lässt sich diese skeptische Gruppe nun überzeugen, doch Tests zu schreiben? Ein großer Vorteil von automatisierten Tests ist die Eigenschaft, dass bei großen Änderungen der Quellcodebasis (Refactoring) die Testfälle automatisch sagen, ob alles korrekt verändert wurde. Denn wenn nach dem Refactoring, etwa einer Performance-Optimierung, die Tests einen Fehler melden, ist wohl etwas kaputt-optimiert worden. Da Software einer permanenten Änderung unterliegt und nie fertig ist, sollte das Argument eigentlich schon ausreichen, denn wenn eine Software eine gewisse Größe erreicht hat, ist nicht absehbar, welche Auswirklungen Änderungen an der Quellcodebasis nach sich ziehen. Dazu kommt ein weiterer Grund, sich mit Tests zu beschäftigen. Es ist der positive Nebeneffekt, dass die erzeugte Software vom Design deutlich besser ist, denn testbare Software zu schreiben ist knifflig, führt aber fast zwangsläufig zum besseren Design. Und ein besseres Design ist immer erstrebenswert, denn das erhöht die Verständlichkeit und erleichtert die spätere Anpassung der Software.

1.1.1 Vorgehen bei Schreiben von Testfällen

Die Fokussierung bei Softwaretests liegt auf zwei Attributen: automatisch und wiederholbar. Dazu ist eine Bibliothek nötig, die zwei Dinge unterstützen muss.

· Testfälle sehen immer gleich aus und bestehen aus drei Schritten. Zunächst wird ein Szenario aufgebaut, dann die zu testende Methode oder Methodenkombination aufgerufen und zum Schluss mit der spezifischen API vom Testframework geschaut, ob das ausgeführte Programm genau das gewünschte Verhalten gebracht hat. Das Übernehmen eine Art „stimmt-es-dass“-Methoden, die den gewünschten Zustand mit dem tatsächlichen Abgleichen und beim Konflikt eine Ausnahme auslösen.

· Das Testframework muss die Tests laufen lassen und im Fehlerfall eine Meldung geben; der Teil nennt sich Test-Runner.

Wir werden uns im Folgenden auf sogenannte Unit-Tests beschränken. Das sind Tests, die einzelne Bausteine (engl. units) testen. Daneben gibt es andere Tests, wie Lasttests, Performance-Tests oder Integrationstests, die aber im Folgenden keine große Rolle spielen.

Weiterlesen

Programmbibliothek für gesprochene Dauern: PrettyTime

Schwierig, einen Titel zu finden, aber wenn ich ein Beispiele gebe wird’s klar, was die LGPL-Bibliothek PrettyTime macht:

PrettyTime p = new PrettyTime();
System.out.println(p.format(new Date())); //prints: “right now”
PrettyTime t = new PrettyTime(new Date(0));
assertEquals("3 hours from now", t.format(new Date(1000 * 60 * 60 * 3)));
PrettyTime t = new PrettyTime(new Date(0));
assertEquals("3 days from now", t.format(new Date(1000 * 60 * 60 * 24 * 3)));
PrettyTime t = new PrettyTime(new Date(0));
assertEquals("3 weeks from now", t.format(new Date(1000 * 60 * 60 * 24 * 7 * 3)));
PrettyTime t = new PrettyTime(new Date(0));
assertEquals("3 months from now", t.format(new Date(2629743830L * 3L)));
PrettyTime t = new PrettyTime(new Date(0));
assertEquals("3 years from now", t.format(new Date(2629743830L * 12L * 3L)));
PrettyTime t = new PrettyTime(new Date(0));
assertEquals("12 minutes from now", t.format(new Date(1000 * 60 * 12)));

Die API kann man auch in JSF nutzen.

<h:outputText value="#{exampleBean.futureDate}">
  <f:converter converterId="com.ocpsoft.PrettyTimeConverter"/>
</h:outputText>

Das ganze gibt es lokalisiert für die Sprachen

  • Dutch – NL
  • English – DEFAULT
  • French – FR
  • German – DE
  • Chinese – ZH_CN
  • Portugese – PT
  • Spanish – ES

Voraussetzung ist Java 6.0. Der Quellcode ist aufgebläht bis zum Umfallen, aber wen das nicht stört, findet in PrettyTime eine kleine nette Bibliothek zur Zeitdarstellung.

Thema der Woche: Hessian und Burlap Protocol

Wow! James Gosling verlässt Sun

Von seinem neuen Blog http://nighthacks.com/roller/jag/entry/time_to_move_on:

Yes, indeed, the rumors are true: I resigned from Oracle a week ago (April 2nd). I apologize to everyone in St Petersburg who came to TechDays on Thursday expecting to hear from me. I really hated not being there. 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. The hardest part is no longer being with all the great people I’ve had the privilege to work with over the years. I don’t know what I’m going to do next, other than take some time off before I start job hunting.