Oli's Blog

Vor einigen Monaten hatten sich die DOAG (Deutsche Oracle Anwendergruppe) und verschiedene Java User Groups (darunter auch die JUGS in einem gemeinsamen Dachverband, der iJUG zusammengeschlossen. Ursprünglich war geplant, die Zeitschrift "Java aktuell" zum Java Forum Stuttgart rauszugeben - das hätte perfekt mit dem Vortrag "Pleiten, Pech und PatternTesting zusammengepasst, da genau zu diesem Thema auch ein entsprechender Artikel drin steht.

Na ja, jetzt sind es halt zwei Monate später. Aber wer Interesse daran hat, die Zeitschrift gibt es noch im gut sortierten Zeitschriftenladen...

Two objects which are equals should return the same hash code (and not the other way around, as some developers think).

...Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

This is corresponding Javadoc about the equals method. For those who forget this PatternTesting offers now an ObjectTester which checks classes with overwitten equals methods:

    ObjectTester.assertEquals(my.little.Dummy.class);

The ObjectTester will create with this call two Dummy objects to check the implementation. If it is not ok an Assertion Error will be thrown.

You can also add a package to check if all classes in the package have a correct equals/hashCode implementation:

    ObjectTester.assertEquals(Dummy.class.getPackage());
    ObjectTester.assertEqualsOfPackage("my.little");

Both calls are identical. You can also exclude classes from this check. This is sometimes necessary for classes where the constructor produces different objects (as is the case for the Date class, for example).

In a similar way you can check classes with the SerializableTester and CloneableTester if they are really serializable or clonable.

Oft steht man vor dem Problem, dass man ein bestehendes Projekt auf Maven umstellen will, ohne die Projekt-Struktur umzustellen. Das geht mit folgendem Eintrag in der POM:

<build>
  ...
  <sourceDirectory>${basedir}/src</sourceDirectory>
  <testSourceDirectory>${basedir}/test</testSourceDirectory>
  <resources>
    <resource>
      <directory>src</directory>
    </resource>
  </resources>
  <testResources>
    <testResource>
      <directory>test</directory>
    </testResource>
  </testResources>
  ...
</build>

In diesem Beispiel liegen die Sourcen unter src und die Test-Sourcen unter test (inkl. der jeweiligen Resource- und Property-Dateien).

Two weeks ago I started to automate the build process for an OpenOffice extension project (Java). I was happy to found a Maven plugin and a description on the OpenOffice wiki. But the last log entry on the CVS page says it: the development was started - that's all.

At github I found an enhancement of this Maven plugin. But the only stuff which was working on my MacBook was 'mvn archetype:create...'. Because I needed the plugin I forked it to my maven-ooo-plugin clone and tried to continue the work of Cédric and Frédéric.

What's working:

• mvn archetype:create (more or less, no changes from my side)
• mvn generate-sources (call of idlc, regmerge and javamaker, see OOo Java Eclipse Tutorial)

What does not work:

• mvn package (creation of OXT, the OpenOffice extension)

I have tested the plugin on MacOS and Linux, but not on Windows (I have no Windows computer). The next steps I plan is to begin with the .oxt creation and to look for a Maven repository where I can deliver it.

Neulich hatte ich das Problem, dass beim Validieren einer XML-Datei immer eine SAXParseException auftrat, sobald Umlaute ins Spiel kamen. Ursache dafür war folgender Aufruf

    validator.validate(new StreamSource(reader))

Marc Guillemot macht mich darauf aufmerksam, dass in den Javadocs zum StreamSource-Konstruktor der folgende Hinweis enthalten ist:

...Normally, a stream should be used rather than a reader, so that the XML parser can resolve character encoding specified by the XML declaration...

Und tatsächlich - nachdem ich den Reader durch einen InputStream ersetzt hatte, lief mein Testfall ohne Fehler durch.

Today PatternTesting 1.0.1 was released. Some feedback from the Java Forum Stuttgart and some minor bug fixes were included. For more info see the release notes.

If you use Maven PatternTesting is not yet sync'd to the Central Maven Repository (the ticket for upload is still "reopened"). So add labs.agentes.de/repository to your POM as described in Build with Maven.

The next event where you can watch PatternTesting live will be probably the gearconf in Düsseldorf. I plan to present a little drama with Christian Heise about a normal day in a developers life.

Stay tuned...

Zusammen mit meinem Kollegen, Christian Heise, hatte ich die Gelegenheit, über PatternTesting in Form eines kleinen Theaterstücks zu referieren. Allerdings wurde aus dem fiktiven Theaterstück bald Realität, als mein Kollege nach dem Vortrag ins Geschäft zurück musste. Die vorgestellten Beispiele sind im Maven-Repository oder im CVS zu finden.

Daneben gab es viele erstklassige Vorträge auf dem Java Forum Stuttgart. Als Mitorganisator war es nicht immer einfach, sich für die richtigen Vorträge zu entscheiden, aber ich denke, es ist uns ganz gut gelungen. Etwas blöd war die Lage des Mozart-Saals, bei dem man erst mal raus in die gleißende Sonne musste, ehe man dann in ein dunkles Loch hinabstieg. Aber von dieser "Umleitung" haben wir leider auch erst kurz vorher von der Messeleitung erfahren. Auf Heise Developer steht ein sehr schöner Artikel über das Java Forum, dem ich mich nur anschließen kann.

Since 0.9.9 end of last year it was quite calm about PatternTesting. But now PatternTesting 1.0.0 is released.

What's new with 1.0.0? For Maven user the group id has changed to "org.patterntesting". While it is not yet sync'd to Maven's default repository you can find it in labs.agentes.de/repository/.

For Non-Maven user the download was now simplified. You need only to download patterntesting-libs-1.0.0-bin.zip from Sourceforge which contains all PatternTesting libraries and the libraries where PatternTesting depends on.

Some of the samples are now documented in the PatternTesting Wiki under Getting Started but are not yet available for download. This will come with PatternTesting 1.0.1. But you can find the sources in CVS below the patterntesting-samples module (the intro and jfs2010 directory).

With PatternTesting 1.0.0 also the home page has moved to patterntesting.org. If you are interested in PatternTesting you can see it also at the Java Forum Stuttgart at 1st July.

Happy PatternTesting...

Bald, bald, bald kommt die neue Eclipse-Version "Helios". Und passend dazu gibt es am 30. Juni ein Eclipse Demo Camp in Stuttgart als kleine Einstimmung auf das Java Forum Stuttgart...

Endlich sind auch die Folien zu "Pleiten, Pech und PatternTesting" fertig. Beide Foliensätze sind in www.agentes.de/download/linuxtag-oliverboehm.zip zusammengepackt.

Nächste Woche geht der Linux-Tag 2010 in Berlin los, auf dem ich mit zwei Vorträgen vertreten sein werde: Java unter Linux - es war einmal... und Pleiten, Pech und PatternTesting. Der Java-unter-Linux-Vortrag am Mittwoch stützt sich im Wesentlich auf den Folien java4linux (pdf, 1,378 KB) , den ich bereits 2003 gehalten habe, ergänzt bzw. korrigiert um die aktuelle Lage von Java unter Linux, die ich in ein eigenes Dokument java4linuxnotizen (pdf, 74 KB) ausgegliedert habe.

Mit dem zweiten Vortrag, "Pleiten, Pech und PatternTesting", bin ich noch nicht ganz fertig, aber da habe ich ja noch bis Samstag, 12. Juni Zeit...

Helsinki - Stuttgart - Budapest - Tel Aviv - London: these are the cities where Oracle comes with its Java Roadshow. Unfortunately I have to work in Bonn. But I know that some people from the JUGS will be there.

Neulich bin ich bei Recherchen zur Privatsphäre im Netz zufällig auf Little Brother von Cory Doctorow gestoßen (und zwar auf die deutsche Übersetzung von Christian Wöhrl). Und dieses Buch hat mich gleich von Anfang an gefesselt. ich musste mehrere Mal aufpassen, dass ich meine Haltestelle nicht verpasste (das letzte Mal, als mir das passiert ist, war Harry Potter Band 6).

Schon die Überschrift (eine Anspielung auf "1984") lässt es erahnen: es geht um den modernen Überwachungsstaat. Das Bedrückende an dem Buch: es ist weniger fiktiv als "1984". Genau so könnte es sich nach dem nächsten Terror-Anschlag abspielen. Das Buch ist spannend geschrieben, und man lernt dabei noch sehr viel über Schutzmaßnahmen im Netz kennen.

Fazit: Unbedingt lesen! Danach wird man die Welt und die Privatsphäre in einem anderen Licht sehen.

Letzte Woche hatte ich mir mal kurz Spring Roo (www.springsource.org/roo) angeschaut. Erster Eindruck:

• scheint so 'ne Art "Ruby on Rails for Java" zu sein
• ist eine Sammlung von "Best Practices" bzw. "Best Tools"
• Abhängigkeiten werden über Maven verwaltet

Spring Roo kommt zwar nur als 4MB große Zip-Datei daher, aber bereits beim Generieren des ersten Projekts werden jede Menge von Bibliotheken und Plugins runtergeladen (Maven lässt grüßen!). Dafür hat man dann eine voll funktionsfähige Web-Anwendung mit JUnit- und sogar (!) Selenium-Tests, das man als fertiges Projekt in Eclipse bzw. die Springsource Toolsuite (= Spring-IDE auf Basis von Eclipse) importieren kann.

Der ersten Begeisterung folgt aber schnell die erste Ernüchterung: sobald man anfängt, den generierten Code erweitern zu wollen, wird man sehr schnell mit den darunterliegende Techniken wie Spring, JPA oder Hibernate konfrontiert. So wurde ich beim Experimentieren mit der generierten Test-Klasse gleich mit Hibernates berühmt-berüchtigter LazyInitializationException konfrontiert, weil ich die Test-Methode nicht als @Transactional gekennzeichnet hatte. Auch bei Erweiterungen an den JSP-Seiten ist man ohne SpringMVC-Kenntnisse aufgeschmissen. Dies Spring Roo anzukreiden wäre aber unfair.

Fazit: Spring Roo ist aus meiner Sicht ein Framework, das in der Java-Welt schon lange überfällig war (auch wenn mit AppFuse ein ähnlicher Ansatz bereits existiert). Es hilf einem, in kurzer Zeit einen Prototypen aufzubauen und weiterzuentwickeln. Es entbindet einen allerdings nicht von der Notwendigkeit, über die verwendeten Technologien Bescheid zu wissen.