Vom Quellcode-Checker Checkstyle gibt es eine neue Version 5. Die Änderungen beschreiben die Seite http://checkstyle.sourceforge.net/releasenotes.html.

The following checks were added since release 4.4:

• AnnotationUseStyle
• MissingDeprecated
• MissingOverride
• PackageAnnotation
• SuppressWarnings
• EqualsAvoidNull
• NoClone
• NoFinalizer
• AvoidStaticImport
• JavadocPackage
• ClassTypeParameterName
• MethodTypeParameterName
• RegexpMultiline
• RegexpSingleline
• RegexpSinglelineJava
• OuterTypeNumber
• FileTabCharacter
• GenericWhitespace

Die Infos gibt es unter http://kentbeck.github.com/junit/doc/ReleaseNotes4.8.html. Die Änderungen halten sich in Grenzen:

Summary of Changes in version 4.8

Categories

From a given set of test classes, the Categories runner runs only the classes and methods that are annotated with either the category given with the @IncludeCategory annotation, or a subtype of that category. Either classes or interfaces can be used as categories. Subtyping works, so if you say @IncludeCategory(SuperClass.class), a test marked @Category({SubClass.class}) will be run.

You can also exclude categories by using the @ExcludeCategory annotation

Example:

public interface FastTests { /* category marker */ }
public interface SlowTests { /* category marker */ }

public static class A {
    @Test
    public void a() {
        fail();
    }

    @Category(SlowTests.class)
    @Test
    public void b() {
    }
}

@Category({SlowTests.class, FastTests.class})
public static class B {
    @Test
    public void c() {

    }
}

@RunWith(Categories.class)
@IncludeCategory(SlowTests.class)
@SuiteClasses( { A.class, B.class }) // Note that Categories is a kind of Suite
public static class SlowTestSuite {
  // Will run A.b and B.c, but not A.a
}

@RunWith(Categories.class)
@IncludeCategory(SlowTests.class)
@ExcludeCategory(FastTests.class)
@SuiteClasses( { A.class, B.class }) // Note that Categories is a kind of Suite
public static class SlowTestSuite {
  // Will run A.b, but not A.a or B.c
}

Bug fixes

• github#16: thread safety of Result counting

• Doku ist hier: http://docs.jboss.org/hibernate/stable/validator/reference/en/html_single/
• Download unter https://www.hibernate.org/6.html
• Die JSR-Seite: http://jcp.org/en/jsr/detail?id=303

Wer von den ganzen Apache Commons * noch immer nicht genug hat, kann einen Blick auf http://code.google.com/p/guava-libraries/ werden. Lauf Webseite „This project contains several of Google’s core Java libraries that we use in our myriad Java projects.“ Die Folien (http://guava-libraries.googlecode.com/files/Guava_a_sketchy_overview.pdf) geben Beispiele für einige Pakete der Libs:

Mir gefällt besonders gut, das moderne API-Design. Ein Blick ist es wert! Die Doku gibt es unter http://guava-libraries.googlecode.com/svn/trunk/javadoc/index.html. Die Folien versprechen auch eine Unterstützdung von GWT — das wäre wirklich interessant.

Findbugs http://findbugs.sourceforge.net/ hat die Versionsnummer erhöht und unter anderem neue Detektoren aufgenommen. Von der Webseite:

• New bug patterns; in some cases, bugs previous reported as other bug patterns are reported as instances of these new bug patterns in order to make it easier for developers to understand the bug reports
  • BC_IMPOSSIBLE_DOWNCAST
  • BC_IMPOSSIBLE_DOWNCAST_OF_TOARRAY
  • EC_INCOMPATIBLE_ARRAY_COMPARE
  • JLM_JSR166_UTILCONCURRENT_MONITORENTER
  • LG_LOST_LOGGER_DUE_TO_WEAK_REFERENCE
  • NP_CLOSING_NULL
  • RC_REF_COMPARISON_BAD_PRACTICE
  • RC_REF_COMPARISON_BAD_PRACTICE_BOOLEAN
  • RV_RETURN_VALUE_OF_PUTIFABSENT_IGNORED
  • SIC_THREADLOCAL_DEADLY_EMBRACE
  • UR_UNINIT_READ_CALLED_FROM_SUPER_CONSTRUCTOR
  • VA_FORMAT_STRING_EXPECTED_MESSAGE_FORMAT_SUPPLIED
