tutego

See flash under http://madbean.com/anim/jarwars/.

Guckst du hier: http://www.youtube.com/v/av5y5X5Eyrg

Das hier unter http://www.absoluteswissen.de/web-xml_i.htm ist doch mal eine schöne interaktive Visualisierung von web.xml. 

Nach dem vierten Proposal (http://www.javac.info/closures-v04.html) für Closures von Gilad Bracha, Neal Gafter (der mit dem Java-Puzzlers), James Gosling und Peter von der Ahé (nach seiner Whishlist unter http://blogs.sun.com/ahe/entry/java_se_7_wish_list werden weitere abgefahrene Sachen möglich sein) wird in der Community heftig diskutiert, ob Closures nötig sind. Ich finde sie toll! Zwar sehe ich schon meine Teilnehmer über den Ausdrücken brüten und zweifeln an der Aussage "Java ist eine einfache objektorientierte Programmiersprache" zweifeln, doch denke ich, dass es unausweichlich ist, Java mehr sprachliche Möglichkeiten zu bieten.

Java: A simple, object-oriented, network-savvy, interpreted, robust, secure, architecture neutral, portable, high-performance, multithreaded, dynamic language [...] Java omits many rarely used, poorly understood, confusing features of C++ that in our experience bring more grief than benefit. [http://java.sun.com/docs/overviews/java/java-overview-1.html]

Dass Java im Moment so viele Veränderungen erfährt ist vielleicht auch eine Frage der Wahrnehmung. Sun war mit Grammatikänderungen bisher sehr konservativ und seit mehr als 10 Jahren haben wir bis auf den Wechsel von Java 1.0 auf Java 1.1 und Java 1.4 auf Java 5.0 kaum Änderungen gesehen; strictfp/Sprachänderungen wäre man so ein Außenseiter. Nun gibt es stärkere Veränderungen, wie wir sie bei anderen Sprachen auch erleben. C# hat sich in den letzten Jahren unglaublich verändert --- was als Java-Klon begann, ist heute eigenständig und als Sprache hoch innovativ. Mitunter starke strukturelle Änderungen lassen sich auch bei Skriptsprachen ausmachen, etwa Python (trinärer Operator, try/except/finally), PHP (die ganzen OOP-Eigenschaften), Perl (für Perl 2.6 ebenfalls Änderungen der OOP-Schreibweise/perl6-language-objects und funktionale Programmierelemente geplant) aber auch C++ und SQL. Als Java-Entwickler hat uns Sun nur in den letzten Jahren so "erzogen" dass es kaum große Änderungen gab, was sich nun ändert. Hier muss Sun uns also wieder "umerziehen".

Dass Java keine einfache Programmiersprache ist, müsste jedem eigentlich bewusst geworden sein, der didaktisch versucht, Konzepte wie Generics zu vermitteln. Unternehmen müssen auch mit nicht-Cracks Software entwickeln können und können nicht darauf bauen, dass alle Mitarbeiter Spezifikationen lesen und Best-Practices befolgen. (IMHO kann man mit OOP-Spezialisten in jeder Programmiersprache exzellente Ergebnisse erziehlen.) Eine Sprache muss daher auch immer ein bisschen Narrensicher sein. (Ein kleiner Seitenhieb auf Perl, der Sprache, der man "Write Once Read Never" (WORN) nachsagt.) Da sehe ich in Closures auf jeden Fall ein Problem, denn während Generics doch noch einfach zu lesen sind (von der Deklaration sprechen wir nicht!) sieht das bei Closure-Nutzungen etwas anders aus. Hier muss der Java-Entwickler wieder eine neue Syntax lernen.

Bisher ist in der neuen Syntax kein Wort von neuen Schlüsselwörtern. Das macht die Anwendung einfacher als es bei Java 5 mit enum war. Ein weiterer Punkt ist, dass man über allgemeine Closures Dinge schreiben kann, die wie spezielle Lösungen aussehen. Ein häufig zitiertes Beispiel ist der Lock:

withLock( lock ) {

    System.out.println( "Closures in Java 7" );

}

Das ist eine Kurzform für

withLock( lock, {=>

    System.out.println( "Closures in Java 7" );

} );

Es ist gerade nicht withLock() ein spezielles Java-Konstrukt, sondern nur die Anwendung eines allgemeinen Closures. Intern wird das Umgesetzt über übliche Schnittstellen. Und mit { => } sieht man schon, wie Closures in Java aussehen können.

In der Summe finde ich Closures toll und freue mich schon. Zwar habe ich schon die ersten Ideen, wie man das didaktisch umsetzen kann, aber mal sehen, was bis dahin geschrieben wird. Was Madbean unter http://madbean.com/2006/closure/ zeigt, finde ich schon nett. Doch bis Java 7 "freigelassen" wird, dauert es noch. Wer sich schon einmal vorbereiten möchte, der sollte sich zum Beispiel die Präsentation von Neal Gafter unter http://www.bejug.org/confluenceBeJUG/display/PARLEYS/Closures+for+Java anschauen.

 

Christian Ullenboom

PS: Wir haben das Seminar "Dynamische Webseiten mit JavaScript und DOM" [http://www.java-tutor.com/seminare/skriptsprachen-schulung/javascript-schulung.html] aktualisiert.

Labels: Java 7

Oracle und JBoss habe beide Spezial-Annotationen, um etwa idetime/timeout zu sezten. Im Fall von Oracle etwa

@StatefulDeployment(idletime=10,timeout=15)

Bei JBoss gibt es @org.jboss.annotation.ejb.PoolClass, aber auch@CacheConfig und @Cache aus dem Caching-Paket.

Für die für die Anwendung der Annotationen gibt es kaum Hinweise im Netz.

Unter http://blogs.sun.com/dagastine/entry/java_6_leads_out_of schreibt David Dagastine über die ersten Performance-Messungen der JVM Version 6. Die Zahlen (und Grafiken) sehen schon gut aus; die Version 6 schneidet bei (fast) allen Szenarien von Sun am Besten ab -- so wurden die Szenarien wahrscheinlich auch ausgesucht :-) BEA JRockit 5.0_06 R26.4 hat mich ein wenig überrascht, da die JVM in einigen Messungen leicht über Suns JVM lag, in den meisten Fällen aber weit am Ende lag.

Interessant erscheint mit der Hinweis, dass das Parameter-Tuning vermutlich in Zukunft einfacher wird, weil die JVM automatisch ihre Modi wählt. Die guten Laufzeitergebnisse kamen auch zustande, ohne einen speziellen Schalter gesetzt zu haben.

EJB 2 und EJB 3 im Container

Jeder EJB 3 Container muss auch EJB 2.x Beans verwalten können. Beim Design der neuen Spezifikation war es wichtig, dass
- eine EJB 2.x Bean in eine EJB 3.0 Bean injiziert werden kann,
- eine EJB 3.0 Bean sich von außen als EJB 2.x Bean ansprechen lässt.

Klassisches Home/Component-Interface

Nehmen wir für eine Session-Bean eine EJBHome-Schnittstelle MyHome an, dessen create()-Methode ein MyRemote liefert.

public interface MyHome extends EJBHome {
public MyRemote create()
throws CreateException, RemoteException;
}

public interface MyRemote extends EJBObject {
public void foo() throws RemoteException;
}

@EJB injiziert eine EJB 2 Bean

Mit der Annotation @EJB injiziert der Container nicht nur EJB 3 Verweise, sondern auch EJB 2 Beans. Da EJB 2 Beans kein Business-Interface haben, injiziert der Container Exemplare, die das Home-Interface implementieren. Der Container soll die Objektvariable myHome belegen:

@EJB private MyHome myHome;

Der Zugriff auf die EJB 2-Bean läuft wie üblich über create():

MyRemote bean = myHome.create();
bean.foo();


@RemoteHome/@LocalHome

Mit den neuen Annotationen aus EJN 3.0 kann eine Enterprise-Bean mit einer EJB 2 Sicht veröffentlicht werden. Dazu ist ein Remote- und Component-Interface nötig.
- Etwa wie im Beispiel MyHome und MyRemote.
Im nächsten Schritt wird die Bean mit @RemoteHome/@LocalHome annotiert, etwa so:

@RemoteHome( MyHome.class )

Nur das Home-Interface, aber nicht das Componten-Interface, kommt in die Annotation.
Die EJB implementiert das Componten-Interface nicht, muss auch keine Annotationen vor diese Methoden setzen. Die create-Methoden werden mit @Init annotiert. Der Name ist egal.

Beispiel einer EJB 2 mit der EJB 3 API

@Stateful
@RemoteHome( MyHome.class )
public class MyEJB2Bean
{
@Init
public void create() { }

public void foo() { }
}

Google hat einen Dienst vorgestellt, bei dem nach US-Patenten gesucht werden kann. Java taucht in den Patentschriften (http://www.google.com/patents?q=java) über 800 mal auf. Viele Patente stammen von Sun Microsystems, aber MS, IBM und Mobilfunkhersteller sind auch dabei.