Expression Language 3.0 (JSR-341), wow, aber komplett an mir vorbeigezogen

Schau http://www.youtube.com/watch?v=Uyx7fLXXSS4, http://www.youtube.com/watch?v=JEKpRjXL06w und http://rijkswatch.blogspot.de/2012/06/expression-language-30-is-in-public.html. Aus der Spezifikation http://download.oracle.com/otn-pub/jcp/el-3_0-fr-eval-spec/EL3.0.FR.pdf.

  • Lambdas: fact = n -> n==0? 1: n*fact(n-1); fact(5) oder employees.where(e->e.firstName == ‘Bob’)
  • Collection-Syntax: employees.where(e->e.firstName == ‘Bob’) oder {„one“:1, „two“:2, „three“:3}
  • Streaming wie in Java 8: books.stream().filter(b->b.category == ‘history’) .map(b->b.title) .toList() oder [1,2,3,4,5].stream().substream(2,4).toArray()

Insgesamt:

■ Added Chapter 2 “Operations on Collection Objects”.
■ Added 1.8, String concatenation operator.
■ Added 1.13, Assignment operator.
■ Added 1.14, Semi-colon operator.
■ Added 1.20 Lambda Expression.
■ Added 1.22 Static Field and Methods.
■ Added T and cat to 1.17 Reserved words.
■ Modified 1.16 Operator precedence.
■ Modified coercion rule from nulls to non-primitive types.
■ Many changes to the javadoc API.

Schön ist, dass man das auch eigenständig außerhalb vom Web-Container verwenden kann. Das macht die EL interessant für Template-Lösungen.

Siehe auch YouTube Video: https://www.youtube.com/watch?v=JEKpRjXL06w

Darf man in einer Java EE-Anwendung mit Class.forName(…) einen Klasse laden?

Ja, das ist erlaubt. Siehe auch http://www.oracle.com/technetwork/java/restrictions-142267.html:

Why is there a restriction against using the Java Reflection APIs to obtain declared member information that the Java language security rules would not allow? Doesn’t Java automatically enforce those rules?
Contrary to common belief, most of the Java Reflection API can be used from EJB components. For example, loadClass() and invoke() can both be used by enterprise beans. Only certain reflection methods are forbidden.

und

Why all the restrictions on creating class loaders and redirection of input, output, and error streams?
Class loading is allowed, but creating custom loaders is not, for security reasons. These restrictions exist because the EJB container has responsibility for class loading and I/O control. Allowing the EJB to perform these functions would interfere with proper operation of the Container, and are a security hazard.

JPA-Beispiel in wenigen Minuten mit OpenJPA

  1. Beziehe unter http://mvnrepository.com/artifact/org.apache.openjpa/openjpa-all das openjpa-all-2.2.0.jar (etwas mehr als 6 MiB) und setzte es in den Klassenpfad.
  2. Habe einen Datentreiber im Klassenpfad (bei mir den der HSQLDB).
  3. Lege im Projekt einen Ordner META-INF an, platziere dort eine Datei persistence.xml:
  4. <?xml version="1.0" encoding="UTF-8"?>
    <persistence xmlns="http://java.sun.com/xml/ns/persistence"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/persistence persistence_2_0.xsd"
      version="2.0">
      <persistence-unit name="traida" transaction-type="RESOURCE_LOCAL">
        <class>traida.shared.domain.Contact</class>
        <properties>
          <property name="openjpa.jdbc.DBDictionary" value="hsql"/>
          <property name="javax.persistence.jdbc.url" value="jdbc:hsqldb:file:hsqldbtest;user=sa" />
          <property name="javax.persistence.jdbc.driver" value="org.hsqldb.jdbcDriver" />
          <property name="openjpa.Log" value="DefaultLevel=ERROR, Tool=ERROR" />
          <property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema(ForeignKeys=true)"/>
        </properties>
      </persistence-unit>
    </persistence>

    Mehr zu den Properties unter http://openjpa.apache.org/builds/apache-openjpa-2.2.1-SNAPSHOT/docs/docbook/manual/main.html.

  5. Lege eine Klasse traida.shared.domain.Contact an:
  6. @Entity
    public class Contact {
      @Id
      @GeneratedValue( strategy = GenerationType.IDENTITY )
      public Long id;
      public String name;
      // Setter/Getter ausgelassen
    }

  7. Schreibe eine main(String[])-Methode mit:
  8. EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory( "traida" );
    EntityManager entityManager = entityManagerFactory.createEntityManager();
    entityManager.getTransaction().begin();
    Contact c = new Contact();
    c.name = "Hallo Willi";
    entityManager.persist( c );
    entityManager.getTransaction().commit();
    System.out.println( entityManager.createQuery( "select c from Contact c" ).getResultList() );
    entityManager.close();

  9. Fertig, jetzt freuen.

Erster Milestone von Jersey 2, implementiert JAX-RS 2

