Java ist auch eine Insel

Freitag, Mai 09, 2008

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

Labels:

AddThis Social Bookmark Button

Donnerstag, Mai 08, 2008

Borland verkauft CodeGear und damit JBuilder

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.

AddThis Social Bookmark Button

Eclipse 3.4 M7 - letzter Milestone

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:

Debug Hover

 

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

Labels:

AddThis Social Bookmark Button

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?

Labels:

AddThis Social Bookmark Button

Donnerstag, April 17, 2008

Neue Video-/Audio-Library

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.

Labels: ,

AddThis Social Bookmark Button

Montag, April 14, 2008

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

Labels:

AddThis Social Bookmark Button

Montag, April 07, 2008

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

Labels:

AddThis Social Bookmark Button

Montag, März 31, 2008

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.

Labels:

AddThis Social Bookmark Button

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.

AddThis Social Bookmark Button

Mittwoch, März 26, 2008

Bei Java ist PI dann auch mal 12

Na klar:

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

AddThis Social Bookmark Button

Dienstag, März 25, 2008

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?

Labels:

AddThis Social Bookmark Button

Montag, März 24, 2008

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.

AddThis Social Bookmark Button

Montag, März 17, 2008

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.

Labels:

AddThis Social Bookmark Button

Samstag, März 15, 2008

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

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.

Labels:

AddThis Social Bookmark Button

Donnerstag, März 13, 2008

NetBeans 6.1 Beta

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

Einige Neuigkeiten dokumentieren die folgenden Screenshots.

Woodstock-Komponenten:

newJSFComponents.png

 

RESTful Web Service Plugin

 

REST_test_client.png

JSF CRUD Generator

persistence-jsfpages.gif

 

MySQL Support in Database Explorer

mysql-node.jpg

 

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

spring-completion.png

spring-refactoring.png

 

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

http://wiki.netbeans.org/wiki/attach/JavaScript/findusages.png

AddThis Social Bookmark Button

Dienstag, März 11, 2008

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.

AddThis Social Bookmark Button

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>

Labels:

AddThis Social Bookmark Button

Inselupdate: Quantifizierer mit Wiederholungen, nicht gierige Operatoren

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 <b>fett</b>. <b>Cool</b>!";

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

Pattern pattern = Pattern.compile( "<b>.*</b>" );

Matcher matcher = pattern.matcher( string );

while ( matcher.find() )

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

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

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( "<b>.*?</b>" );

Matcher matcher = pattern.matcher( "Echt <b>fett</b>. <b>Cool</b>!" );

while ( matcher.find() )

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

Die Ausgabe ist:

<b>fett</b>

<b>Cool</b>

Labels: ,

AddThis Social Bookmark Button

Donnerstag, März 06, 2008

Java nach C# Übersetzer von ILOG Open-Source

ILOG hat ihren Übersetzer von Java nach C# quelloffen gemacht. Da Projekt ist unter SourceForge gehostet. Eingebunden ist es über Eclipse und dann macht man einfach nur ein File > Export. Es unterstützt Java 6 mit allen Java 5 Features wie Generics, Enums, foreach.

PS: Aktualisiertes tutego-Seminar Oracle Discoverer für Anwender

Labels: ,

AddThis Social Bookmark Button

Mittwoch, März 05, 2008

Alternative Sprachen für die und auf der JVM

Java hat seine Monopolstellung eingebüßt – die hochoptimierte JVM und die umfangreichen Java-Bibliotheken lassen sich mittlerweile durch alternative Programmiersprachen nutzen. Auf der einen Seite existieren klassische Interpreter und Compiler für existierende Sprachen, wie Ruby, Prolog, LISP, BASIC, Python, die bestmöglich auf die Java-Umgebung portiert werden. Auf der anderen Seite sind es ganz neue Programmiersprachen (wie Groovy), die sich als echte Alternative zur Programmiersprache Java etablieren. Skriptsprachen werden oft über die JSR 223: Scripting for the Java Platform, einer standardisierten API, angesprochen.

