Um mit value % 2 == 1 zu testen, ob value eine ungereade Zahl ist, muss value positiv sein, denn -3 % 2 wertete Java zu -1 aus. Der Test auf ungereade Zahlen wird erst wieder korrekt mit value % 2 != 0.

Werden Exemplare einer nicht statischen inneren Klasse serialisiert, die äußere Klasse implementiert aber nicht Serializable, gibt es einen Fehler, denn intern hält ein Objekt der inneren Klasse einen Verweis auf das Exemplar der äußeren Klasse. Statische innere Klassen machen das nicht, was das Problem mit der Serialisierung lösen kann. Das Datenvolumen kann natürlich groß werden, wenn schlanke nicht-statische innere Serializable-Klassen in einer äußeren Serializable-Klassen liegen, die sehr viele Eigenschaften besitzt.

Zwar wird Java 7 höchst wahrscheinlich Closures bekommen, aber nicht jeder wird wissen, dass im Moment ganz unterschiedliche Varianten diskutiert werden:

– Gilad Bracha, Neal Gafter, James Gosling, Peter von der Ahé (BGGA)
– Bob Lee, Doug Lea, and Josh Bloch (CICE)
– Stefan Schulz (FCM)

Der Blog-Eintragt http://www.jroller.com/page/scolebourne?entry=java_7_comparing_closure_proposals vergleicht Szenarien mit den drei bisherigen Vorschlägen.

FileChannel     fc = new FileInputStream( "c:/a.html" ).getChannel();
ByteBuffer byteBuf = fc.map( FileChannel.MapMode.READ_ONLY, 0, fc.size() );
CharBuffer charBuf = Charset.defaultCharset().newDecoder().decode( byteBuf );
Pattern    pattern = Pattern.compile( "<a.*?href=[\"']([^\"]*?)[\"'].*?>", Pattern.CASE_INSENSITIVE );
Matcher          m = pattern.matcher( charBuf );

while ( m.find() )
  System.out.println( m.group( 1 ) );

fc.close();

RPC-Style oder Document-Style

RPC-Syle (Remote Procedure Style)
Web-Services werden im Sinne von entfernten Methodenaufrufen genutzt.
Eine Web-Service-Methode kann Übergabeparameter und Rückgaben besitzen.
Die Übergabewerte müssen umkodiert werden. XML selbst zum Beispiel wird als umkodierter String übertragen.

Document-Style
Eine Web-Service-Methode hat nur ein Argument.
Das Argument geht als echtes XML-kodiertes Objekt auf den Weg und wird nicht umkodiert.
Da sich jedes beliebige XML-Dokument schicken lässt, ist das flexibler bei Anpassungen, denn Änderungen am WSDL für die Argumente sind nicht nötig.

SOAP-Encoding/Literal-Encoding

SOAP nutzt XML um Daten zu übertragen.
Im Fall von Methoden müssen Argumente und Rückgabewerte wie Zahlen, Strings aber auch Arrays der Datentypen in XML kodiert werden.

Zwei Kodierungen gibt es:

• Literal-Encoding. Literal Encoding nutzt ein XML Schema zum Validieren der SOAP-Daten.
• SOAP-Encoding, auch Section 5 Encoding genannt. Das 5. Kapitel der W3C-Spezifiaktion für SOAP schreibt vor, wie Argumente verpackt werden.

Mit den Varianten RPC- oder Document-Style zu versenden und Daten über SOAP-Encoding oder Literal zu kodieren gibt es theoretisch vier Möglichkeiten.

• RPC/SOAP-Encoding wird nach WS-I Basic Profile nicht empfohlen. (Kann XFire etwa auch nicht.)
• Document/SOAP ergibt keinen Sinn.

Document/Wrapped

Die Variante über Document/Literal, auch Document/Bare genannt, ist in der Praxis üblich. Sie bietet auch die beste Performance http://www-128.ibm.com/developerworks/webservices/library/ws-soapenc/.

Zwar nimmt Document/Literal nur exakt ein Argument, es lässt sich aber tricksen, in dem mehrere Argumente zu einem neuen komplexen Typ werden. Das nennt man Document/Wrapped. Damit ist auch addPerson(int id, String name) möglich.
Die Paramter id und name werden in einen eigenen Complex-Type gepackt.

