Java ist auch eine Insel

Inselupdate: Generics und Arrays

noreply@blogger.com (Christian Ullenboom) — Sun, 18 May 2008 11:06:00 +0000

Die Typlöschung ist der Grund dafür, das Arrays nicht so umgesetzt werden können, wie es sich der Entwickler denkt. Folgendes gibt einen Compilerfehler.

class TwoBox<T>
{
private T[] array = new T[ 2 ]; // Cannot create a generic array of T
T[] getArray() { return array; }
}

Der Grund für diesen Fehler ist dann gut zu erkennen, wenn wir überlegen, zu welchem Programmcode die Typlöschung führen würde:

class TwoBox
{
Object[] array = new Object[ 2 ]; // (1)
Object[] getArray() { return array; }
}

Der Aufrufer würde nun die TwoBox parametrisiert verwenden wollen:

TwoBox<String> twoStrings = new TwoBox<String>();
String[] stringArray = twoStrings.getArray();

Denken wir an diese Stelle wieder an die Typlöschung und an das, was der Compiler generiert:

TwoBox twoStrings = new TwoBox();
String[] stringArray = (String[]) twoStrings.getArray(); // (2)

Jetzt ist es auffällig: Während (1) ein Object-Array der Länge 2 aufbaut und auch getArray() dies als Object-Array nach außen gibt, castet (2) dieses Object-Array auf ein String-Array. Das geht aber nicht, denn diese Beiden Typen sind nicht typkompatibel. Zwar kann natürlich ein Object-Array Strings referenzieren, aber das Feld selbst als Objekt ist eben ein Object[] und kein String[].

Hinweis Die Java-API bietet über Reflection eine Möglichkeit, Arrays eines Typs zu erzeugen:

T[] array = (T[]) Array.newInstance( clazz, 2 );

Allerdings muss der Class-Typ clazz bekannt sein und müsste als zusätzlicher Parameter übergeben werden. Die Syntax T.class gibt einen Compilerfehler, denn über die Typlöschung wäre das ja sowieso immer Object.class, was den gleichen Fehler wie vorher ergibt und kein Fortschritt wäre.

YUI4JSF: JSF-Komponenten auf der Basis der Yahoo UI Library

noreply@blogger.com (Christian Ullenboom) — Sat, 17 May 2008 15:21:00 +0000

YUI4JSF (http://yui4jsf.sourceforge.net/) bietet auf der Basis der The Yahoo! User Interface Library (YUI) neue JSF-Komponenten:

Die Webseite schreibt über das YUI4JSF-Projekt:

Components that wrap around builtin YUI Widgets. YUI has many widgets like calendar, slider, autocomplete, treeview, inputColor and etc. YUI4JSF takes these widgets and provides pure JSF Components which take care of the javascript and server side interaction.

Components powered by YUI Utilities. YUI Utilities like DragDrop Utils are used to create custom components like SortList or Accordion Panel.

AJAX Forms (Beta). YUI4JSF Ajax components like ajaxCommandButton ajaxifies your existing forms in few seconds.

Layout Engine (Experimental). YUI4JSF provides a templating engine that helps creating a flexible layout mechanism in your JSF pages.

Das Demo (http://www.nightdev.devisland.net/yui4jsf-examples) zeigt die Komponenten live. Wenn ich allerdings das Look-and-Feel der YUI-Beispiele mit denen von YUI4JSF vergleiche, kommt YUI4JSF irgendwie schlechter weg.

License: Apache License V2.0

VisualVM 1.0 RC

noreply@blogger.com (Christian Ullenboom) — Sat, 17 May 2008 14:01:00 +0000

Vom VisualVM (https://visualvm.dev.java.net/) gibt es eine erste 1.0 Version.

May 6th, 2008: VisualVM 1.0 RC released. This is mainly a stabilization release: many bugs have been fixed and performance and memory management have been significantly improved. The only new feature is the Start Page which contains useful links to VisualVM documentation and JDK monitoring and troubleshooting guides. Sources for this release are available in release10 branch.

Es sieht so aus, als ob VisualVM in Java 7 als weiteres Tool neben der JConsole einzieht. (Oder vielleicht auch VisualVM sich die JConsole einverleibt und dann VisualVM das "Hauptprogramm" wird. VisualVM erlaubt -- genauso wie auch die JConsole -- Plugins, und eines ist eben für MBeans.)

JSF-Woodstock Komponenten 4.2

noreply@blogger.com (Christian Ullenboom) — Fri, 16 May 2008 18:03:00 +0000

Die quelloffene JSF-Komponenten-Sammlung https://woodstock.dev.java.net/ ist in einer neuen Version 4.2 veröffentlicht. Demos der Komponenten gibt es unter http://webdev2.sun.com/example/faces/index.jsp. Interessant finde ich die Rate-Komponente und das Common Tasks Page.

Buchkritik: Agile Java Development with Spring, Hibernate and Eclipse

noreply@blogger.com (Christian Ullenboom) — Fri, 16 May 2008 09:39:00 +0000

Anil Hemrajani. Sams. ISBN 0-672-32896-8. Mai 2006. 360 Seiten

Lehrbücher, die anhand eines Beispiels versuchen, die agile testgetriebene Softwareentwicklung mit Ant, Hibernate, HSQLDB und Spring (Web mit Spring MVC) zu zeigen, gibt es meines Wissens keins – bis auf dieses. Vielleicht ist das auch kein Wunder, denn schon die Themen Spring/Hibernate füllen dicke Bücher. Hemrajanis Buch will aber gar nicht in die Tiefe gehen, sondern zeigt, wie mit Open-Source Tools ein Online Timesheet System aufgebaut wird. Der Autor streift dabei weitere Technologien, wie die Eclipse IDE, Logging, Profiling, und stellt Links zu vielen Tools übersichtlich am Ende jedes Kapitels vor. Die Zielgruppe für das Buch dürften Personen sein, die bisher mit dem Standard Java gearbeitet haben, und nun lernen wollen, mit welchen Enterprise Technologien sich Web-Anwendungen bauen lassen. Wer eine detaillierte Beschreibung in JUnit, Hibernate und Spring sucht, ist mit dem Buch sicherlich nicht gut beraten. Schade ist auch, dass Hibernate über die HBM.XML-Dateien konfiguriert wird und nicht die Sprachmöglichkeiten über Java 5 (Annotationen) und der JPA-Entity-Manager zum Einsatz kommen. Dass nicht Spring 2 den Kern bildet, ist zu verschmerzen, und das statt Spring MVC nicht Spring WebFlow zum Einsatz kommt ist wohl eher eine Frage des didaktischen Wegs und dem Zeitpunkts des Drucks zu verschulden.

Thema der Woche: Bug-Finder

noreply@blogger.com (Christian Ullenboom) — Thu, 15 May 2008 11:44:00 +0000

Bei jedem Software-Projekt sollte die Qualität über einen langen Zeitraum konstant hoch sein. Insbesondere bei wechselnden Team-Mitgliedern kommen aber schnell Inkonsistenzen in die Sourcen und die Qualität leidet. Code-Analyse Tools versuchen aufgrund bekannter Fehler-Pattern genau diese Schwachstellen zu finden. In Java gibt es eine ganze Reihe von Tools. So führt http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#Java auf:

Bandera — analyzer for Java
Checkstyle — analyze Java and apply coding standard
Classycle — analyze Java class cycles and class and package dependencies (Layers)
FindBugs — an open-source static bytecode analyzer for Java (based on Jakarta BCEL).
Jlint — for Java
PMD (software) — a static ruleset based Java source code analyzer that identifies potential problems.
Soot — A Java program analysis and compiler optimization framework

Für einige Produkte gibt es Eclipse-Plugins. Teste FindBugs in Eclipse/NetBeans. Studiere die Bugs/Schwachstellen, die FindBugs automatisch finden kann.

BGGA Closures werden wohl das Rennen in Java 7 machen

noreply@blogger.com (Christian Ullenboom) — Sat, 10 May 2008 07:20:00 +0000

Beim http://openjdk.java.net/ Projekt ist ein Unterprojekt http://openjdk.java.net/projects/closures/ eingerichtet worden:

This goal of this Project is to produce a feature-complete prototype of the Java bytecode compiler (javac) for the draft BGGA Closures specification. This Project is sponsored by the OpenJDK Compiler Group.

Wenn es also Closures in Java schaffen -- einige Stimmen sagen, dass es dafür noch zu früh ist -- dann wohl diese Syntax. Da das Projekt sehr neu ist, befinden sich in der Mailing-Liste noch nicht viele Nachrichten.

Derweil hat sich die Closures-Spezifikation (Homepage http://www.javac.info/) von der Version 0.5 nicht weiter bewegt und auch die Open Issues sind nicht geklärt.

Interessant ist auch die http://www.javac.info/google-position.html (Neal Gafter ist Angestellter bei Google)

As of April 7, 2008, the following is Google's position on proposals to add support for closures to Java: Google believes Java platform will likely benefit from continued research into closures. To arrive at the best solution, Google is open to multiple parallel investigations but is not currently prepared to commit to any particular proposal. We do not expect these investigations to yield results in time for Java 7, and are of the opinion that it is premature to launch a JSR that forces us down any specific path.

Annotationen in Spring 2.0/2.5 für Autowire und neue Beans

noreply@blogger.com (Christian Ullenboom) — Fri, 09 May 2008 07:51:00 +0000

Bis Spring 2.0 gab es im Wesentlichen nur eine Möglichkeit, Spring-Beans zu deklarieren und Bean-Referenzen zu injizieren. Ab Spring 2.0 und besonders in Spring 2.5 gibt es einen Richtungswechsel. Statt Bean-Definitionen und Injizierungsanweisungen ausschließlich über XML-Dokumente zu beschreiben, kommen Annotationen hinzu. Spring nutzt zum Einen Standard-Annotationen aus Java 6 (Common Annoations) aber auch eigene.

Nehmen wir zwei Beans an:

Die Bean CalendarPrinter soll ein Datum injiziert bekommen.

public class CalendarPrinter {
public void setDate( Date date ) …

Über XML lässt sich das einfach beschreiben, doch seit Spring 2.5 veranlasst eine Annotation Spring dazu, die Verweise automatisch zu injizieren:
@Autowired

@Autowired ist eine Annotation für Methoden und Attribute, damit Spring selbständig den Verweis setzt:

    public class CalendarPrinter {
      @Autowired
      public void setDate(@Qualifier("today") Date d) …
    }

Die Annotation @Qualifier ist nur dann nötig, wenn es mehrere Beans dieses Typs gibt. (Nicht bei uns.)

Damit Spring überhaupt die Verknüpfung vornimmt, ist in der XML-Datei ein Hinweis zu setzen.

Die erste Möglichkeit ist:

Eine im Allgemeinen bessere Alternative (die AutowiredAnnotationBeanPostProcessor und CommonAnnotationBeanPostProcessor zusammenfasst) ist

<context:annotation-config/>

Die Annotation @Autowired ist genauso gültig bei Attributen:

    public class CalendarPrinter
    {
      @Autowired Date date;

      public void doIt()
      {
        System.out.println( date );
      }
    }

Java 6 (für Java 5 ist ein Extra-Jar nötig) führt aus JSR-250 die Lebenszyklus-Annotationen @PostConstruct und @PreDestroy sowie @Resource ein.

    public class CalendarPrinter {
      @PostConstruct public void initialize() {
        System.out.println( "init" );
      }
      /* @PreDestroy public void remove() {
        System.out.println( "destroy" );
      } */
    }

Beans deklarieren

Die Verknüpfung ist durch Autowire automatisiert und minimiert die XML-Konfigurationsdatei.
Zum Deklarieren von neuen Beans bringt Spring ebenfalls Annotationen mit.
Statt in der XML-Datei zu schreiben

<bean id="calendarPrinter"
 class="com.tutego.spring.annotation.CalendarPrinter" />
 können wir annotieren:
 @Component class CalendarPrinter

Damit Spring nach annotierten Beans sucht, ist nötig:

<context:component-scan
base-package="com.tutego.spring" />

Die Annotation @Component ist an allen Typen erlaubt und natürlich zur Laufzeit sichtbar:

    @Target(value=TYPE)
    @Retention(value=RUNTIME)
    @Documented
    public @interface Component
    {
      String value();
    }

API zur Eigenschaft: „The value may indicate a suggestion for a logical component name, to be turned into a Spring bean in case of an autodetected component.“

Geben wir dem CalendarPrinter den Bean-Namen „ cal-printer“:

@Component("cal-printer")
public class CalendarPrinter

Aus dem ApplicationContext genommen folgt:

    ApplicationContext context =
      new ClassPathXmlApplicationContext( … );
    Object bean = context.getBean( "cal-printer" );
    System.out.println( bean.getClass() );
    // class com.tutego.spring.annotation.CalendarPrinter

@Component ist eine sehr allgemeine Annotation.

Besser ist es, semantische Annotationen zu nutzen, die @Component erweitern. Spring liefert drei mit:

1. @Target(value=TYPE) … @Component
public @interface Repository

2. @Target(value=TYPE) … @Component
public @interface Service

3. @Target(value=TYPE) … @Component
public @interface Controller

Borland verkauft CodeGear und damit JBuilder

noreply@blogger.com (Christian Ullenboom) — Thu, 08 May 2008 14:18:00 +0000

Heise schreibt am 7. Mai, dass Borland CodeGear für lächerliche 23 Millionen Dollar an Embarcadero verkauft. Damit geht eine lange Ära von Borland Entwicklungswerkzeugen zuende. Was nun aus dem JBuilder wird, ist damit offen. Embarcadero ist zumindest bei Entwicklern kein Unbekannter, denn das Unternehmen entwickelte das UML-Tool Describe, was in die Sun-IDE eingeflossen ist.

Eclipse 3.4 M7 - letzter Milestone

noreply@blogger.com (Christian Ullenboom) — Thu, 08 May 2008 11:14:00 +0000

Seit dem 2. Mai gibt es den letzten Milestone Eclipse 3.4 M7 vor dem finalen Release geplant im Juni 2008. Die New and Noteworthy lesen sich wie zu erwarten, das heißt, kaum Neuerungen, da es auf die Endversion geht. Interessant ist:

You should see faster Java compile times when using machines with multiple CPUs. The Eclipse Compiler for Java (aka "ecj") is now taking advantage of the multi-threading capability of multi-CPU machines. The full build of a Java project also takes advantage of this support.

Dann noch eine Kleinigkeit:

- Download: http://www.eclipse.org/downloads/index.php

Thema der Woche: Datum und Zeit

noreply@blogger.com (Christian Ullenboom) — Thu, 08 May 2008 11:08:00 +0000

An der Datum/Zeit-API wird schon ewig rumgemeckert, und jetzt soll es wirklich gut werden. Lies zunächst die API-Dokumentation der zentralen Standard-Klassen:

Date
DateFormat
SimpleDateFormat
Calendar
GregorianCalendar

Was sind die Argumente der Kritiker?

http://justinsomnia.org/2007/05/dates-and-java-suck/
http://robsanheim.com/2006/03/13/top-five-worst-apis-in-java/
http://vafer.org/blog/20041128172956 (Java Dates and other crap)

Eine hervorragende Open-Source-Biblitohek ist http://joda-time.sourceforge.net/. Was macht Joda-Time anders/besser?

Die https://jsr-310.dev.java.net/ möchte endlich eine tolle Datums/Zeit-API in das Standard-Java Version 7 bringen. Was unterscheidet Joda-Time von JSR 310?

Neue Video-/Audio-Library

noreply@blogger.com (Christian Ullenboom) — Thu, 17 Apr 2008 13:19:00 +0000

Also wenn

MediaManager.installNativeLibrary(true); // enable file protocol MediaManager.getInstance().registerProtocol(FileProtocol.URL_PREFIX, FileProtocol.FACTORY); // create Swing frame JFrame frame = new JFrame(); frame.setSize(new Dimension(480, 300)); frame.setLayout(new BorderLayout()); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); // add Java2D-based video renderer to Swing frame final IVideoRenderer renderer = new Java2DRenderer(); frame.add(renderer.getVisualComponent()); // show frame frame.setVisible(true); // open movie file & find stream info (resolution, audio channels,...) AVFormatContext formatContext = AVFormatContext.openFile(FileProtocol.computeUrl(new File("samples/elephantsdream.avi"))); formatContext.findStreamInfo(); // create media player final MediaPlayer player = new MediaPlayer(renderer); player.open(formatContext);

alles ist, was man für ein Video abzuspielen bracht, dann prima. pulsar (http://dev.getpulsar.com/) ist eine neue Open-Source Bib mit einer nativen Komponente, zum Abspielen von Audio und Video.

Pulsar includes a media library to encode, decode and playback audio and video files. Pulsar makes use of projects like FFmpeg, X264, liba52, FAAD2 and LAME to support a variety of codecs like MPEG, H.264, AC3 and MP3. The input can be a local file, a HTTP stream or an arbitrary other input implementing IMediaProtocol. The media library is distributed in two files, a Java library "pulsar_media.jar" and a native library "pulsar_media.*". There are precompiled versions of the native library for Windows, Mac OS X and Linux.

Thema der Woche: Inversion Of Control/Dependency Injection

noreply@blogger.com (Christian Ullenboom) — Mon, 14 Apr 2008 18:00:00 +0000

Komponenten müssen in irgendeiner Weise auf Dienste (Services) zurückgreifen. Diese Dienste könnte entweder in die Komponenten injiziert werden oder eine Komponente bezieht den Dienst über eine zentrale Service-Factory. Vergleiche die Ansätze Service-Locator und IoC (Spring-Beispiele).

http://martinfowler.com/articles/injection.html

Spring ist nicht der einzige IoC-Container. Verschaffe einen Überblick über

Ob nun IoC grundsätzlich die Beste Lösung ist, oder ob nicht eine einfache Zentrale reicht, ist Thema von http://lateralprogramming.wordpress.com/2008/04/07/why-use-spring-if-you-have-a-hashmap-at-hand/.

Thema der Woche: Apache Commons

noreply@blogger.com (Christian Ullenboom) — Mon, 07 Apr 2008 08:42:00 +0000

Die Apache-Group hat mit ihren vielen Projekten irgendwann bemerkt, dass sie einige Dinge immer wieder programmieren. So ist nach und nach http://commons.apache.org/ entstanden, ein Projekt, welches viele Hilfsklassen implementiert.

Verschaffe einen groben Überblick über alle Projekte von http://commons.apache.org/, wofür sie da sind und sie leisten.

Vertiefe in http://commons.apache.org/io/ und http://commons.apache.org/lang/ und schaue in die Typbeschreibung jeder Klasse/Schnittstelle.

Programme eine Beispielprogramm, bei dem die toString()-Methode generisch über ToStringBuilder aufgebaut wird.
Schreibe ein paar Demos, die Funktionen aus StringUtils, WordUtils nutzen.
Kopiere eine Datei von einer Stelle zur anderen.
Nutze passende Klassen/Funktionen aus org.apache.commons.io.filefilter um in einem Vergleiche alle Dateien zu finden, die (älter ein als gewisses Datum sind UND über einer gewissen Größe liegen) ODER (auf eine bestimmte Dateiendungen, wie doc oder rtf, enden).

Thema der Woche: Bytecode und Obfuscator

noreply@blogger.com (Christian Ullenboom) — Mon, 31 Mar 2008 10:58:00 +0000

Wie jeder weiß, produziert der Java-Compiler in der Regel Bytecode. Um eine Vorstellung davon zu bekommen, sollte man lesen

Dann je nach Wunsch weitere Kapitel aus der Java Virtual Machine Specification; da ist aber jede Waschmaschine spannender.

Java Bytecode lässt sich disassemblieren, etwa mit javap. Hier sollte man ein Beispiel ausprobieren.

Um den Bytecode unansehnlich zu machen, lässt sich ein Obfuscater einsetzten. Teste die Möglichkeiten von http://proguard.sourceforge.net/ an einem Beispiel.

JVM auf iPhone

noreply@blogger.com (Christian Ullenboom) — Mon, 31 Mar 2008 10:46:00 +0000

Apple ist zwar bisher gegen eine Java VM (und auch gegen Flash -- angeblich zu langsam, hahaha), aber Sun hat eine Implementierung für das iPhone angekündigt:

http://www.infoworld.com/article/08/03/07/sun-iphone-java_1.html
http://www.macworld.com/article/132451/2008/03/sun.html
http://www.javalobby.org/java/forums/t88464.html (Steve Jobs on iPhone: No Java For You)

Da das iPhone auf OS X 10 basiert (http://www.roughlydrafted.com/2007/07/13/iphone-os-x-architecture-the-mach-kernel-and-ram/), ist es durchaus möglich, das Sun auch für "normale" Apple-Computer ein JDK ausliefert. Wenn bei Sun schon Linux, Solaris und Windows dazugehört, passt OS X auch noch ganz gut rein.

Bei Java ist PI dann auch mal 12

noreply@blogger.com (Christian Ullenboom) — Wed, 26 Mar 2008 14:19:00 +0000

Na klar:

Die Lösung: PI ist die XML Processing Instruction. Gefunden auf http://thedailywtf.com/.

Thema der Woche: PDF-Dokumente

noreply@blogger.com (Christian Ullenboom) — Tue, 25 Mar 2008 10:28:00 +0000

PDF ist ein Standard-Dokumentenformat geworden, an dem man nicht vorbeikommt.

http://en.wikipedia.org/wiki/Portable_Document_Format. Ist die PDF-Spezifikation offen oder geschlossen? Konzipiert Adobe oder ein Gremium weitere Versionen?

Java bietet eine Reihe von Bibliotheken an, die PDF-Dokumente verfassen und darstellen. Bekannter sind:

Was sind Bibliotheken zum Anzeigen und Erstellen? Welche Einschränkungen sind bekannt? Was kann man mit http://djproject.sourceforge.net/ns/ machen?

Erstelle mit iText aus den Kurzbeispielen http://itextdocs.lowagie.com/tutorial/ eine PDF mit Absätzen, einfachen Tabellen und Bildern. Zeige die PDF mit dem https://pdf-renderer.dev.java.net/ an.

Microsoft versucht mit dem XPS-Standard (http://en.wikipedia.org/wiki/XML_Paper_Specification) eine Alternative zu etablieren. Gibt es dazu irgendwelche Java-Bibliotheken?

Java Swing Framework hat sich wohl erledigt

noreply@blogger.com (Christian Ullenboom) — Mon, 24 Mar 2008 10:30:00 +0000

Das AppFramework (RI von JSR 296) ist wohl tot. Von Pushing-Pixels:

Hans Muller confirms what many have already guessed. His e-mail on the users mailing list of AppFramework (reference implementation of JSR 296) confirms that the development of this project has been dead since last November and will continue to be so through this summer. The subsequent discussion on the mailing list indicates that it is quite unlikely that somebody will step up and be able to provide leadership that is much needed for JSR-level projects. The inclusion in JDK 7 looks like it’s in jeopardy as well.

Hans Muller schreibt dazu:

I'm the spec lead for JSR-296 and the only developer as well. I've been neglecting the project for the past several months to focus exclusively on Sun's Java FX initiative. You can see the results of some of that work in the Scenario project (http:www.scenegraph.dev.java.net), and before too long in the revised ("Reprise") version of the graphics/UI library for the FX Script language. I'd originally expected to be heads-down on FX for a couple of weeks and then after that return to devoting part of my time to this project. Unfortunately that hasn't happened and it's unlikely to change through this summer.

I'm proud of how far along Application Framework is and it's inspiring to see how the developer community has responded. It's particularly gratifying to see questions asked and answered on this list and proposals floated and discussed. I'd like to restore the project's ability to make some progress, by adding a few developers to the project who'll be able to update the code and make decisions about how to evolve the design. If you're interested and if you feel you have the time and the right kind of experience, please send me an email. I'm going to try and resolve this in the next week or so.

Tja. Hoffentlich bleibt dann das Bean-Binding stehen. Obwohl -- da schreibt Pushing-Pixels weiter:

John O’Connor has an article on Beans Binding (reference implementation of JSR 295). Unfortunately, these two projects are twin victims of JavaFX for the better part of this year, and one could only hope that JavaFX will live up to its promise and to the investment in engineering resources that have been subverted to it.

So viel zum Thema: "Wir bringen Java zurück zum Desktop. In Java 7." Klar.

Thema der Woche: Unicode und Kodierungen

noreply@blogger.com (Christian Ullenboom) — Mon, 17 Mar 2008 12:21:00 +0000

Java verarbeitet Zeichen (bisher) intern in 2-Byte Unicode. Gespeichert werden Daten aber in der Regel in UTF-8 oder, für uns in Europa, in Latin-1. Thema der Woche ist Unicode und die Umkodierungen. Am Anfang sollen The Ten Commandments of Unicode von Elliotte Rusty Harold stehen:

I am Unicode, thy character set. Thou shalt have no other character sets before me.
Thou shalt carefully specify the character encoding and the character set whenever reading a text file.
Thou shalt not refer to any 8-bit character set as “ASCII”.
Thou shalt ensure that all string handling functions fully support characters from beyond the Basic Multilingual Plane. Thou shalt not refer to Unicode as a two-byte character set.
Thou shalt plan for additions of future characters to Unicode.
Thou shalt count and index Unicode characters, not UTF-16 code points.
Thou shalt use UTF-8 as the preferred encoding wherever possible.
Thou shalt generate all text in Normalization Form C whenever possible.
Thou shalt avoid deprecated characters.
Thou shalt steer clear of the private use area.

Da schließen sich nun einige Fragen an, die es zu klären gilt:

Was ist der Unterschied zwischen ASCII, Unicode 2 und Unicode 4?
Was ist ein Code-Point? Welche Funktionen in Java 5 sind wegen Unicode 4 hinzugekommen? Welche beiden Funktionen zum Zugriff auf ein Zeichen gibt es? Resultieren daraus Performance-Unterschiede?
Was ist eine Kodierung? Wie wird sie in Java bestimmt? Durch einen String oder durch eine Klasse?
Welchen Funktionen/Konstruktoren der Java Klassenbibliothek nehmen eine Kodierungskennung entgegeben? Nenne mehrere Wege, wie man Strings/Byte-Felder umkodiert.
Gibt es XML-Parser in Java, die Unicode 4 unterstützten? Was sagen die Autoren von XML-Parsern zu Unicode 4?
Warum kann es beim Datenbankzugriff auf Textspalten Probleme geben? Gibt es dokumentierte Probleme/Lösungen?

Auch neu: tutego's Clip-Art Seite. Links zu weiteren Clip-Art Sammlungen (ohne die lästigen Popup-Menüs) sind willkommen.

Insel: Service-Factory, IoC, Lookup, Generics, Services und alles zusammen

noreply@blogger.com (Christian Ullenboom) — Sat, 15 Mar 2008 11:44:00 +0000

Je größer eine Java-Anwendung wird, desto größer werden die Abhängigkeiten zwischen Klassen und Typen. Um die Abhängigkeiten zu reduzieren, ist zunächst gewünscht, sich nicht so sehr an Implementieren zu binden, sondern an Schnittstellen. (Das gelobte „Programmieren geben Schnittstellen und nicht gegen eine Implementierung.“) Eine Schnittstelle beschreibt dann Dienste, so genannte Services, auf die an anderer Stelle zurückgegriffen werden kann. Die nächste Frage ist, wie ein Service mit Geschäftslogik zu der Stelle kommt, an denen er benötigt wird, etwa auf der grafischen Oberfläche als Aktion hinter einer Schaltfläche. Hier haben sich zwei Wege herausgestellt:

Service-Fabriken. Eine Service-Fabrik ist eine Zentrale, an die sich Interessenten wenden, wenn sie einen Service nutzen wollen. Die Fabrik liefert eine passende Implementierung, die immer eine Service-Schnittstelle implementiert. Welche Realisierung – also konkrete Klasse – die Fabrik liefert, soll den Nutzer nicht interessieren; eben Programmieren gegen Schnittstellen.
Dependency Injection/Inversion of Control (IoC). Nach diesem Prinzip fragen die Interessenten nicht aktiv über eine zentrale Service-Fabrik nach den Diensten, sondern den Interessenten wird der Service über eine übergeordnete Einheit gegeben (injiziert). Die magische Einheit nennt sich IoC-Container. In der Vergangenheit hat sich das Spring-Framework als De-facto-Standard eines IoC-Containers herauskristallisiert.

Arbeiten mit dem ServiceLoader

Java SE bietet bisher keine Bibliothek für Dependency Injection aber mit der Klasse java.util.ServiceLoader eine einfache Realisierung für Service-Fabriken. Ein eigenes Programm soll auf einen Grüß-Dienst zurückgreifen, aber welche Implementierung das sein wird, soll an anderer Stelle entschieden werden.

ServiceLoader<Greeter> greeterServices = ServiceLoader.load( Greeter.class );

for ( Greeter greeter : greeterServices )

System.out.println( greeter.getClass() + " : " + greeter.greet( "Chris" ) );

ServiceLoader erfragt mit load() eine Realisierung, die die Schnittstelle Greeter implementieren soll. Die Realisierung ist der Service-Provider. Greeter deklariert eine greet()-Operation:

package com.tutego.insel.services;

public interface Greeter

{

String greet( String name );

}

Der Service liefert aber eine konkrete Klasse. Demnach muss es irgendwo eine Zuordnung geben, die einen Typnamen (Greeter) mit einer konkreten Klasse, der Service-Implementierung, verbindet. Dazu ist im Wurzelverzeichnis des Klassenpfades ein Order META-INF mit einem Unterordner services anzulegen. In diesem Unterordner ist eine Textdatei (provider-configuration file) zu setzen, die den gleichen Namen wie die Service-Schnittstelle besitzt:

META-INF/

services/

com.tutego.insel.services.Greeter

Diese Textdatei, die keine Dateiendung aufweist, enthält Zeilen mit voll qualifizierten Klassenamen (binary name genannt) für die Implementierung, die später hinter diesem Service stehen. Es kann eine Zeile oder durchaus mehrere Zeilen für unterschiedliche Implementierungen angegeben sein. In der Datei META-INF/services/com.tutego.insel.services.Greeter steht:

com.tutego.insel.services.FrisianGreeter

FrisianGreeter ist demnach unsere letzte Klasse und eine tatsächliche Implementierung des Services:

package com.tutego.insel.services;

public class FrisianGreeter implements Greeter

{

public String greet( String name ) {

return "Moin " + name + "!";

}

Utility-Klasse Lookup als ServiceLoader-Fassade

So nett der ServiceLoader auch ist, die API könnte ein wenig kürzer sein. Denn oftmals gibt es nur eine Service-Implementierung und nicht gleich mehrere. Daher soll eine Fassade eine knackigere API anbieten. Eine kurze Methode lookup() liefern genau den ersten Service (oder null) und lookupAll() gibt alle Service-Klassen in einer Sammlung zurück. (Das Listing nutzt mehrere Dinge, die die Insel bisher nicht vorgestellt hat! Dazu zählen Generics, Datenstrukturen, Iterator, Meta-Objekte.)

public class Lookup

{

public static <T> T lookup( Class<T> clazz )

{

Iterator<T> iterator = ServiceLoader.load( clazz ).iterator();

return iterator.hasNext() ? iterator.next() : null;

}

public static <T> Collection<? extends T> lookupAll( Class<T> clazz )

{

Collection<T> result = new ArrayList<T>();

for ( T e : ServiceLoader.load( clazz ) )

result.add( e );

return result;

}

Die Nutzung vereinfacht sich damit:

System.out.println( Lookup.lookup( Greeter.class ).greet( "Chris" ) ); // Moin Chris!

System.out.println( Lookup.lookupAll( Greeter.class ).size() ); // 1

Unverkennbar ist natürlich der Einfluss der NetBeans-Klasse http://bits.netbeans.org/dev/javadoc/org-openide-util/org/openide/util/Lookup.html.

NetBeans 6.1 Beta

noreply@blogger.com (Christian Ullenboom) — Thu, 13 Mar 2008 13:14:00 +0000

NetBeans entwickelt sich in rascher Geschwindigkeit, und baut besonders den Bereich Wizards gegenüber Eclipse aus.

Einige Neuigkeiten dokumentieren die folgenden Screenshots.

Woodstock-Komponenten:

RESTful Web Service Plugin

JSF CRUD Generator

MySQL Support in Database Explorer

Spring Framework Support (Ob Sun damit über den eigenen Schatten springen muss?)

NetBeans 6.1 has a completely redesigned JavaScript support compared to NetBeans 6.0

Neues aus EJB 3.1

noreply@blogger.com (Christian Ullenboom) — Tue, 11 Mar 2008 12:41:00 +0000

Einige Änderungen aus dem Preview der EJB 3.1 Specification.

Es gibt neu auch Singleton Session Beans, die mit @Singleton annotiert sind:

The EJB specification defines stateful, stateless, and singleton session beans. There are differences in
the API between stateful session beans, stateless session beans, and singleton session beans.

4.7 Singleton Session Beans
A Singleton session bean is a session bean component that is instantiated once per application. In cases
where the container is distributed over many virtual machines, each application will have one bean
instance of the Singleton for each JVM.
Once instantiated, a Singleton session bean instance lives for the duration of the container in which it is
created. It maintains its state between client invocations but that state is not required to survive container
shutdown or crash.

Man kann für lokale Beans auf eine Business-Schnittstelle verzichten:

In EJB 3.x, a local client accesses a session bean through the bean’s local business interface or through
a no-interface client view representing all the public methods of the bean class.

3.4.2 Obtaining a Reference to the No-interface Local View
A client can obtain a reference to a Session Bean’s No-interface Local View through dependency injection
or lookup in the JNDI namespace.
For example, the No-interface Local view of the CartBean session bean with bean class com.acme.Cart-
Bean may be obtained using dependency injection as follows :
@EJB CartBean cart;
The CartBean No-interface view could also be looked up via JNDI as shown in the following code segment
using the lookup method provided by the EJBContext interface. In this example, a reference to
the client bean’s SessionContext is obtained through dependency injection:
@Resource SessionContext ctx;
...
CartBean cart = (CartBean)ctx.lookup(“cart”);
Despite the fact that the client reference for the No-interface Local view has type <bean class> , the client
never directly uses the new operator to acquire the reference.

3.4.4 Session Bean’s No-Interface Local View
A Session Bean’s no-interface view is a variation of the Local view that exposes the public methods of
the bean class without the use of a separate business interface.
A reference to the no-interface view may be passed as a parameter or return value of any Local business
interface or no-interface view method.
The container provides an implementation of a reference to a no-interface view such that when the client
invokes a method on the reference, the business method on the session bean instance and any interceptor
methods are invoked as needed.
Only public methods of the bean class (and any super-classes) may be invoked through the no-interface
view. Attempted invocations of methods with any other access modifiers via the no-interface view reference
result in the javax.ejb.EJBException.
It is invalid to reference a session object that does not exist. If a stateful session bean has been removed,
attempted invocations on the no-interface view reference result in the javax.ejb.NoSuchEJBException.

Neu ist, das eine Session-Bean synchron oder asynchron aufgerufen werden kann:

3.4.8 Asynchronous Invocations
By default, session bean invocations through the Remote, Local, and no-interface views are synchronous,
meaning the client blocks for the duration of the invocation and is returned control only after all
invocation processing has completed. Clients can achieve asynchronous behavior by invoking session
bean methods that have been designed to support asynchrony.

When a client invokes an asynchronous method, the container returns control to the client and continues
processing the asynchronous invocation on a separate thread of execution.

3.4.8.1 Return Values
Asynchronous methods have a return type of void or Future<V>, where V represents the result value
of the asynchronous invocation.
In the case of a Future<V> return type, the object returned to the client is a container provided object.
This object allows the client to retrieve the invocation result value, discover any invocation exception,
or attempt to cancel the asynchronous invocation.

Thema der Woche: Reguläre Ausdrücke

noreply@blogger.com (Christian Ullenboom) — Tue, 11 Mar 2008 11:39:00 +0000

Reguläre Ausdrücke vereinfachen die Abfragen an Strings radikal. Lese zunächst zur Einleitung

Regular Expressions in Java (PPT)

Anschließend sollte man die die API-Doku lesen:

In einer Code-Suchmaschine kann man nun einige Beispiele für Pattern-Nutzung ablesen:

http://www.google.com/codesearch?q=lang%3Ajava+%22pattern.matches%22&hl=de&btnG=Code+suchen

Mehr Beispiele (allerdings auch mit Perl-RegEx, die Java nicht unterstützt) gibt die Seite

http://regexlib.com/

Hier sollte man sich ein paar Beispiele anschauen.

Zum Schluss eine Übung: Schreibe einen RegEx-Ersetzer, der aus einem Satz mit der "Basic text formatting" Regel der Wiki-Syntax (http://wiki.splitbrain.org/wiki:syntax) HTML erzeugt. Also soll aus

**bold**

folgendes werden:

<b>bold</b>

Inselupdate: Quantifizierer mit Wiederholungen, nicht gierige Operatoren

noreply@blogger.com (Christian Ullenboom) — Tue, 11 Mar 2008 10:13:00 +0000

Wiederholungen

Neben Quantifizierern ? (einmal oder keinmal), * (keinmal oder beliebig oft) und + (einmal oder beliebig oft), gibt es drei weitere Quantifizierer, die es erlauben, die Anzahl eines Vorkommens genauer zu beschreiben.

X{n}. X muss genau n-mal vorkommen
X{n,}. X kommt mindestens n-mal vor
X{n,m}. X kommt mindestens n aber maximal m-mal vor

Beispiel Eine E-Mail Adresse endet mit einem Domain-Namen, der 2 oder 3 Zeichen lang ist.

static Pattern p = Pattern.compile( "[\\w|-]+@\\w[\\w|-]*\\.[a-z]{2,3}" );

Gierige und nicht gierige Operatoren

Die drei Operatoren ?, * und + haben die Eigenschaft, die längste mögliche Zeichenfolge abzudecken – das nennt sich gierig (engl. greedy). Deutlich wird diese Eigenschaft, bei dem Versuch, in einem HTML-Strings alle fett gesetzten Teile zu finden. Gesucht ist also ein Ausdruck, der im String

String string = "Echt fett. Cool!";

die Teilfolgen fett und Cool erkennt. Der erste Versuch für ein Programm:

Pattern pattern = Pattern.compile( ".*" );

Matcher matcher = pattern.matcher( string );

while ( matcher.find() )

System.out.println( matcher.group() );

Nun ist die Ausgabe aber fett. Cool! Das verwundert nicht, denn mit dem Wissen, dass * gierig ist, passt .* auf die Zeichenkette vom ersten bis zum letzten .

Die Lösung ist der Einsatz eines nicht gierigen Operators (auch „genügsam“, „zurückhaltend“, „non-greedy“, „reluctant“ genannt). Dieser Operator bekommt einfach hinter dem Qualifizierer ein Fragezeichen gestellt.

Mit diesem nicht-gierigen Operator lösen wir einfach das Fettproblem:

Pattern pattern = Pattern.compile( ".*?" );

Matcher matcher = pattern.matcher( "Echt fett. Cool!" );

while ( matcher.find() )

System.out.println( matcher.group() );

Die Ausgabe ist:

fett

Cool