JavaScript

Seit Java 6 ist über Rhino – ein Projekt der Mozilla Foundation – eine JavaScript-Laufzeitumgebung integriert. Die Script-Engine erlaubt die dynamische Übersetzung in Bytecode, was schnelle Ausführungszeiten der prozeduralen, funktionalen, objektorientierten Programmiersprache garantiert.

Groovy

[Logo]Groovy bietet eine starke Syntax mit Closures, Listen/Mengen, Reguläre Ausdrücke, eine dynamische und statische Typisierung und vielem mehr. Moderne IDEs wie Eclipse oder NetBeans unterstützen Groovy durch Plugins. Der Groovy-Compiler erzeugt für die Groovy-Klassen den typischen Bytecode, sodass normale Java-Klassen problemlos Groovy-Klassen nutzen können – oder umgekehrt. Zwei Vorträge zum Einlesen:

JRuby

[Logo]JRuby ist die Java-Version der dynamisch getypten Programmiersprache Ruby. Sun beschäftigt mit Charles Nutter und Thomas Enebo (die ›JRuby Guys‹) zwei Entwickler, und bringt auch mit der Integration in die NetBeans IDE (J)Ruby weit nach vorne. Ruby wird mit einem Atemzug mit dem Web-Framework Ruby on Rails genannt, ein Framework für Web-Applikationen, welches dank JRuby auch auf jedem Tomcat und Java Application-Server läuft.

Jython

[Logo]Die beliebte Programmiersprache Python bringt Jython auf die Java-Plattform. Auch Jython übersetzt Python-Programme in Java-Bytecode und erlaubt relativ schnelle Ausführungszeiten. Jython 2.2 implementiert Python auf 2.2, doch hat sich (C-)Python mit Version 2.6 und 3 schon weiter entwickelt. Auch sonst gibt es Unterschiede, etwa bei den eingebauten (nativen) Funktionen. Sun hat im März 2008 Ted Leung und Frank Wierzbicki (Hauptentwickler von Jython) eingestellt, um Python auf der JVM weiter zu fördern.

Scala

[Logo]Scala ist eine Funktionale, objektorientierte Programmiersprache, die in der Java-Community große Zustimmung findet, obwohl sie von Martin Odersky erst 2001 entwickelt und 2004 vorgestellt wurde. Ein Eclipse-Plugin steht ebenfalls bereit. Für die .NET-Plattform gibt es ebenfalls eine Implementierung. Besonders zeichnet Scala ein durchdachtes Typsystem aus.

Quercus

Quercus ist eine Implementierung von PHP, welches insbesondere dazu geeignet ist, bestehende und beliebte PHP-Projekte in einer Java-Umgebung ablaufen zu lassen. In der Java-Welt werden zwar nicht alle PHP-Funktionen unterstützt, aber es gibt in der Java-Welt keine Speicherüberläufe oder Sicherheitsprobleme.

Jatha

Jatha ist eine ›Common LISP library in Java‹, eine Implementierung von Common LISP. Mit einer API lassen sich LISP-Programme aus Java heraus aufrufen.

LuaJava

[Logo]LuaJava implementiert die Programmiersprache Lua für die JVM. Die aus Brasilien stammende dynamisch getypte Programmiersprache Lua zählt zu den performantesten, interpretierten Skriptsprachen. Sie ist in erster Linie als eingebettete Programmiersprache zur Applikationssteuerung entworfen worden; prominete Nutzer sind Sim City, World of Worcraft, Adobe Photoshop Lightroom, SciTE.

Pnuts

Pnuts gehört zu den schnellsten Skriptsprachen auf der JVM. Die Sprache hat eine einfache Syntax und übersetzt Programme ebenfalls in Bytecode.

JBasic

Mit JBasic gibt es für die Java-Plattform einen BASIC-Dialekt, der sich an GW-BASIC anlehnt.

JLog

