tutego

• Wiederhole die Gof-Pattern von http://www.cmcrossroads.com/bradapp/javapats.html#Part2.
• Gehe die fundamentalen Pattern unter http://www.mindspring.com/~mgrand/pattern_synopses.htm#Dynamic%20Linkage ab.

• Nenne zwei Nachteile, die Vererbung gegenüber Assoziation hat.
• Gibt es seit Java 5 eine Alternative zu Marker-Interfaces? Wie sieht diese aus? Nenne Beispiele.

• Implementiere mit http://commons.apache.org/chain/ ein einfaches Beispiel, bei dem auf der Basis der ersten Bytes einer Grafikdatei eine Meldung auf dem Bildschirm erscheint, um welchen Bildtyp es sich handelt.
• dom4j nutzt mehrere Flyweight-Klassen (http://dom4j.org/dom4j-1.6.1/apidocs/org/dom4j/tree/package-summary.html). Diskutiere, ob das Fliegengewicht-Klassen nach dem Gof-Prinzip sind.

Labels: Die wöchentliche Dosis Java

Unter http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/4c3f752993a5 ist die Änderung sichtbar, mit der in Java 7 der Cache für die Integer-Objekte nun nicht mehr zwangsläufig im Bereich –128 bis +127 liegen muss. Ändern kann man die Cache-Größe auf der Kommandozeile mit -XX:AutoBoxCacheMax=<size>.

Labels: Java 7

Die Pattern/Matcher erlauben nicht nur das Suchen und Ersetzen, sondern bieten noch weitere interessante Möglichkeiten.

• Teste das Beispiel unter http://www.java2s.com/Code/Java/Regular-Expressions/MatcherappendReplacement.htm.
• Lies http://www.devarticles.com/c/a/Java/Introduction-to-the-Javautilregex-Object-Model/8/.
• Lies aus http://java.sun.com/javase/6/docs/api/java/util/regex/Matcher.html die Dokumentation von appendReplacement(), appendTail().
• Evaluiere, ob man einen http://en.wikipedia.org/wiki/Pig_Latin –Konverter mit diesen speziellen Methoden einfach schreiben kann.

Lösungen sind wieder gerne willkommen.

Labels: Die wöchentliche Dosis Java

Am 7.4.09 hat Google das Google Web Toolkit 1.6 veröffentlicht:

• http://googlewebtoolkit.blogspot.com/2009/04/introducing-gwt-16-and-friends.html
• http://code.google.com/intl/de/webtoolkit/doc/1.6/ReleaseNotes_1_6.html

Zu den Neuerungen gehören unter anderem DatePicker und DateBox (http://gwt.google.com/samples/Showcase/Showcase.html#CwDatePicker) und ein LazyPanel. Viele Bug-Fixes wurden gemacht. Eine der größten Änderungen ist das Eventing: Event-Listener wurden durch Event-Handler ersetzt. Damit gibt es nur noch eine zentrale Stelle, an der die Events verwaltet werden und nicht mehr viele kleine Mini-Listen bei jedem Widget.

Das Google Plugin for Eclipse wird wohl die Standard-IDE werden und vermutlich Cypal verdrängen. Insbesondere da es laut Webseite bietet:

• Recognition of inline JavaScript (JSNI): syntax highlighting, auto-indenting, Java Search and Refactoring integration
• GWT compiler shortcuts and configuration UI
• Wizards to create entry points, modules and HTML pages
• Support for GWT JUnit tests

Die Doku für das Eclipse-Plugin ist unter http://code.google.com/intl/de/eclipse/docs/gwt.html. Laut der Beschreibung fehlt die schöne Möglichkeit, Stubs für RPC-Dienste aufzubauen; das bietet Cypal. Schade.

PS: tutego hat das GWT-Seminar für GWT 1.6 aktualisiert: http://www.tutego.de/seminare/java-schulung/GWT-Seminar-Google-Web-Toolkit-Schulung.html.

Die langtools von Java sind die bekannten Kommandozeilenprogramme wie javac, jar, javap, … Die Quellen kann man sich zum Beispiel aus dem Mercurial Repository holen. Für Java 6 liefert http://hg.openjdk.java.net/jdk6/jdk6/langtools/ den Zugriff auf die Sourcen. Sie lassen sich auch in einem Rutsch (zip) beziehen. Im Verzeichis src/share/classes beginnen die Pakete:

• com.sun.javadoc. Die Java Doclet-API, also nur Schnittstellen etwa um Pakete, Variablen oder Typen zu beschreiben
• com.sun.mirror. Mirror API repräsentiert Konstrukte eines Java-Programms wie Klassen, Modifizierer. Anweisungen und Ausdrücke werden nicht repräsentiert. Wird in Java 7 verschwinden, denn dort gibt es mit javax.lang.model (seit Java 6) einen Ersatz. Die Mirror API wurde in Java 5 für das APT eingeführt, aber nie standardisiert
• com.sun.source.tree. Repräsentiert den AST (abstract syntax trees) eines Java-Programms vom Java-Compiler. com.sun.source.util. Utility-Klassen für den AST
• javax.annotation.processing. Um Annotation-Prozessoren zu beschreiben
• javax.lang.model.Element, javax.lang.model.type, javax.lang.model.util. Deklarationen, für Typen, die Meta-Daten aus einem Java-Programm beschreiben, etwa Modifizierer oder Generics-Typen. In erster Linie für APT
• com.sun.tools.apt.*. Annotation Processing Tool (apt). Greift auf javax.lang.model zurück
• com.sun.tools.doclets.internal.toolkit. Implementierung des Standard-Doclets
• com.sun.tools.javadoc. Implementierung des Schnittstellen aus com.sun.javadoc
• com.sun.tools.javac.*. Java-Compiler
• com.sun.tools.javah. C Header and Stub File Generator
• sun.tools.javap. Der Java Class File Disassembler.

Wenn man ein Beispiel programmieren möchte, muss man tools.jar in den Klassenpfad aufnehmen. Dann kann man schon loslegen. So nutzt folgendes Programm die Datenstrukturen von javap, und ist somit der Java-Quellcode-Gegenspieler von Reflection.

import java.io.*; 
import sun.tools.javap.*; 

public class MyJavap 
{ 
  static String filename = "bin/MyJavap.class"; 

  public static void main( String[] args ) throws FileNotFoundException 
  { 
    ClassData classData = new ClassData( new FileInputStream( filename ) ); 

    for ( FieldData field : classData.getFields() )

       System.out.println( field.getType() + " " + field.getName() ); 

    for ( MethodData method : classData.getMethods() ) 
      System.out.println( method.getName() + method.getParameters() ); 
  } 
}

Ausgabe:

java.lang.String filename 
<clinit>() 
<init>() 
main(java.lang.String[])

Die API um Programmcode zu beschreiben ist komplizierter. Folgendes Programm baut einen internen Baum auf und lässt ihn über die komfortablen print()-Funktionen ausgeben:

import javax.tools.DiagnosticCollector; 
import javax.tools.JavaCompiler; 
import javax.tools.JavaFileManager; 
import javax.tools.JavaFileObject; 
import javax.tools.StandardJavaFileManager; 
import javax.tools.ToolProvider; 

import com.sun.tools.javac.code.Flags; 
import com.sun.tools.javac.code.TypeTags; 
import com.sun.tools.javac.tree.JCTree; 
import com.sun.tools.javac.tree.TreeMaker; 
import com.sun.tools.javac.tree.JCTree.JCAnnotation; 
import com.sun.tools.javac.tree.JCTree.JCBlock; 
import com.sun.tools.javac.tree.JCTree.JCClassDecl; 
import com.sun.tools.javac.tree.JCTree.JCCompilationUnit; 
import com.sun.tools.javac.tree.JCTree.JCExpression; 
import com.sun.tools.javac.tree.JCTree.JCModifiers; 
import com.sun.tools.javac.tree.JCTree.JCStatement; 
import com.sun.tools.javac.tree.JCTree.JCTypeParameter; 
import com.sun.tools.javac.tree.JCTree.JCVariableDecl; 
import com.sun.tools.javac.util.Context; 
import com.sun.tools.javac.util.List; 
import com.sun.tools.javac.util.ListBuffer; 
import com.sun.tools.javac.util.Name; 
import com.sun.tools.javac.util.Name.Table; 

public class BuildSomeCode 
{ 
  public static void main( String[] args ) 
  { 
    JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); 
    DiagnosticCollector<JavaFileObject> diagnostics = new DiagnosticCollector<JavaFileObject>(); 
    StandardJavaFileManager fm = compiler.getStandardFileManager( diagnostics, null, null ); 

    Context context = new Context(); 
    context.put( JavaFileManager.class, fm ); 

    TreeMaker maker = TreeMaker.instance( context ); 
    Table table = new Table(); 

    ListBuffer<JCTree> methods = new ListBuffer<JCTree>(); 

    JCModifiers mmods = maker.Modifiers( Flags.PUBLIC | Flags.STATIC ); 
    Name mname = Name.fromString( table, "test" ); 
    JCExpression retType = maker.TypeIdent( TypeTags.VOID ); 
    ListBuffer<JCVariableDecl> params = new ListBuffer<JCVariableDecl>(); 
    ListBuffer<JCStatement> stmts = new ListBuffer<JCStatement>(); 
    JCBlock methodBody = maker.Block( 0, stmts.toList() ); 
    methods.append( maker.MethodDef( mmods, mname, retType, List.<JCTypeParameter> nil(), 
                                     params.toList(), List.<JCExpression> nil(), methodBody, null ) ); 

    JCModifiers cmods = maker.Modifiers( Flags.PUBLIC ); 
    Name cname = Name.fromString( table, "Test" ); 
    JCClassDecl classDef = maker.ClassDef( cmods, cname, List.<JCTypeParameter> nil(), null, 
                                           List.<JCExpression> nil(), methods.toList() ); 

    ListBuffer<JCTree> classDefs = new ListBuffer<JCTree>(); 
    classDefs.append( classDef ); 

    JCCompilationUnit compilationUnit = maker.TopLevel( List.<JCAnnotation> nil(), null, 
                                                        classDefs.toList() ); 

    System.out.println( compilationUnit ); 
  } 
}

Das ergibt:

public class Test { 
    public static void test() { 
    } 
}

Zum Weiterlesen:

• http://javadots.blogspot.com/2006/11/javac-internals.html
• http://www.ahristov.com/tutorial/java-compiler.html
• http://www.cs.ucla.edu/~smarkstr/javacop/docs/ASTQuickReference.pdf
• http://blogs.sun.com/yj/entry/yet_another_way_to_hack

Java nutzt für Objekte den Heap-Speicher, kann aber Bytes auch in sogenannten direkten Puffern speichern. Das kann sehr effizient sein, da Kopieroperationen zwischen dem Heap-Speicher und dem internen Speichern vermieden werden.

• Lies Programming With Buffers
• Verstehe Position, Limit, Capacity und flip(), reset(), rewind()
• Zeichne eine UML-Diagramm mit den Unterklassen von java.nio.Buffer und finde die Unterschiede
• Kopiere eine Datei mit der NIO Klasse FileChannel. Nutze geschickt transferFrom(). Folge erst danach der Diskussion unter http://www.javalobby.org/java/forums/t17036.html
• Studiere http://www.java2s.com/Code/Java/Regular-Expressions/AgreplikeprogramusingNIObutNOTLINEBASED.htm.

Labels: Die wöchentliche Dosis Java

• NetBeans-Kenai Integration
• Dependency Graph Viewer
• GlassFish Services in der View
• Hudson Integration
• und mehr...
  

Labels: Entwicklungsumgebung

EoD SQL (Ease of Development) ist eine API, die über Annotationen SQL-Queries an Methoden erlaubt und diese dann zur Laufzeit ausführt. Ein Beispiel zeigt die Arbeitsweise am schnellsten:

 public interface UserQuery extends BaseQuery {
    @Select("SELECT * FROM users WHERE id = ?1")
    public User getUserById(long id);
  
    @Select("SELECT * FROM users")
    public DataSet<User> getAllUsers();
 
    @Update("UPDATE users SET user_name = ?{1.userName}, email_address = ?{1.emailAddress} " +
    "dob = ?{1.dob} WHERE id = ?{1.id}")
    public void updateUser(User user);
 
    @Update(sql = "INSERT INTO users (user_name, email_address, dob) VALUES " +
    "(?{1.userName}, ?{1.emailAddress}, ?{1.dob})",
    keys = GeneratedKeys.RETURNED_KEYS_FIRST_COLUMN)
    public User insertUser(User user);
 
 }
 

Mit

UserQuery QUERY = QueryTool.getQuery(UserQuery.class);

wird dann ein Objekt erzeugt, was die Schnittstelle implementiert. Dann sind Aufrufe wir QUERY.getAllUsers() möglich

Zusammenfassung von der Webseite;

EoD SQL is a very small API that allows binding of SQL Queries to Java Objects. The API is designed to be compatible with the "Ease of Development" API that could be found in J2SE 1.6 beta, but not in the final release. The EoD API's main principal is that it maps SQL ResultSet's to objects, and not the other way around. Most OR mapping layers try to replicate the database structure in objects, where EoD SQL lets you write the SQL code, while it allows for easy access to Java Objects that map to the ResultSet.

Advantages to EoD SQL:

• Super light weight
• Very easy to work with
• Generally well documented (tell me where it's not)
• More features than the original EoD RI
• No compile-time anything needed
• No XML, or other configuration files needed
• Should work with any JDBC database
• Lets you code whatever SQL you like
• Object mapping is loose (extra columns in the results are ignored, as are extra fields in the data object)

What EoD SQL is not:

• EoD SQL will not parse or validate your SQL in any way
• EoD SQL is not a database or database connector, it sits on top of JDBC
• EoD SQL will not get you girls

Labels: Open Source

Nach Python unterstützt die GAP nun auch Java 6. Allerdings gibt es auch einige Besonderheiten:

• Kein Dateisystem (somit keine sinnvollen java.io.File-Operationen), da Zugriff über den App Engine Datastore
  
• Keine eigenen Threads
• Kein AWT- und Swing-Funktionalität/Pakete. Dass man kein Fenster aufmachen kann ist klar, aber es können auch keine Bilder skaliert werden und einige Web-Frameworks nutzen Swing-Modelle wie TableModel. (Für die Bild-Operationen bietet Google eine eigene API: http://code.google.com/intl/de/appengine/docs/java/images/overview.html)
  
• Eingeschränktes Reflection
• Besonderer Klassenlader
• (Natürlich) kein JNI
• Nicht unterstützte Dinge werfen eine SecurityException
  

Nichts desto trotz laufen auch dyn. Sprachen wie Groovy und JRuby. Und es gibt ein Eclipse-Plugin für das Deployment (Google Plugin for Eclipse). Datenzugriff der AppEngine gibt es mit der API von JPA/JDO über http://www.datanucleus.org/products/accessplatform/ (früher JPOX), IMHO eine recht unbekannte Implementierung der Standards.

Zum Weiterlesen:

• http://code.google.com/intl/de/appengine/docs/java/overview.html
• http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html
• http://www.infoq.com/news/2009/04/gae
• http://code.google.com/intl/de-DE/appengine/docs/java/jrewhitelist.html
• http://paulhammant.com/blog/google-app-engine-for-java-with-rich-ruby-clients.html
• http://www.vineetmanohar.com/2009/04/11/writing-java-hello-world-for-google-app-engine/
• http://broadcast.oreilly.com/2009/04/java-for-google-appengine-fina.html
• http://www.theserverside.com/news/thread.tss?thread_id=54256
• 
  

Labels: Open Source, Web Frameworks

Labels: Java 7