Der normale GZIPOutputStream nutzt einen Standardkompressionswert. Um diesen zu ändern, ruft man beim Deflator, der eigentlich hinter der Kompresssion steckt, setLevel() auf, um den Kompressionslevel setzen. Die folgende Unterklasse regelt das für uns:

import java.io.IOException;
import java.io.OutputStream;
import java.util.zip.GZIPOutputStream;

public class LevelGZIPOutputStream extends GZIPOutputStream
{
/**
 * Creates a new output stream with a default buffer size and
 * sets the current compression level to the specified value.
 *
 * @param out the output stream.
 * @param level the new compression level (0-9).
 * @exception IOException If an I/O error has occurred.
 * @exception IllegalArgumentException if the compression level is invalid.
 */
public LevelGZIPOutputStream( OutputStream out, int compressionLevel )
    throws IOException
{
  super( out );
  def.setLevel( compressionLevel );
}
}

Da blättere ich gerade durch das „Just Java“ Buch und glaube, schon einen Fehler gefunden zu haben, da sagt mir der Compiler, dass alles in Ordnung ist:

public class T
{
public static int foo()[]
{
 return new int[] { 1, 2, 3 };
}

public static void main( String[] args )
{
 System.out.println( foo().length );
}
}

Diese sonderbare Rückgabe habe ich noch nie gesehen und ist mir in der Grammatik der Sprache Java auch noch nie aufgefallen.

Was früher noch Teil der J2EE war, ist heute Teil der Java Standard Edition.

• http://java.sun.com/j2ee/sdk_1.3/techdocs/api/ zeigt noch DOM und SAX, sowie das „JDBC 2.0 Optional Package“ was dann Teil der J2SE 1.4 wurde.
• http://java.sun.com/j2ee/1.4/docs/api/index.html zeigt javax.management „Java Management Extensions“ (JMX), und javax.xml.parsers, javax.xml.transform was fester Bestandteil von Java SE 5 wurde.
• http://java.sun.com/javaee/5/docs/api/ zeigt die JPA (Java Persistence API), was vermutlich Teil von Java 6 wird.

Viele Teile der Java Enterprise Edition werden so geläufig, dass sie in die Java Standard Edition wandern.

• Dennoch wurde es unter der Enterprise-Edition mehr: 78 Pakete in Java EE 5, 54 Pakete in J2EE 1.4, 32 in J2EE 1.3

Mit JBoss und den proprietären Annotationen ist es einfach eine JMX zu schreiben. JBoss bringt ein Beispiel gleich mit:

package trail.jmx;

public interface Rechner {

// Attribute
public void setGrowthrate (double g);
public double getGrowthrate ();

// The management method
public double calculate (int start, int end, double saving);

// Life cycle method
public void create () throws Exception;
public void destroy () throws Exception;
}

 

package trail.jmx;

import java.lang.management.ManagementFactory;

import javax.annotation.PostConstruct;

import org.jboss.annotation.ejb.Management;
import org.jboss.annotation.ejb.Service;

@Service (objectName=“trail:service=calculator“)
@Management(Rechner.class)
public class RechnerMBean implements Rechner {

double growthrate;

public void setGrowthrate (double growthrate) {
this.growthrate = growthrate;
}

public double getGrowthrate () {
return growthrate;
}
public double calculate (int start, int end, double saving) {
double tmp = Math.pow(1. + growthrate / 12., 12. * (end – start) + 1);
return saving * 12. * (tmp – 1) / growthrate;
}

// Lifecycle methods
public void create() throws Exception {
growthrate = 0.08;
System.out.println(„Calculator – Creating“);
}

public void destroy() {
System.out.println(„Calculator – Destroying“);
}

}

In der JMX-Console taucht die Klasse dann auf.

Wenn man das ganze nun mit der JConsole hinbekommen möchte, hat man ein Problem, denn JBoss meldet die Beans nicht am Standard-Container für JMX Beans an, sondern an einem eigenen. Daher benötigt JBoss einen Hinweis, in den Sun-Container zu schreiben. Dazu ist ein Schalter beim Starten (run.bat oder in Eclipse bei der Startkonfiguration) mit anzugeben:

-Djboss.platform.mbeanserver -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl

Unter Java 5 muss natürlich noch -Dcom.sun.management.jmxremote dazu.

Jetzt ist der „Rechner“ auch in der JConsole.

• Greift Hibernate nicht allein auf die Datenquelle zu, sind die Daten im Cache unter Umständen nicht mehr aktuell.
• Wenn Daten einmal in den Cache gesetzt werden, danach aber nie wieder benötigt werden, war die Arbeit umsonst.
• Bei sehr vielen Daten quillt der Cache über und muss Dinge entfernen – nach Murphys Law sind die dabei, die wir als nächstes wieder lesen.
• Es sollen/müssen alle Anfragen an die Datenbank gehen, weil etwa jede Anfrage Logging-Informationen mitgespeichert. (Durch ein SELECT ist ein Trigger verbunden.)
• Wenn es nur eine Sitzung gibt, ist ein Second Level Cache unnötig. Er dient nur dazu, Daten zwischen mehreren Sitzungen „lebendig“ zu halten.

Seit Java 5 gibt es mit dem Executor (JSR 166) eine Schnittstelle für „Ausführer“ von Runnable-Objekten.
Spring bietet mit dem TaskExecutor die gleiche Schnittstelle.
– So steht die Funktionalität auch für Java 1.4 und Java 1.3 und auch für Java EE Umgebungen zur Verfügung.
org.springframework.core.task.TaskExecutor:
void execute( Runnable task )

Die TaskExecutor im Überblick

SimpleThreadPoolTaskExecutor
– Thread-Pool durch Quartz’s SimpleThreadPool.
SimpleAsyncTaskExecutor
– Erzeugt pro Anfrage einen neuer Thread. Es gibt eine optionale maximale Größe.
SyncTaskExecutor
– Führt Runnable im aktuellen Thread aus. Erzeugt also keinen neuen Thread zur Nebenläufigkeit.
ConcurrentTaskExecutor
– Ein Wrapper zum java.util.concurrent.Executor von Java 5.
ThreadPoolTaskExecutor
– Geht direkt auf den java.util.concurrent.ThreadPoolExecutor von Java 5. Ermögicht Anpassung der Properties „corePoolSize“, „maxPoolSize“, „keepAliveSeconds“, „queueCapacity“.
TimerTaskExecutor
– Nutzt einen java.util.Timer zur Ausführung. Der Runnable wird als TimerTask hintereinander durch den Timer-Thread ausgeführt.
WorkManagerTaskExecutor
– Nutzt CommonJ WorkManager als Implementierung. Ermöglicht Ausführung auf Applikationsservern von BEA und IBM.

Beispiel für TaskExecutor

public class DoItExecutor
{
private TaskExecutor executor;

public DoItExecutor( TaskExecutor executor )
{
this.executor = executor;
}

public void doIt()
{
Runnable run = new Runnable() {
public void run() {
System.out.println( Thread.currentThread() );
}
};

executor.execute( run );
executor.execute( run );
}
}

Injizierung vom TaskExecutor

<bean id=“taskExecutor“ class=“org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor“>
<property name=“corePoolSize“ value=“5″ />
<property name=“maxPoolSize“ value=“10″ />
<property name=“queueCapacity“ value=“25″ />
</bean>

<bean id=“doItExecutor“ class=“DoItExecutor“>
<constructor-arg ref=“taskExecutor“ />
</bean>

„Fehlende“ Typen aus Java 5

Spring bietet unterschiedliche Implementierungen für den TaskExecutor, aber Java 5 bietet außer execute() im Executor noch mehr.
Der java.util.concurrent.ThreadPoolExecutor implementiert mehr als nur Executor, nämlich ExecutorService. Das bietet
– awaitTermination(), invokeAll(), invokeAny(), isShutdown(), isTerminated(), shutdown(), shutdownNow(), submit()
– mit weiteren Typen wie Future, Callable.
Spring bietet dafür bisher keine Abstraktion!