gwt-connectors – Verbindungen zwischen Formen

gwt-connectors ist eine GWT-Bibliothek, um Formen miteinander zu verbinden.

Die Präsentation zeigt, wie das geht.

Wer’s selber ausprobieren möchte, schaut unter demo (IE, Firefox, Opera, Chrome). (Aber wie kann man nun die Verbindung wieder lösen …)

Der nötige Programmcode ist kurz:

// Create boundary panel
AbsolutePanel boundaryPanel = new AbsolutePanel();
boundaryPanel.setSize("600px", "400px");
RootPanel.get().add(boundaryPanel, 10, 10);
Diagram diagram = new Diagram(boundaryPanel);
boundaryPanel.add(new Label("Connectors example"), 10, 2);

// Add connectors
Connector connector1 = new Connector(50, 80, 100, 100);
connector1.showOnDiagram(diagram);

Connector connector2 = new Connector(350, 200, 270, 80);
connector2.showOnDiagram(diagram);

Connector connector3 = new Connector(450, 120, 500, 80);
connector3.showOnDiagram(diagram);

// Add some elements that can be connected
Label label = new Label("LABEL");
Image image = new Image("http://code.google.com/images/code_sm.png");
HTML html = new HTML("<b>HTML<br>ELEMENT</b>");

boundaryPanel.add(label, 50, 270);
boundaryPanel.add(image, 180, 250);
boundaryPanel.add(html, 450, 250);

Shape shapeForLabel = new Shape(label);
shapeForLabel.showOnDiagram(diagram);

Shape shapeForImage = new Shape(image);
shapeForImage.showOnDiagram(diagram);

Shape shapeForHtml = new Shape(html);
shapeForHtml.showOnDiagram(diagram);