• Providing a bug rank (1-20), and the ability to filter by bug rank. Eventually, it will be possible to specify your own rules for ranking bugs, but the procedure for doing so hasn’t been specified yet.
• Fixed about 45 bugs filed through SourceForge
• Various reclassifications and priority tweaks
• Added more bug annotations to a variety of bug reports. This provides more context for understanding bug reports (e.g., if the value in question was is the return value of a method, the method is described as the source of the value in a bug annotation). This also provide more accurate tracking of issues across versions of the code being analyzed, but has the downside that when comparing results from FindBugs 1.3.8 and FindBugs 1.3.9 on the same version of code being analyzed, FindBugs may think that mistakenly believe that the issue reported by 1.3.8 was fixed and a new issue was introduced that was reported by FindBugs 1.3.9. While annoying, it would be unusual for more than a dozen issues per million lines of codes to be mistracked.

Steve Ebersole schreibt auf seinem Blog http://in.relation.to/12153.lace dazu:

This is the first release towards supporting JPA 2. Most of the APIs are implemented. Some know limitations for this beta include:

• Some of the ‚metamodel‘ APIs are still unimplemented, specifically differentiating between declared attributes and attributes (same wording as java.lang.reflect). The getDeclaredXYZ methods simply return null in this release.
• ‚criteria‘ query building is fully implemented aside from defining subquery correlations, to the best of my knowledge and current state of the spec. However, compiling criteria queries is unimplemented scheduled for the next release.

Additionally, initial support for fetch profiles has been added in this release. Currently only join-fetching is supported as a strategy in fetch profiles.

The artifacts have all been published to the JBoss Maven repository. Additionally the release bundles have been uploaded to SourceForge.

This is also the first version bundling annotations, entitymanager and envers together with the other core modules. Moving forward all will be versioned and released together.

Die Ankündigung von SpringSource liest sich so:

Together, VMware and SpringSource plan to further innovate and develop integrated Platform as a Service (PaaS) solutions that can be hosted at customer datacenters or at cloud service providers. These solutions will allow customers to rapidly build new enterprise and web applications and run and manage these applications in the same dynamic, scalable and cost-efficient vSphere-based internal or external clouds that can also host and manage their existing applications, providing an evolutionary path to the future.

Seit einem Monat gibt es EventBus 1.3. Die Webseite spricht im Wesentlichen von zwei Neuigkeiten:

Mein Blog-Eintrag und Folien stellen das nette Projekt vor:

• http://www.tutego.com/blog/javainsel/2009/03/einfuhrung-in-den-eventbus.html
• http://www.slideshare.net/tutego/einfhrung-in-den-eventbus?type=powerpoint

In meiner Seminarverwaltungssoftware können Trainer die Seminarbeschreibungen ändern. Natürlich möchte ich mitbekommen, welche Stellen geändert wurden und das am Liebsten hübsches aufbereitet. Da bin ich auf http://code.google.com/p/daisydiff/ gestoßen. Man kann entweder über die Kommandozeile arbeiten oder mit einer Hilfsklasse, wobei zwei Klassen einen ersten Anhaltspunkt für die API geben:

• http://code.google.com/p/daisydiff/source/browse/trunk/daisydiff/src/java/org/outerj/daisy/diff/Main.java
• http://code.google.com/p/daisydiff/source/browse/trunk/daisydiff/src/java/org/outerj/daisy/diff/DaisyDiff.java

Ein kleines Beispiel soll das Diff in HTML-Form in den Temp-Ordner C:\Users\CHRIST~1\AppData\Local\Temp\ schreiben:

package com.tutego.traida;

import java.awt.Desktop;
import java.io.File;
import java.io.FileWriter;

import org.outerj.daisy.diff.Main;

public class DaisyDiffDemo
{
  public static void main( String[] args ) throws Exception
  {
    String html1 = „Eine zwei Polizei“;
    String html2 = „Eins zwei drei Polizei“;

    File fileIn = File.createTempFile( „daisyin“, „.html“ );
    File fileOut = File.createTempFile( „daisyout“, „.html“ );
    File fileDiff = File.createTempFile( „daisydiff“, „.html“ );
    new FileWriter( fileIn ).append( html1 ).close();
    new FileWriter( fileOut ).append( html2 ).close();

    String[] daisyDiffArgs = {
      fileIn.getAbsolutePath(), fileOut.getAbsolutePath(), „–file=“+fileDiff.getAbsolutePath()
    };
    Main.main( daisyDiffArgs );

    fileIn.deleteOnExit();
    fileOut.deleteOnExit();
    Desktop.getDesktop().open( fileDiff );
  }
}

Das generierte HTML greift auf allerlei Zeugs zurück. Damit die HTML-Datei gut angezeigt wird, einfach aus dem Zip die Order css, images und js in das temp-Verzeichnis C:\Users\CHRIST~1\AppData\Local\Temp kopieren. Dann sieht das Ergebnis so aus:

Auf Jazoon09 (Präsentation: http://docs.google.com/Present?docid=dcc9m6z9_1524fzspccfp) wurde ein Projekt vorgestellt, wie 4 Millionen Zeilen COBOL erfolgreich nach Java konvertiert werden konnten. (infoQ http://www.infoq.com/news/2009/07/cobol-to-java hat die Links). Im Zentrum der Konvertierung steht der Konverter (83.000 Quellcodezeilen, fast 700 Klassen), das zusammen mit der Laufzeitbibliotheken (153k Zeilen, fast 900 Klassen) auf COBOL-Programme übersetzt und ausführt. Die COBOL-Masken werden in HTML übersetzt.

Die GPL-Projekte sind unter http://code.google.com/p/naca/ zu finden (aber nicht im Source als SVN).

Von der Webseite:

JaQue provides an infrastructure for Microsoft LINQ like capabilities on Java platform. Using ASM, JaQue builds expression trees, which are used to build a query in domain specific technology or language, such as SQL. This way Java developers can focus on writing application logic in the language they know – Java, regardless what the underlying technology or language is in use. JaQue to Objects and JaQue to XML are currently supported and JaQue to JPA is under development.

Ein Beispiel macht das praktisch deutlich:

EntityManagerFactory emf = Persistence.createEntityManagerFactory("hibernate");
  EntityManager em = emf.createEntityManager();
  JaqueEntityManager jem = new JaqueEntityManager(em);
  Queryable<Order> orders = jem.from(Order.class);

  System.out.println(count(where(new Predicate<Order>() {
        public Boolean invoke(Order t) throws Throwable {
                return t.getOrderID() > 11000;
        }
  }, orders)));

Wie bei LINQ soll eine eine API für die verschiedenen Datenquellen geben, also XML, Objekte, Datenbanken, … Für JPA schreibt die Seite “Currently it’s able to perform only simple SELECTs, JOINs and AGGREGATEs”. Das ist natürlich nicht viel. Insofern ist diese Lösung WEIT von den LINQ to SQL-Möglichkeiten entfernt.

Der Hinweis der Webseite auf “Interoperability with Java Closures” ist natürlich hinfällig. Dadurch, dass Closures aber wegfallen, wird die ganze API viel aufgeblähter, als wenn man Closures hätte. Die Scala-Variante ist daher auch viel kürzer.

PS: Die nächsten 2 Wochen gibt es keine Blog-Einträge, da ich ich Afrika bin.

Für unseren Seminarbetrieb erstellen wir nach dem Seminarabschluss aus einer XML-Datei die Rechnung und Zertifikate für den Kunden. Die Vorlagen sind in OpenOffice verfasst und können ohne Probleme verändert werden. Ein großer Vorteil ist weiterhin, dass OO einen PDF Exporter mitbringt.

Der Nachteil der Lösung, OpenOffice für die PDF-Erzeugung fernzusteuern ist, dass es sehr schwergewichtig. OO muss installiert und gestartet werden. Das ist auf einem Server, etwa einem einfachen Servlet-Container oder sogar der Google App Engine for Java natürlich nicht denkbar.

Ein anderer Weg ist daher, zwar weiterhin OpenOffice für die Erstellung einer Vorlage zu verwenden, aber beim PDF-Export anders vorzugehen. Die Lösungen können Acrobat Forms (Acroforms) bieten, also eigentlich interaktive Felder, die man später über ein Programm füllen kann. Im ersten Schritt erzeugt man daher mit OpenOffice Draw eine Formular. (Das wird etwa beschrieben unter http://www.devx.com/opensource/Article/38178/.) Dann exportiert man das Dokument in PDF unter Erhaltung der Formulareigenschaften. Dieses PDF lässt sich nun mit iText auslesen, die Formularzellen füllen und wieder als PDF schreiben. Dabei kann die “Formulareigenschaft” wegfallen, dass man später bei dem PDF-Dokument nichts mehr von interaktiven Elementen sieht.

import java.io.FileOutputStream;
import com.lowagie.text.pdf.*;

public class FillInPdfForm
{
  public static void main(String[] args) throws Exception
  {
    PdfReader reader = new PdfReader(„c:/rein.pdf“);
    PdfStamper stamper = new PdfStamper(reader, new FileOutputStream(„c:/raus.pdf“));
    BaseFont font = BaseFont.createFont(„c:\\windows\\fonts\\Calibri.ttf“, BaseFont.CP1252, BaseFont.NOT_EMBEDDED);
    AcroFields form = stamper.getAcroFields();
    for( Object o : reader.getAcroForm().getFields() )
      form.setFieldProperty( ((PRAcroForm.FieldInformation) o).getName(), „textfont“, font, null);
    form.setField(„name“, „Christian Ullenboom“);
    form.setField(„content“, „Brav sein\nLieb sein“);
    stamper.setFormFlattening(true);
    stamper.close();
  }
}

Etwas lästig ist, dass beim Ausfüllen der in OO zugewiesen Font flöten geht. Daher muss man diesen neu zuweisen. Sonst ist es Arial/Helvetica.

Zum Zugriff auf Dokumente und Spreadsheets von OpenOffice ist http://www.jopendocument.org/ eine GPL-Bibliothek, die das mit einer einfachen API unterstützt. Etwa das laden und verändern von Spreadsheets:

File file = new File( „c:/in.ods“ );
SpreadSheet createFromFile = SpreadSheet.createFromFile( file );
Sheet sheet = createFromFile.getSheet( 0 );
sheet.setValueAt( „Filling test“, 1, 1 );
sheet.getCellAt( „A1“ ).setValue( „On site support“ );
sheet.getCellAt( „I10“ ).setValue( new Date() );
sheet.getCellAt( „F24“ ).setValue( 3 );

File outputFile = new File( „c:/out.ods“ );
sheet.getSpreadSheet().saveAs( outputFile );

Weitere Beispiele gibt http://www.jopendocument.org/documentation.html.

Interessant ein ein purer Java-Viewer, und damit die Möglichkeit in PDF zu exportieren, ohne dass man OO dazu fernsteuern muss.

Beim Testen der SpreadSheet-API sind mir leider einige Nachteile aufgefallen:

• Es gibt keine Named References
• Die API ist sehr Datei-orientiert. Nur im Speicher Dokumente anzulesen und zu verarbeiten ist nicht möglich. Ich sehe erst einmal keine Methode, wie ein Servlet z.B. sich den InputStream auf ein OO-Dokuments holen und als OutputStream an den Client verschicken kann, ohne dass man vorher das OO-Dokument in eine Datei schreibt.
• Soll der eingebauter Viewer verwendet werden, können TIFF-Bilder nicht angezeigt werden.
• GPL könnte für einige Bereiche ein Problem sein. Es werden aber kommerzielle Lizenzen verkauft.