Thema der Woche: Google Web Toolkit (GWT)

Das Google Web Toolkit (GWT)  ist ein Web-Framework, mit einem interessanten Ansatz. Statt HTML-Seiten in den Vordergrund zu setzen, schreibt man Gui-Anwendungen in Java mit einer in AWT/Swing bekannten Art (Komponenten/Container und Listener) und lässt diese Anwendung von einem Compiler in JavaScript übersetzten. Die ganze Gui wird somit Teil des Web-Browers. Für den Teil, der nicht im Browser läuft, also die gesamte Geschäftslogik und Datenbank, gibt es eine RCP-Schnittstelle.

Schaue drei Beispiele für die Möglichkeiten von GWT an.

Um etwas mehr vom Hintergrund zu verstehen, kann man http://www.maximilien.org/presentations/2006/AJAX_and_GWT_Public_07052006.pdf lesen.

Wer praktisch spielen möchte, kann GWT+Eclipse+Plugin nach dem folgenden Blog-Eintrag installieren. Mehr über die Gui-Komponenten erfährt man in einem Kapitel des Hanser-Verlags (Übersetzung von GWT in Action): Widgets (deutsch).

Swing-Komponenten: JIDE Common Layer

JIDE ist ein Unternehmen, welches schon seit vielen Java qualitativ hochwertige Swing-Komponenten baut. Einige der Komponenten sind frei (JIDE Common Layer (Open Source Project)), weitere wie das Docking-Framework, Action Framework, (Pivot) Grids, Code Editor und weitere gehören zum kommerziellen Teil. Die Komponenten aus dem JIDE Common Layer stehen unter dual-license: GPL und free commercial license.

Textbox, die sich automatisch erweitert

Tabelle und Liste mit Checkboxen, Split-Pane mit mehreren Bereichen


Neue Border und Border-Layout mit anderer Anordnung Norden und Süden


Button-Gruppe und Datums, Popupmenü verbreiterbarer Größe und Zeit/Datum-Auswahl



Neue Standard-Dialoge

Verzeichnisauswahl

Overlay legt Komponenten über andere Komponenten

Scrollpane mit Platz für weitere Komponenten, Slider mit zwei Enden


Container mit Suche und Selektion

Statt Scrollbar automatisches Scrollen durch Pfeile

Diverse Label

Reiterkomponente

Buchkritik: Java EE 5 Development using GlassFish Application Server

David Heffelfinger. Packt Publishing. ISBN 1847192602. Oktober 2007. 408 Seiten

Trägt ein Buchtitel eine Technologie und gleichzeitig ein Produkt im Namen, ist das eine schwere Mischung. Entweder wird auf die Administration des Servers eingegangen, oder wir finden ein Lehrbuch, das nur Beispiele lauffähig auf einem speziellem Produkt vorweisen kann. Heffelfingers Werk gehört in keine Kategorie. Der Bezug zu Glassfish ist minimal, und wer mehr sucht als eine kleine Installationsanweisung – die es auch im Netz bei Sun gibt –, wird enttäuscht. Da die sauberen Java EE Beispiele den Entwickler nicht an einen speziellen Container binden, sind seine Quellcodes auch auf JBoss oder Geronimo ablauffähig. Wer nun Java EE lernen möchte, ist sicherlich darin interessiert, seine Beispiele zumindest auf einem Server laufen zu sehen. Aus Sicht der Zielgruppe eines Buches wohl eher unnötig einschränkend.

Didaktisch und fachlich gibt es das ein oder andere zu bemängeln. Einige Quellcode-Snippets bekommen ihr @Override vor den überschriebenen Servlet-Methoden, andere nicht. Und warum wird der String-Konstruktor laienhaft verwendet?

application.setAttribute("applicationAttribute", new String( "This string is accessible accross sessions."));

Oder parameterName aus String deklariert, aber später dennoch einmal explizit gecastet?

String parameterName = (String) initParameterNames.nextElement();
out.print(config.getInitParameter((String) parameterName));

Oder ein StringBuffer statt der guten allen String-Konkatenation eingesetzt?

@Override public String toString() {
StringBuffer fullNameBuffer = new StringBuffer();
fullNameBuffer.append(firstName);
fullNameBuffer.append(" ");
fullNameBuffer.append(lastName);
return fullNameBuffer.toString();
}

Hier ist ein return firstName + " " + lastName; doch wirklich angenehmer zu lesen und auch die Performance gar nicht schlechter.

Ebenso heiße ich es nicht für sinnvoll, auf das MVC-Konzept auch bei JSP/Servlets zu verzichten. Didaktisch dürften JSPs eher vor Servlets Sinn ergeben. JSPs gehen mir auch zu früh runter auf implizite Objekte und eine Skriptlet-Ebene ohne früh schon EL und die Standard-TagLib zu erklären. Die web.xml-Datei bekommt auch immer unterschiedliche Schema-Dateien und Versionen untergeschoben: Einmal 2.4, dann wieder das aktuelle 2.5. Beim Fehlerhandling findet sich:

StringWriter stringWriter = new StringWriter();
PrintWriter printWriter = new PrintWriter(stringWriter);
exception.printStackTrace(printWriter);
out.write(stringWriter.toString());

