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:

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.

Bei Java ist PI dann auch mal 12

Na klar:

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

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:

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.

Labels:

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:

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.

Labels:

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:

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:

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.

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:

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: