Scheduling Junit tests with RunnerScheduler for a concurrent execution | junit.org

Super.

• SCJP: Ich  hab mal angefangen da das Buch durchzulesen und werd das dann mit Marc und Stephan auch durchziehen, inkl. Prüfung. Mein Chef hat mir dann noch BlackBelt empfohlen.
• SingStar: Ich bin ja stolzer Besitzer einer Playstation und wir (d.h. meine Arbeitskollegen und ich) haben schon eine Party veranstaltet. Morgen findet die nächste Iteration statt und, so wie es aussieht, werden wir das alle zwei Wochen durchziehen
• Code Review: Haben wir jetzt schon zweimal durchgeführt. Gibt immer wieder spannende Diskussionen, manchmal auf Quellcode-Ebene, manchmal eher auf Prozess-Ebene. Aber immer gut und hitzig
• Speeddating: Einmal durchgeführt. Mal schauen wie es sich entwickelt

Das wars auch schon. Da ich vermutlich bis Weihnachten nichts Neues schreiben werden, wünsche ich einfach mal:

FROHE WEIHNACHTEN

Details des Java-Memory-Modells: volatile-, final- und atomic-Felder - Angelika Langer
Das war ein spannender Vortrag. Was genau bewirken eigentlich diese Felder? Inwiefern geben sie Garantien ab? Was können Sie leisten und was nicht? Welche kann man in manchen Fällen als synchronised-Ersatz verwenden? Da ich diese drei Felderbezeichner bisher noch nie wirklich verwendet hatte (ausser final), fand ich es unglaublich faszinierend mal ein bißchen stärker in Thread-/Parallelprogrammierung reinzuschnuppern. Ich empfehle als Lektüre da auch mal

• http://www.torsten-horn.de/techdocs/java-concurrency.htm#Irrtuemer
• http://www.java-blog-buch.de/0407-weitere-modifizierer/

WJAX-Challenge
http://it-republik.de/jaxenter/wjax09/challenge

Why the next five years will be about languages - Ted Neward

Sehr witziger Vortrag über Sprachen an sich. Natürlich auch über den Hype namens DSL (Domain Specific Languages), aber prinzipiell darüber das nicht jede Sprache die Endlösung ist, das viele Sprachen überleben werden, obwohl sie keiner will und das es neue Sprachen geben wird, die jetzt noch keiner kennt. Quintessenz am Ende: Wer sich jetzt nicht um Sprachen kümmert, brauch später auch nur noch einen Satz: "Would you like fries with that".

Back to the Basics: Anwendungen auf Basis von EJB 3.1 - Dirk Well

Ein kleiner Einführungskurs in EJB 3 mit Hinweisen was in EJB 3.1 noch dazu kommen wird. Im Prinzip nichts besonderes, da kann man auch einfach die Spezifikation lesen (wie fast immer ), allerdings war es ganz nett mal eine Zusammenfassung zu sehen. Interessant könnte das @Asychnronous sein, das dann mit Future-Objekten arbeiten. Muss ich mir nochmal genauer anschauen. Weiterhin dazu kommt dann noch @Singleton, wobei diese leider nur Clusternode-eindeutig sind, bzw. JVM-eindeutig. Bißchen doof, wenn man fast nur mit Clustern arbeitet. Muss man halt schauen wie man die synchronisiert.
Weiterhin wurden cronjobs neu entdeckt. Nennt sich in EJB 3.1 dann Timer und lässt sich (fast) beliebig steuern. Find ich halt faszinierend wie man alten Wein einfach in neue Schläuche packt und das dann als "Feature" verpackt. Wow. Timer

42 für Softwarearchitekten - Dr. Gernot Starke
Da verweis ich grad einfach mal auf http://arc42.de/. Im Prinzip ein sehr interessanter Vortrag über Projektdokumentation (also nicht nur das Benutzerhandbuch, sondern alles inkl. Requirements und Technische Konzepte). Da gibt's ein Template zum Runterladen, das gerade mal 30 Seiten (oder so) hat, das einem eine Struktur vorgibt wie man ein Projekt beschreiben kann. In der Theorie eine super Sache, allerdings glaube ich nicht, das man irgendeinen Vorgesetzten davon überzeugen kann, dass man erstmal eine Woche lang ein Template ausfüllt um dann (weil agil und so), nochmals pro Woche einen Tag zu verbraten um das auf den neusten Stand zu bringen. Chefs wollen schnell was und das so billig wie möglich.

The Future of Enterprise Java - Adam Bien
Lange Keynote. Muss ich mir nochmal genau Gedanken machen was da alles gesagt wurde. Im Prinzip nix Überwältigendes, meist nette trends.google.com-Graphiken, gepaart mit ein paar Fakten "aus der Wirtschaft". Klingt jetzt viel abfälliger als es war. An eine Sache erinnere ich mich noch: Single Vendor wird wohl (leider) kommen. Also, Cloud und so: Application Server, JPA-Implementation und/oder andere Libraries von einem Hersteller. Ich nenne hier einfach mal Red Hat aka Jboss.

Hibernate Search: Full-text search for Hibernate Applications - Emmanuel Bernard
Ein Hibernate Interface für Lucene. 'nough said.
Ne, ernsthaft: Eigentlich eine sehr abgefahrene Sache, weil es die Lucene-Machine einfach komplett wegkapselt. Man kann das quasi als normale DataSource sehen, die dann per EntityManager angesprochen wird und auch Query und ResultLists nutzt. Faszinierend. Ausserdem wird dann auch bei einem Datenbankupdate automatisch die Änderung in den Lucene-Index propagiert.

JCR: Java Content Repositories - Carsten Ziegeler
Da der Marc da bissle seine DA drüber geschrieben hat (oder so ähnlich), hab ich mir das auch mal angeguggt. Ist jetzt keine besondere Präsentation gewesen, eigentlich nur eine Beschreibung WAS ein Content Repository ist und das JCR 2.0 relativ frisch raus ist. Schaunmermal.

CouchDB, die REST-basierte Datenbankalternative fürs WEB 2.0 - Frank Pientka
Was ein komisches Ding. Eine JSON-Datenbank. Man erstellt einfach ein JSON-Dokument und packt das dann in die CouchDB. Nutzt das Map&Reduce das irgendwie wohl Google entwickelt hat. Das ist jetzt grobes Halbwissen, müsste man mal genauer recherchieren. Ich finds aber irgendwie komisch, weil das "eigentlich" nur eine JSON-Datenbank ist, mit REST-Interface. Ein GET ist also ein SELECT, ein POST ist ein INSERT usw. Ohne Sicherheitsmechanismus, Login oder sonstirgendwas. Wer die URL kennt, darf alles machen. Doofes Konzept irgendwie.

NACHTRAG: Es gibt wohl doch ein Sicherheitsmodell. Es gibt Admin-Accounts, einen Lese- und einen Schreibzugriff. Allerdings wurde davon, soweit ich mich erinnere, nichts im Vortrag erwähnt. Nur das man halt einen HTTP-Proxy davor schalten sollte, um Sicherheitsfeatures reinzubringen. Quelle: http://couchdb.apache.org/docs/overview.html

Was schafft man in 60 Minuten - Live "on stage" hacking for Java EE 6 - Adam Bien
Geile Sache. In 60 Minuten einfach mal EJB 3.1, JPA 2.0, JSF 2.0, JMS einen Junit-Test mit EJBContainer-Mockup und ein JSF-Redirect. Und das ganze dann noch per REST und Webservice erreichbar. Damit gewinnt dieser Beitrag das Bullshit-Bingo des Tages

Das wars dann erstmal für heute, ich geh mal mein Bier auffüllen

<?xml version="1.0"?>
<project name="FatJar MySuperDuperClass.jar (experimental)" default="main" basedir=".">
    <!-- this file was created by Fat-Jar Eclipse Plug-in -->
    <!-- the ANT-Export is in a very early stage, so this -->
    <!-- is only experimental, ANT 1.6 or above is        -->
    <!-- required, feedback is always welcome:            -->
    <!--       http://sourceforge.net/projects/fjep       -->
    <!-- uncomment the following lines if using ANT outside Eclipse -->
    <!--
        <property name="fjepPath" value="plugins/net.sf.fjep.fatjar_0.0.31/fatjar.jar"/>
        <taskdef name="fatjar.build" classname="net.sf.fjep.anttask.FJBuildTask" classpath="${fjepPath}"/>
        <typedef name="fatjar.manifest" classname="net.sf.fjep.anttask.FJManifestType" classpath="${fjepPath}"/>
        <typedef name="fatjar.exclude" classname="net.sf.fjep.anttask.FJExcludeType" classpath="${fjepPath}"/>
        <typedef name="fatjar.jarsource" classname="net.sf.fjep.anttask.FJJarSourceType" classpath="${fjepPath}"/>
        <typedef name="fatjar.filesource" classname="net.sf.fjep.anttask.FJFileSourceType" classpath="${fjepPath}"/>
    -->
    <!-- uncomment the above lines to use ANT outside of Eclipse -->
    <target name="main">
      <fatjar.build output="MySuperDuperClass.jar">
        <fatjar.manifest mainclass="de.schwobeseggl.test.MySuperDuperClass"/>
        <fatjar.filesource path="bin" relpath=""/>
        <fatjar.jarsource file="lib/commons-cli.jar" relpath=""/>
        <fatjar.jarsource file="lib/jbossall-client.jar" relpath=""/>
        <fatjar.jarsource file="lib/junit.jar" relpath=""/>
        <fatjar.jarsource file="lib/log4j.jar" relpath=""/>
        <fatjar.jarsource file="lib/jdom.jar" relpath=""/>
       </fatjar.build>
    </target>
</project>

Schön und gut, das geht aber nur innerhalb von Eclipse. Auch wenn man obigen Hinweis folgt und die Zeilen einkommentiert, klappt es nicht, es kommt die Fehlermeldung:

BUILD FAILED
/my/path/MySuperDuperClass/build.xml:42: fatjar.build doesn't support the nested "fatjar.filesource" element.

Doof. Die Lösung ist relativ einfach, aber erst nach langer Suche hab ich sie gefunden: Einfach ein loaderref="${fjepPath}" in jedes typedef rein. Somit wird aus:

<typedef name="fatjar.manifest" classname="net.sf.fjep.anttask.FJManifestType" classpath="${fjepPath}"/>

ein

<typedef name="fatjar.manifest" classname="net.sf.fjep.anttask.FJManifestType" classpath="${fjepPath}" loaderref="${fjepPath}" />

String[] allowed = new String[] {"text/html", "text/json"};

Aber was ist mit Maps?

public class Router {
  public static final Map<String, Handler> routes;

  static {
    Map<String, Handler> map = new HashMap<String, Handler>();
    map.put("/account", new AccountHandler());
    map.put("/feed", new FeedHandler());
    map.put("/opml", new OpmlHandler());
    routes = Collections.unmodifiableMap(map);
  }
}

Find ich gut. Endlich weiß ich sowas auch. Noch schneller gehts mit:

public static final Map<String , Handler> routes =
           new HashMap<String , Handler>() {{
    put("/account", new AccountHandler());
    put("/feed", new FeedHandler());
    put("/opml", new OpmlHandler());
}};

• add(int, int)
• roll(int, int)

Was ist der Unterschied? Letztendlich machen beide etwas Ähnliches, nämlich das Erhöhen/Erniedrigen eines Datums um einen Wert. Bei roll() werden nur die "größeren" Einheiten so gelassen wie sie sind. D.h. (laut API) das beim 31. August 1999 ein roll(Calendar.MONTH, 8 ) im 30. April 1999 endet (weil die Jahres-Einheit "größer" ist als die Monats-Einheit). Der Tag wird nur deshalb verändert, weil der 31. April nicht existiert und so das Nächstbeste genommen wird.

Ein add(Calender.MONTH, 8 ) führt allerdings dazu, dass die nächst größere Einheit bei Bedarf angepasst wird, d.h. aus dem 31. August 1999 wird dann der 30. April 2000.

Ein Kollege merkt sich den Unterschied so: Wie beim Zahlenschloß. Das hilft nicht bei add(), aber bei roll() wird ja auch jeweils nur der eine Ring des Zahlenschloß weiterge"roll"t und der Rest bleibt unbeeinflußt.

Zusätzlich noch ein Hinweis: Calendar.MONTH ist null-basiert, d.h. geht von 0-11 und 2 ist der März. Ein Calendar.getInstance().getTime().toLocaleString() passt das allerdings "intern" an und bei der Ausgabe ist dann der März wieder der 3. Monat des Jahres.

So geschehen mit Eclipse und JUnit. Eclipse nutz ich in Version 3.4.2 und JUnit in 4.3.1. So weit so gut. Eclipse hat jetzt eine wunderbare Integration von JUnit. Man kann, in der Theorie, sowohl alle Tests einer Suite ausführen, oder auch nur einen. Ausser man macht das so wie ich:

public class TestClient {
  public static junit.framework.Test suite() {
    return new JUnit4TestAdapter(RMITestClient.class);
}

  public static void main(String[] args) {
    junit.textui.TestRunner.run(suite());
  }

  @Test
  public void someTest {
    Value value = getSomeAction();
    assertTrue("should be true", value);
  }

  @Test
  public void someOtherTest {
    Value value = getSomeAction();
    assertTrue("should be true", value);
  }
}

So, wie man sieht, habe ich zwei Tests (mit der @Test-Annotation) und zwei Funktionen die die Abwärtskompatibiliät für JUnit <4.0 geben soll. Irgendwo ausm Internet[tm]. Nunja, mit diesen beiden Abwärtskompatibilitätsfunktionen kann die Eclipse-UI nicht mehr nur einzelne Tests ausführen, sondern führt den einen Test den man markiert aus, und dann den Rest trotzdem. Suboptimal. Deswegen einfach die Funktionen sich schenken, die Abwärtskompatibilität ebenso und dann klappt's auch mit den Nachbarn.