Warum der Autor nicht einfach exception.printStackTrace(new PrintWriter(out)); schreibt, ist mir ein Rätsel. (out ist ein JspWriter extends Writer und printStackTrace() möchte einen PrintStream oder PrintWriter.) Dann ist die Definition einer Bean falsch: „All of its variables must be private.” Die von Properties verwendeten Attribute sind in der Regel private, aber sie müssen es nicht sein. Auch sind natürlich public static final-Konstanten erlaubt. (Wunderbar, dass ausgerechnet im zugehörigen Beispiel die Variablen nicht private sind, sondern paketsichtbar.)

Die Datenbank ist mit zehn Tabellen vielleicht für Einstiegerbeispiele doch etwas zu kompliziert. Als Leser ist man erschrocken, plötzlich ein Servlet zu sehen, welches an die Datenbank geht und SQL-Anweisungen ausführt. Warum sieht man so einen Wahnsinn noch im Jahre 2008? Die Datenbank-Connection wird zudem nicht korrekt im finally-Block geschlossen. Es reicht, auf Seite 120 gebe ich auf und wage den Wiedereinstieg auf Seite 347. (Übersprungen werden Standard TagLibs, JSF, JMS, Security, EJB, Web-Services.) Zum Abschluss ein kleiner Höhepunkt: Heffelfinger geht praktisch auf Facelets ein und zeigt auch ein Beispiel für das Templating, ein Weiteres für Ajax4jsf und JBoss Seam findet sich ebenso. Ein erneuter Lichtblick: Der Autor verwendet vorbildlich die vorgesehene Dateieindung .jspf für inkludierte JSP-Fragmente. Dann noch etwas IDE-Integration (NetBeans und Eclipse) und der Spuk ist vorbei.

Buchkritik: Java/J2EE Job Interview Companion – 400+ Questions & Answers

Arulkumaran Kumaraswamipillai, Sivayini Arulkumaran. Lulu.com. ISBN 1411668243. April 2007. 355 Seiten

Es handelt sich um ein interessantes Buch, welches ich in dieser Form noch nicht gelesen habe. Meist dreht es sich ja um Anwendungsdesign oder harte Technologien, aber ein Buch, welches für Java-Entwickler mögliche Bewerbungsfragen sammelt, ist mir neu. Daher sollte das Werk auch von zwei Seiten beleuchtet werden: Vom Interviewer und vom Interviewten. Beide Gruppen erhalten mögliche Standardfragen zu diversen Themen aus Java SE, Java EE (+Hibernate +Spring) sowie Anwendungsdesign. Das Niveau wechselt zwischen „Was ist der Unterschied zwischen String und StringBuffer?“ und „Erkläre Inner Join und Outer Join.“ Beide Parteien erhalten ausreichende Antworten, wobei das Buch nur kurze Erklärungen liefert und auf breite Ausschweifungen verzichtet; sonst könnte leicht ein 2000 Seiten starker Wälzer daraus werden. Die Fragen sind gut gemischt und decken optimal das Standardwissen jedes Entwicklers ab. Trotz des Lobes kann die Erwähnung einiger Fehler nicht unterbleiben. Ein Beispiel zum Thema Varags: „The type must be Object and it must be the last argument or the only argument to the method.” Natürlich kann jeder Typ bei Varags verwendet werden, int… genauso wie String…. Hinzu kommen noch ein paar Kleinigkeiten, wie \n statt %n in printf(), klein geschriebene Enum-Konstanten, String-Konkatenationen im SQL-Statement für variable Teile statt Prepared-Statement und nicht erreichbarer Programmcode beim Schließen von JDBC-Connections, wenn es vorher eine Exception gab. Dennoch alles in allem ein gutes Buch zur Vorbereitung und auch zum Auffrischen des Java-Wissens für Entwickler, die schon ein paar Jahre Java programmieren.

Buchkritik: Agile Java Development with Spring, Hibernate and Eclipse

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

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

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

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:

    <bean id="today" class="java.util.Date" /> 
<bean id="calendarPrinter"
class="com.tutego.spring.annotation.CalendarPrinter" />

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:

    <bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor"/>

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 );
      }
    }

<beans xmlns="http://www.springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd">
<context:annotation-config/>
<bean id="today" class="java.util.Date" />
<bean id="calendarPrinter" class="com.tutego.spring.annotation.CalendarPrinter" />
</beans>

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

Thema der Woche: Datum und Zeit

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?

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?

Thema der Woche: Inversion Of Control/Dependency Injection

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).

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/.

Aufgabe:

  • Welcher fundamentale Unterschied hat Google Guice gegenüber Spring?
  • Frage Google Trends, wie sich die beiden IoC-Framwork sich in letzter Zeit entwickelt haben.

Thema der Woche: Apache Commons

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.

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

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

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:

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.

Thema der Woche: PDF-Dokumente

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

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

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

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:

  1. I am Unicode, thy character set. Thou shalt have no other character sets before me.
  2. Thou shalt carefully specify the character encoding and the character set whenever reading a text file.
  3. Thou shalt not refer to any 8-bit character set as “ASCII”.
  4. 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.
  5. Thou shalt plan for additions of future characters to Unicode.
  6. Thou shalt count and index Unicode characters, not UTF-16 code points.
  7. Thou shalt use UTF-8 as the preferred encoding wherever possible.
  8. Thou shalt generate all text in Normalization Form C whenever possible.
  9. Thou shalt avoid deprecated characters.
  10. 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.

Neues aus EJB 3.1

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 clas
s.

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

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

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

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

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

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>