Weitere Details im Blog http://marek.potociar.net/2012/02/22/first-milestone-build-of-jersey-2-0/. Für Clients gibt es vielleicht die größte Änderung: Die Einführung der JAX-RS Client API. Die API ist allerdings noch nicht verabschiedet, kann sich daher also ändern. Die bisherige Spezi von JAX-RS liegt unter http://jcp.org/aboutJava/communityprocess/edr/jsr339/index.html.

GlassFish v3 und Java EE 6 freigegeben

Unter http://www.theserverside.com/news/thread.tss?thread_id=58858 ist heute zu lesen:

Sun has released the Java Platform Enterprise Edition 6and the GlassFish Enterprise Server v3.
Java EE 6 includes new specifications that add new functionality to the platform, like dependency injection, Bean Valiation and RESTful services, as well as improvements to the existing specifications including very significant improvements to Java Server Faces, Enterprise Java Beans, JPA, Servlets and Java Connectors. Java EE 6 also includes a Web Profile. Additional information on Java EE 6 is available from the WebSite and this Overview Article.
The GlassFish v3 Server implements the Java EE 6 specification. GlassFish v3 is Open Source and fully modular, built on an OSGi kernel and the Grizzly NIO infrastructure. GlassFish v3 is suitable for a wide range of applications, from development to deployments. The long list of additional GFv3 features includes embeddability, very fast startup, redeploy-on-save, session state persistence, dynamic language support, management and monitoring facilities, graphical, CLI and REST command interfaces, and an update center. GlassFish v3 is supported by NetBeans, Eclipse and IntelliJ IDEA.
Additional information on GlassFish v3 Server is available from the Product Page and our main Team Announcement. GFv3 can be downloaded here; the full version is 70MB and the Web Profile 50MB.

Zusammenfassung der Änderungen von EJB 3.1 und JPA 2

  • Die lokale Schnittstelle (local view) einer lokalen Session Bean kann nun entfallen, da direkt die öffentlichen Methoden als Schnittstelle verwendet werden können. Eine lokale Session Bean muss daher keine Schnittstelle mehr implementieren, um injiziert zu werden und Methoden anzubieten.
  • EJBs müssen nicht mehr in einem EAR-Archiv verpackt sein, sondern können einfach in einem WAR deployed werden. Im Fall von WAR-Archiven liegen dann die Klassen unter WEB-INF/classes.
  • Mit der Annotation @Singleon lässt ein Singleton markieren, sodass sich eine Session Bean (die auch Business Schnittstellen implementieren kann) von unterschieden Stellen nutzen lässt, aber eben nur einmal in der JVM vorhanden ist.
  • Die Annotation @Startup ist ein Zusatz für @Singleton, um über das Hoch-/Runterfahren des Applikationsservers informiert zu werden. Die Callbackmethoden nutzen das bekannte @PostConstruct und @PreDestroy.
  • Der EntityManager erlaubt ein detach().
  • Embeddable’s können in JPA 2.0 geschachtelt sein und Relationen eingehen.
  • Weitere Mappings bei JPA-Tabellen. Map-Keys können nun einfache Objekte, Entities und embedded Entities sein.
  • Bisher konnten etwa 1:n-Assoziationen immer nur Verweise auf Entity-Beans realisieren, aber keine Sammlungen etwa von Strings oder Datums-Objekten. Das ändert sich mit JPA 2.0, das Collections von Elementen erlaubt. Hier zieht JPA eine Collection-Table heran.
  • Die Entities im Persistence Context eines Entity-Managers sind in einem Cache, dem Level 1 Cache. Bei zwei Entity-Managern ist es implementierungsabhängig, wie zum Beispiel zwei gleiche Entity-Beans in den beiden EM gehalten werden. Das bestimmt ein Level 2 Cache. Dieser Level 2 Cache lässt sich über die Shared Cache API von JPA 2.0 rudimentär kontrollieren.
  • Mit einer @Version-Spalte erlaubt JPA 1.0 schon immer optimistisches Locking, allerdings nur optimistische Lese- oder Schreib-Sperren. Mit JPA 2.0 wird über die Enum LockMode nun Optimistisches und auch Pessimistisches Locking unterstützt.
  • Eine neue Criteria-API kommt in JPA 2.0 und damit neue Typen wie QueryBuilder, CriteriaQuery. Die API folgt dem Fluent-Interface Prinzip, etwa wie bei criteriaQuery.select(entity.get(„id“)).where(queryBuilder.cojunction(queryBuilder.equals(…), …)).
  • JPA-QL kennt für Datumswerte nun auch Literale.
  • JPA-QL unterstützt polymorphe Anfragen der Art WHERE CLASS(e) = Klassenname.
  • JPA-QL ermöglicht CASE-Anfragen wie eine Fallunterscheidung.
  • JPA-QL erlaubt in der WHERE-Klausel Zugriff auf den Index einer Liste.

JBoss 5 ist fertig + Application Servers 2008 Rankings

Nach 3 Jahren gibt es nun (endlich) den JBoss 5 AS. Einige Meldungen und Meinungen dazu:

JBoss 5 taucht aber (noch) nicht als zertifizierter Java EE 5 Container unter http://java.sun.com/javaee/overview/compatibility.jsp auf, obwohl http://sacha.labourey.com/2008/09/15/jboss-as-is-now-ee5-certified/ davon berichtet.

Unter http://www.theserverside.com/news/thread.tss?thread_id=51008 wird der EDC report – "Application Servers 2008 Rankings" (http://www.evansdata.com/reports/viewRelease_download.php?reportID=20) diskutiert. Die Kommentare sind lesenswert. Der Download des Papers verlangt ein Login, ist aber ansonsten frei.

Java EE 6 in der Endphase der Spezifikation

Die JSR-316 (http://jcp.org/aboutJava/communityprocess/edr/jsr316/index.html) ist eine Umbrella-API für Java EE 6. Am 22. November 2008 war der Close of Early Draft Review, sodass Java EE 6 nun in die heiße Endphase geht. Interessante neue APIs in Java EE 6 sind:

  • JSR-311 JAX-RS: Java API for RESTful Web Services
  • JSR-299 Web Beans
  • JSR-236 Timer for Application Servers
  • JSR-237 Work Manager for Application Servers

Erwartet Updates gibt es bei

  • Enterprise JavaBeans
  • Java Persistence API
  • Servlets
  • JavaServer Faces
  • JAX-WS
  • Java EE Connector API

Jersey 1.0 (JAX-RS) ist fertig

Im Sun-Blog ist http://blogs.sun.com/theaquarium/entry/jersey_1_0_just_shipped ist zu lesen:

JAX-RS co-spec lead and Jersey lead Paul Sandoz just announced Jersey 1.0 availability. v1.0 moments are always special and this one is certainly no exception given how progress was made on a regular basis from engineering hard work and lots of community feedback. Congrats to Paul and the entire community for a well run open source project !

Jersey 1.0 is obviously a JAX-RS 1.0 implementation, but it also adds Spring integration, a REST client, and obviously is production quality…
One of the signs of a community-involved project is the many ways the bits can be accessed: GlassFish v2 and v3, NetBeans 6.5, Maven 2, zip, etc…

With Jersey 1.0 out the door, you can now freely choose your Web Services style and stick to standards. Java EE 6, scheduled sometime mid-2009, will make this even clearer though a maintenance release.
See Jersey for more stories.

Und überall sitzt die OSGi Service Platform drunter…

Unter http://www.earthtimes.org/articles/show/world-leading-enterprise-application-server-providers,541827.shtml und http://www.osgi.org/blog/2008/09/impressive-press-release.html führen die Autoren auf, wie beliebt mittlerweile OSGi als Basis für Java EE Container ist. Peter Kriens führt folgende Container auf:

  1. IBM Websphere. They started in 2006 and aggresively moved their code on OSGi. Obviously it helped that IBM has committed itself to OSGi since day -1.
  2. Oracle WebLogic. Formerly known as BEA weblogic. BEA was one of the first companies public touting the advantages of OSGi, clearing the road for others.
  3. Paremus Infiniflow. Paremus has pioneered the use of OSGi in highly distributed application servers allowing the system to scale to unprecendented heights.
  4. ProSyst ModuleFusion. ProSyst is the key provider of OSGi technology in the embedded worlds but originated from the development of a J2EE server. They are now back in this market with an offering based completely on OSGi.
  5. Redhat JBoss. JBoss already worked with a microkernel approach but recognized the advantages of a standard two years ago.
  6. SAP Netweaver. Well, they are not yet based on OSGi, but they clearly see their future based on the OSGi specifications and are becoming more and more active in the OSGi Alliance.
  7. SpringSource Application Platform. The company that simplified Enterprise development with their Spring Framework decided to create their own offering in the application server market completely based on the OSGi specifications.
  8. Sun Glassfish. And last, but definitely not least, Sun decided to use OSGi in the JEE reference implementation Glassfish. They clearly take OSGi extremely serious nowadays since they also hired Richard S. Hall. It is so good to see Sun back at the OSGi Alliance.

Interessant sind zwei Feststellungen:

  1. In der Regel geben die Container die OSGi-Implementierung nicht nach oben weiter, abstrahieren also von den Internas. Nur einige Produkte erlauben, auch selbst OSGi-Bundles anzumelden.
  2. Java EE und das SpringFramework sind beides Nutznießer der OSGi-Plattform. Man kann nun fragen, ob man sich überhaupt noch mit OSGi selbst beschäftigen muss, wenn etwa GlassFish oder http://www.springsource.com/products/suite/applicationplatform gute Abstraktionen bieten.