JLog implementiert einen ISO-Standardisierten PROLOG-Interpreter. JLog läuft in einem eigenen Fenster mit Quellcode-Editor, Query-Panel, Hilfe, Debugger, oder es kann in einem eigenen Java-Programm eingebettet werden.

Jacl

Jacl implementiert einen TCL-Interpreter in Java. Die Entwicklung ist nicht mehr aktiv.

 

Die Webseite http://www.robert-tolksdorf.de/vmlanguages.html führt weitere Programmiersprachen für die JVM auf. Allerdings sind viele der gelisteten Sprachen für sehr spezielle Anwendungsfälle entworfen, experimentell oder werden nicht mehr gepflegt.

Labels:

AddThis Social Bookmark Button

Samstag, März 01, 2008

Thema der Woche: Java 5 und Java 6

Java 5 ist mittlerweile weit verbreitet, und Entwickler sollten auf der einen Seite die neuen Spracheigenschaften kennenlernen, auf der anderen Seite sich mit dem Update der Bibliotheken beschäftigen. Als Startlinks gelten:

Von jeder neue Klasse und Schnittstelle sollte man zumindest den API-Kopf gelesen haben. Besonderes Augenmerk sollten Entwickler auf Generics legen. Hier gilt hervorzuheben das Tutorial http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf. Die Begriffe

  • Generischer Typ
  • Typparameter
  • formalter Typparameter
  • parametrisierter Typ
  • Typargument
  • Wildcard-Typ
  • Bounded Wildcard
  • upper bound, lower bound
  • generische Methode
  • unchecked Warnung
  • erasure
  • Wildcard capture
  • multiple bound

solle man sofort einordnen und beschreiben können.

Jeder Entwickler sollte insbesondere alle Anwendungen von Generics bei der Utility-Klasse Collections verstehen:

PS: Beginne bei <T>/<E> bzw. <K,V>, dann <?> und dann den restlichen. max/min sind dann die Generics-"Bonbons".

Wer danach die Nase von Generics immer noch nicht voll hat, beginnt http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html zu lesen. Das ist die umfangreichste Quelle zu dem Thema im Netz.

Labels:

AddThis Social Bookmark Button

Neue Rubrik "Die wöchentliche Dosis Java"

Nach mehr als 10 Jahren in der Java-Weiterbildung wiederholen sich doch die Fragen. Die Klassiker: "Wie haben Sie Java gelernt?", "Wie bilden Sie sich weiter?", "Was für Java-Bibliotheken nutzen Sie?", "Wie verbreitet ist eigentlich XZY?" Aus diesen Anfragen heraus möchte ich eine neue Rubrik "Die wöchentliche Dosis Java" vorstellen. Die Idee ist, die kontinuierliche Weiterbildung von Software-Entwicklern zu fördern. In der (hoffentlich) wöchentlichen Rubrik stelle ich Technologien, Bibliotheken, Tools, Sprachupdates, ... vor, in der sich Programmierer in einer Woche beschäftigen können und somit ein neues Gebiet kennenlernen. Der Bereich umfasst dabei die gesamte Java-Landschaft. Mal werden es Sprach-Erweiterungen sein, mal XML-Technologien, dann wieder etwas von Swing und Gui-Frameworks, dann REST, Web-Toolkits oder Open-Source Bibliotheken.

Labels:

AddThis Social Bookmark Button

Donnerstag, Februar 21, 2008

Java Closures : Inselupdate für Java 7

Mit den Closures nach Gilad Bracha, Neal Gafter, James Gosling, Peter von der Ahé.

Innere Klassen, insbesondere anonyme innere Klassen, sind bisher die einzige Möglichkeit, um Programmteile an Methoden zu übergeben. Nehmen wir einen Timer als Beispiel. Dem eigentlichen Zeitgeber muss ein Stücken Code übergeben werden, sodass der Timer weiß, was er zu tun hat. Mit dem Zeitgeber, der Klasse Timer, und der abstrakten Basisklasse TimerTask zur Beschreibung der Aufgaben, ist schnell ein Beispiel programmiert, das wie eine Uhr in jeder Sekunde die Zeit auf dem Bildschirm ausgibt:


public class TimerExample
{
public static void main( String[] args )
{
class MyTimer extends java.util.TimerTask {
@Override public void run() {
System.out.println( new java.util.Date() );
}
}

new java.util.Timer().scheduleAtFixedRate( new MyTimer(), 0, 1000 );
}
}

Für die Beschreibung des Programmcodes ist extra eine eigene Klasse erforderlich. Über eine innere anonyme Klasse lässt sich der Programmcode jedoch noch etwas weiter verkürzen:

 public class TimerExample
{
public static void main( String[] args )
{
new java.util.Timer().scheduleAtFixedRate( new java.util.TimerTask() {
@Override public void run() {
System.out.println( new java.util.Date() );
}
}, 0, 1000 );
}
}

Aus dem Programm ist deutlich abzulesen, dass zum "Transport" der println()-Anweisung einiges an Schreibarbeit nötig ist. Wünschenswert ist es aber, wenn der Programmcode leichter an die Funktion scheduleAtFixedRate() zu übergeben wäre. Da die bereitgestellte Funktion bisher nicht so programmiert ist, ist das Ziel, dieses nachzuprogrammieren.

Deklaration eines Closures

Ein Closure repräsentiert einen Block Java-Code. Die allgemeine Schreibweise ist

{ formal parameters => statements expression }

Die Schreibweise definiert eine anonyme Funktion. Vergleichen wir einer bekannten Funktionsdeklaration

void out()
{
System.out.printn("Hallo Welt");
}

mit der Deklaration eines Closures:

{ => System.out.printn("Hallo Welt"); }

Während normale Funktionen mit ihrem Namen aufgerufen werden, steht eine Closure für ein Objekt, welches eine invoke()-Methode anbietet.

public class Closures
{
public static void main( String[] args )
{
{ => System.out.println("Hallo Welt"); }.invoke();
}
}

Aus der allgemeinen Schreibweise

{ formal parameters => statements expression }

lässt sich absehen, dass formale Parameter wie bei normalen Funktionsdeklarationen möglich sind. So lassen sich in den Closure-Block Daten einführen. Vergleichen wir wieder eine Funktions- mit einer Closure-Deklaration:

void quote( String s )
{
System.out.println("'" + s + "'");
}

Der Closure mit Beispiel:

public class Closures
{
public static void main( String[] args )
{
{ String s => System.out.println("'" + s + "'"); }.invoke( "tutego" );
}
}

Zwei Dinge fallen an dem Beispiel auf:
• Formale Parameter haben einen Typ (links vom Pfeil steht String s ).
• Die invoke()-Funktion nimmt immer so viele Argumente an, wie es formale Parameter in der Closure-Deklaration gibt.

Die Beispiele bisher zeigen Closures, die in ihrem Rumpf eine Anweisung tragen. Closures können aber auch Ausdrücke enthalten.

public class Closures
{
public static void main( String[] args )
{
System.out.println( { int a, int b => (a + b) / 2 }.invoke( 10, 20) ); // 15
}
}

Im Rumpf endet die Ausdruck nicht mit einem Semikolon, denn es wäre ja auch verboten,

System.out.println( (a + b) / 2; );

zu schreiben.

Ein auffälliger Unterschied zur Funktion ist die fehlende return-Anweisung. Closures selbst sind quasi an die Aufrufstelle eingesetzte Programmteile und ein return würde die Funktion verlassen!

Funktions-Typ

Closures, wie { int a, int b => (a + b) / 2 }, besitzen einen so genannten Funktions-Typ, der durch die Typen der Parameter und der Rückgabe bestimmt ist. Die allgemeine Notation ist

{ formal parameters => return type }

Gibt eine Funktion nicht zurück, so steht rechts vom Pfeil void. Für unsere drei bisherigen Closures sind die Typen:

{ => void }
{ String =>