Ich bin gespannt, wann es das erste UML-Tool mit GWT gibt. gwt-connectores basiert im Übrigen auf Fred Sauer’s gwt-dnd. (Dazu auch das Demo http://allen-sauer.com/com.allen_sauer.gwt.dnd.demo.DragDropDemo/DragDropDemo.html.)

Dazu passt auch die Ankündigung von http://googledocs.blogspot.com/2009/03/drawing-on-your-creativity-in-docs.html, ein Zeichenwerkzeug in Google Docs einzubetten:

http://www.googlewatchblog.de/2009/03/26/google-docs-drawing-veroeffentlicht/ hat dazu ebenfalls ein Bild parat:

GWT Charting Bibliothek gflot und charts4j.

Alles fängt mit http://jquery.com/ an. Darauf baut auf http://code.google.com/p/flot/, eine JavaScript-Bib. für Chars:

http://code.google.com/p/gflot/ ist nun der GWT-Aufsatz auf flot.

Für eine Bar-Diagramm ist nur folgender Quellcode nötig:

final String[] MONTH_NAMES = { "jan", "feb", "mar", "apr", "may", "jun", "jul", "aug", "sep", "oct", "nov", "dec" };

PlotModel model = new PlotModel();
PlotOptions plotOptions = new PlotOptions();

BarSeriesOptions barSeriesOptions = new BarSeriesOptions();
barSeriesOptions.setShow(true);
barSeriesOptions.setLineWidth(1);
barSeriesOptions.setBarWidth(1);
barSeriesOptions.setAlignment(BarAlignment.CENTER);

plotOptions.setDefaultBarsSeriesOptions(barSeriesOptions);
plotOptions.setLegendOptions(new LegendOptions().setShow(false));



// add tick formatter to the options

plotOptions.setXAxisOptions(new AxisOptions().setTicks(12).setTickFormatter(new TickFormatter() {

public String formatTickValue(double tickValue, Axis axis) {

if (tickValue > 0 && tickValue <= 12) {

return MONTH_NAMES[(int) (tickValue - 1)];

}

return "";

}

}));


// create a series

SeriesHandler handler = model.addSeries("Ottawa's Month Temperatures (Daily Average in &deg;C)", "blue");


// add data

handler.add(new DataPoint(1, -10.5));

handler.add(new DataPoint(2, -8.6));
handler.add(new DataPoint(3, -2.4));
handler.add(new DataPoint(4, 6));
handler.add(new DataPoint(5, 13.6));
handler.add(new DataPoint(6, 18.4));
handler.add(new DataPoint(7, 21));
handler.add(new DataPoint(8, 19.7));
handler.add(new DataPoint(9, 14.7));
handler.add(new DataPoint(10, 8.2));
handler.add(new DataPoint(11, 1.5));
handler.add(new DataPoint(12, -6.6));

// create the plot
SimplePlot plot = new SimplePlot(model, plotOptions);

// put it on a panel
FlowPanel panel = new FlowPanel();
panel.add(plot);

return panel;

Eine Alternative dazu ist http://code.google.com/p/charts4j/  bzw. http://code.google.com/p/charts4j/wiki/GWT_Port.

Dozer 5.0

Letzten Monat ist Dozer 5.0 veröffentlicht worden. Vor einem Jahr hatte ich schon über Dozer berichtet: http://www.tutego.de/blog/javainsel/2008/01/bean-bean-mapping-mit-dozer.html. Neu beim Java-Bean-Mapper sind:

  • Added Generics to public api
  • Switched to XSD instead of DTD
  • Simpler packaging
  • Upgraded 3rd party dependencies
  • Upgraded code to use jdk 1.5 features
  • Various feature requests and bug fixes

Auch die Namen sind vereinheitlicht worden, nun heißt es org.dozer, BeanFactory, CustomFieldMapper, usw.

Wie das Mapping über XML-Dateien beschrieben wird, klärt das Dokument http://dozer.sourceforge.net/documentation/mappings.html genauer. Auch wenn Dozer nun Java 5 unterstützt, beginnt Dozer nicht mit Annotationen, um die Mappings zu beschreiben.

Derby Datenbank endlich auch pur In-Memory

Andere Java-Datenbanken können es schon lange, Derby kann es nun auch: Daten nur im Speicher ohne File-Backup halten. Die Derby-URL für dieses Feature lautet dann jdbc:derby:memory:datenbank;create=true. (Warum eigentlich nich einfach nur „mem“?)

Zum Weiterlesen: http://blogs.sun.com/kah/entry/derby_10_5_preview_in, http://wiki.apache.org/db-derby/InMemoryBackEndPrimer. Die aktuelle Derby-Datenbank kann man unter http://db.apache.org/derby/releases/release-10.5.1.1.cgi beziehen.

Thema der Woche: Micro-Benchmarks

Lies zunächst die folgenden Artikel

Versuche dann mit http://jetm.void.fm/index.html die Frage zu klären, wie groß der Unterschied ist, wenn man Threads für eine Aufgabe per Hand startet oder aus einem Thread-Pool holt.

Thema der Woche: Gof-Pattern-Wiederholung

Theoretische Aufgaben:

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

Praktische Aufgaben:

Thema der Woche: Matcher-Append-Replacement und Pig Latin

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

Lösungen sind wieder gerne willkommen.

Google Web Toolkit 1.6, Google Plugin for Eclipse

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

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.

Projekte und Pakete aus den langtools

Achtung! Nur gültig in für JDK 6, in JDK 7 gibt es Umbenennungen.

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:

Thema der Woche: NIO-Buffer

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.

EoD SQL hilft beim Mini-OR-Mapping aber nicht, um Girls zu kriegen

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

Google App Engine unterstützt Java

Google Plugin for EclipseNach 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:

Thema der Woche: Java™ 6u10 – Java6u13

In der letzten Java™ 6 Updates sind einige Neuigkeiten hinzugekommen. Einige sind JavaFX geschuldet.

Java 6u14 ist noch nicht fertig. Es gibt nur ein „Java™ Platform, Standard Edition 6u14 Binary Snapshot Releases“. Die Anzahl der gefixten Bugs ist groß. Lese dazu  http://download.java.net/jdk6/ und http://tutorial.fyicenter.com/out.php?ID=3688.

Na endlich: JDK 7 feature list, build and integration schedule

Mark Reinhold schreibt auf seinem Blog:

At Devoxx back in December I presented a list of candidate features for JDK 7(video, interview); more recently, at FOSDEM, I discussed that list as well as the high-level schedule and the means by which we plan to deliver the release (slides, audio/video). The high-level schedule is now available on the JDK 7 Project page in theOpenJDK Community along with a detailed feature list, the near-term build and integration schedule, and the long-term, build-by-build calendar. The JDK 7 feature list, like that of any large software project, is provisional and subject to change based upon new information and new proposals. Who Many of the planned features will be implemented by Sun engineers; the rest will be contributed from outside Sun. We’ll shortly define a process by which additional features can be proposed—so long as you’re willing to write not just the code but also the necessary tests and specification material. There will also be a simpler, lighter-weight process for smaller changes. Where Regardless of who writes the code, the expectation is that all development will take place in the open, either in the JDK 7 Project, in some other OpenJDK Project, or elsewhere. What about the JCP? The JDK 7 Project is creating a prototype of what might—or might not—wind up in the Java SE 7 Platform Specification. When the SE 7 Platform JSR is submitted then the features under development in JDK 7 will be proposed for inclusion therein, except for those that are VM-level or implementation-specific.

Der Kalender gibt Ende Februar an.

M8 2010/02/12 – 2010/02/18 b95

Die Feature-List ist interessant aber ich denke, dass einiges im Detail noch offen ist:

  • JSR TBD: Small language enhancements (Project Coin)
  • JSR 296: Swing application framework
  • Swing updates