PSP Emulator in Java (jpcsp)

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Java ist langsam? Nee, denn sonst würde man keinen PSP Emulator in Java programmieren, sondern in C(++)! Doch das Projekt http://jpcsp.org/ (bzw. http://code.google.com/p/jpcsp/) zeigt wieder einmal, wie leistungsfähig Java (plus ein paar nativer Bibliotheken) ist. Die Emulation ist modernen Spielkonsolen ist schwer, da sie mit spezieller Hardware vollgestopft sind, auch wenn die Prozessoren nicht wie in moderne PCs in Gigahertz-Bereich laufen. Die PSP hat mit einem auf MIPS 4000 basierenden RISC-Prozessor und einen “Media-Engine”-Chip, die JPCSP ausgezeichnet emuliert, was an die 300 Speile ausführbar macht: http://www.emunewz.net/forum/forumdisplay.php?fid=65. Der Code greift für die Media-Low-Level-Operationen auf http://lwjgl.org/ zurück. Es steckt sonst noch nativer Anteil drin, etwa für Raw-Sockets (das sind Sockets mit allen TCP/IP-Informationen, also auch den Headern, nicht nur den Transportdaten selbst, http://www.savarese.org/software/rocksaw/) oder eine Bib. namens Xuggler, was ein Java-Wrapper für FFmpeg ist.

Neue JavaFX-Version (build 42), mal wieder API-Änderungen

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Download unter http://javafx.com/. Änderungen betreffen wohl nahezu jedes Hauptprogramm, denn setVisible(true) wird zu show() und setVisible(false) zu hide(). Das ist natürlich super ungewöhnlich, da AWT genau den anderen Weg gegangen ist, und eben Bean-Methoden einführte. 2.: Die Builder sind in ein andere Paket gerutscht, so fällt weg: import javafx.builders.SplitPaneBuilder;
Achtung: Die Online-Doku ist im Moment noch nicht auf dem neusten Stand.

Wicket 1.5 jetzt raus

~ Christian Ullenboom ~ 2 Kommentare

Siehe http://wicket.apache.org/2011/09/07/wicket-1.5-released.html.

Most notable changes

With this release the Wicket team has revised many of its internals. A short list:

  • HTML5 components added: EmailTextField, NumberTextField, UrlTextField and RangeTextField
  • New inter-component events (explained below)
  • Minimum required servlet API is servlet-api 2.5
  • All standard validators now extend Behavior to allow for client side validations
  • IBehavior has been removed and AbstractBehavior has been deprecated, you should now extend Behaviorinstead
  • Simplified the request cycle processing and made it more extensible
  • URL handling is now in one place
  • Wicket’s rendering code has been greatly simplified
  • Improved browser caching support
  • ClientSideImageMap replaces old ImageMap
  • Better support for running behind proxies with x-forwarded-for header
  • Request cycle listeners make it easier to integrate frameworks in your Wicket application
  • Consistent naming: methods with Javascript in the name have been renamed to use proper capitalization:JavaScript
  • Switching to HTTPS is as simple as configuring a new root mapper to make Wicket HTTPS aware and annotating a page with @RequireHttps

A longer list of changes and improvements can be found in our migration guide.

Gastbeitrag: AWT-Schwergewichte nach vorne, bitte!

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Der Code hinter Container.add(Component comp) hat sich immer wieder gewandelt, und lange Zeit war es problematisch, AWT- und Swing-Komponenten zu mischen. Seit Java 7 stellt das AWT jedoch jede mögliche Kombination von beliebigen Komponenten zuverlässig dar – den zusätzlichen Rechenaufwand bekommt jeder zu spüren, der etwa versucht, eine JScrollPane mit 50.000 JLabels zu bestücken.

Weiterlesen →

Tester für einfache iCalendar Klasse gesucht

~ Christian Ullenboom ~ 1 Kommentar

Für alles rund um iCal ist http://wiki.modularity.net.au/ical4j/index.php die Standardlösung. Allerdings ist mir das zu fett und hat auch noch diverse Abhängigkeiten. Daher habe ich mir eine einfache Klasse gebaut, die iCal-Dokumente für Events erzeugt.

String s = new ICalendar()



            .start( new Date() )



            .end( new Date() )



            .summary( "Ba,st;ille\\ Day Party\näöß" )



            .toString();



System.out.print( s );


erzeugt:


BEGIN:VCALENDAR

  
VERSION:2.0


PRODID:-//tutego//NONSGML ICalendar//DE


BEGIN:VEVENT


DTSTART:20110904T200944


DTEND:20110904T200944


SUMMARY:Ba\,st\;ille\\ Day Party\näöß


END:VEVENT


END:VCALENDAR 




Möchte das jmd. testen und mit Tipps geben?

Was ist JavaFX?

~ Christian Ullenboom ~ 1 Kommentar

AWT und Swing sind bisher die Standardlösungen für grafische Anwendungen unter Java. AWT bildet das Fundament mit Ereignisbehandlung, Fenster-Management und einer mächtigen 2D-API. Swing sitzt auf dem AWT und ist eng mit ihm verbunden. Es realisiert die Komponenten, die zum Teil selbst in Java implementiert sind, manch ein Look and Feel – wie im Fall von Windows – lässt die Komponenten nativ vom Betriebssystem zeichnen.

Swing und AWT sind mächtig, aber es hat sich in den Letzen Jahren nicht großartig weiterentwickelt. Insbesondere gibt es Lücken im Bereich Medien und Animation, etwas, was bei modernen grafischen Oberflächen heutzutage gefragt ist. Statt das Sun/Oracle in die Weiterentwicklung investiert, hat sich das Unternehmen für eine komplette Neuentwicklung der GUI-Ebene entschieden, die nichts mehr mit Swing/AWT gemeinsam hat: JavaFX.

JavaFX ist eine Komplettlösung mit einer API für

· GUI-Komponenten

· HMTL/CSS/JavaScript mit eingebetteten Web-Brower

· Animationen

· Video

· Audio

· 2D und 3D

Da JavaFX komplett alle APIs für moderne Oberflächen anbietet, und auch nicht von AWT/Swing abhängig ist, bildet JavaFX einen kompletten Media-Stack. Die Betonung liegt auf Media, denn die AWT/Swing-API im Java SE kann keine Medien einbinden oder abspielen. Zwar ist JavaFX auch noch kein Teil der Java SE, doch das kann sich ändern. Über Profile sollte JavaFX auch auf mobilen Endgeräten und im Internet wie Applets laufen, allerdings ist eher davon auszugehen, das JavaFX es bei Rich-Client-Anwendungen Einzug hält und dort AWT/Swing verdrängt. Es ist nicht abzusehen, dass JavaFX im Internet als Flash-Ersatz oder auf mobilen Endgeräten punkten kann, dafür ist die Kombination HTML5 + CSS3 + JavaScript zu attraktiv.

Anders als AWT ist die JavaFX-Implementierung auf der Höhe der Zeit und greift direkt auf alle 2D/3D-Fähigkeiten moderner Grafikkarten zurück. So kann mit JavaFX alles das programmiert werden, was bisher eher mit Flash gemacht wurde, wohl aber fehlen noch die tollen Entwicklertools. Es gibt Plugins für Adobe Photoshop und Illustrator, mit denen Grafiken und Pfade exportiert werden können, aber eben keine ganzen Animationen, die etwa mit Adobe Flash erzeugt wurden. Und seit dem Adobe Flash auch HTML5 exportiert, öffnet sich eine ganz neue Welt.

 

Geschichte

JavaFX ist schon sehr lange in Entwicklung und viele interne Swing-Entwickler wurden auf das Projekt angesetzt – daran liegt es wohl auch, dass bei Swing nicht mehr passierte. Im Jahr 2003 wurde JavaFX dann auf der SunOne Konferenz vorgestellt, zusammen mit der Programmiersprache Java FX Script. Die Sprache macht es einfach möglich hierarchische Objektgrafen aufzubauen, und bot eine nette Syntax für Objekt-Bindung, doch wurde sie für die aktuelle Version JavaFX 2.0 fallen gelassen. Oracle wollte keine weitere Programmiersprache, sondern eine pure Java API, die sich von unterschiedlichen existierenden Skriptsprachen dann ansprechen kann. Das ist sicherlich eine gute Entscheidung, denn unter Groovy sieht das sehr schlank aus, fast wie mit JavaFX Script auch (http://groovy.codehaus.org/GroovyFX).

Microsoft Office-Dokumente in Java verarbeiten

~ Christian Ullenboom ~ 3 Kommentare

Auch wenn sich die Welt nach freien und quelloffenen Lösungen sehnt, Microsoft Office ist immer noch eines der bestverkauftesten Produkte auf diesen Planeten mit dem MS-Dokumentenformat als Sonne im Mittepunkt. Da die Dokumentation von Microsofts Dateiformaten mittlerweile zugänglich[1] sind, gibt es auch Java-Bibliotheken, die MS-Office-Dokumente einlesen, modifizieren und schreiben. Bekannt dafür ist Apache POI[2] (http://poi.apache.org/), was APIs für folgende Formate (Komponenten genannt) bietet:

POI-Komponete

Aufgabe

Grad der Unterstützung

HSSF, XSSF

Excel XLS, Excel XLSX

Gut

HSLF, XSLF

PowerPoint PPT, PowerPoint PPTX

Ausreichend

HWPF, XWPF

Word DOC, Word DOCX

Befriedigend

HDGF

Visio VSD

Rudimentär, nur lesen

HPBF

Publisher PUB

Rudimentär, nur lesen

HMEF/HSMF

Outlook MSG/ Microsoft TNEF (Transport Neutral Encoding Format)

Rudimentär, nur lesen

OpenXML4J

Open Packaging Conventions (OPC)/OOXML

Gut

POIFS

OLE 2 Compound Document (OLE2 Filesystem)

Sehr gut

HPSF

OLE2 Property Sets

Sehr gut

POI-Komponenten nach http://poi.apache.org/overview.html#components

OpenXML4J und POIFS sind keine üblichen Dokumentenformate, aber Archivformate für Microsoft-Dokumenten (analog zu Zip). HPSF erlaubt Zugriff auf Datei-Metadaten wie Autor, Titel, usw.

Neben POI gibt es nicht mehr so viele Alternativen, eher kleinere Bibliotheken, die sich auf ein Formate spezialisiert haben. So etwa http://jexcelapi.sourceforge.net/ für Excel, was eine sehr einfache und intuitive API hat, aber beim Lesen oft Probleme bereitet. Nur wurde es bisher seit 2 Jahren nicht mehr aktualisiert. Eine kommerzielle Lösung bietet Aspose (http://www.aspose.com/categories/java-components/aspose.total-for-java/default.aspx). Für den Zugriff auf MS Access Datenbanken gibt es die quelloffene Bibliothek http://jackcess.sourceforge.net/, die auch eine sehr aktuelle fluent API hat. Auf MS Access lässt sich aber auch per ODBC zurückgreifen, das Datenbankkapitel gibt eine kleine Übersicht.

Das neue Office-Format basiert auf XML und so auch deutlich einfacher zu verarbeiten als das binäre Format. Es ist im Office Open XML beschrieben. Für Word-Dokumente gibt es zum Beispiel das relativ neue Projekt java2word (http://code.google.com/p/java2word/).

Neben dem Office Open gibt es das OASIS Open Document Format – mit Dateiformaten wie OpenDocument (ODF) für Textdokumente – die etwa von OpenOffice verarbeitet werden. Eine Bibliothek zum Verarbeiten bietet das ODF Toolkit (http://odftoolkit.org/).

 

Fehlt noch was?

[1] http://www.microsoft.com/interop/docs/officebinaryformats.mspx

[2] POI steht für „Poor Obfuscation Implementation“, weil das Dateiformat so kryptisch ist. Die Kürzel der Komponenten beginnen in der Regel mit „H“ was für „Horrible“ steht .

Java™ Platform, Standard Edition 7 Update 2 Binary Snapshot Releases

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

http://jdk7.java.net/download.html

Änderungen:

http://hg.openjdk.java.net/jdk7u/jdk7u/ws-b02-2011-08-12_39

Changeset

Bug ID

Synopsys

831f1dadcc35

7057705

can’t generate api docs for JDK7 updates

http://hg.openjdk.java.net/jdk7u/jdk7u/jdk

Changeset

Bug ID

Synopsys

f01230bea4aa

7043737

klist does not detect non-existing keytab

9847e43556fb

7029903

Splash screen is not shown in 64-bit Linux with 16-bit color depth

175f98d43a12

7062969

java -help still shows http://java.sun.com/javase/reference

440d5a3cfdf8

7067922

(launcher) java -jar throws NPE if JAR file does not contain Main-Class attribute

a5ea1f537169

7039182

PPC: NIO: java.io.IOException: Invalid argument in sun.nio.ch.FileDispatcherImpl.read0

http://hg.openjdk.java.net/jdk7u/jdk7u/langtools

Changeset

Bug ID

Synopsys

ceb7ca04b7eb

7060926

Attr.PostAttrAnalyzer misses a case

2f2ac80b6836

7061125

Proposed javac argument processing performance improvement

130154dbafc8

7068902

(javac) allow enabling or disabling of String folding

8b6f8a4bc8b8

7060642

(javadoc) improve performance on accessing inlinedTags

fda5571c663a

6735320

StringIndexOutOfBoundsException for empty @serialField tag

add40922e84d

7059905

(javadoc) promote method visibility for netbeans usage

Deklarative JavaFX-Oberflächen mit FXML

~ Christian Ullenboom ~ 2 Kommentare

Den Szene-Graph über Java Programmcode aufzubauen ist eine Möglichkeit, doch JavaFX erlaubt es auch, die Objekte über XML zu konfigurieren. Das erlaubt es viel einfacher, grafische Oberflächen über Gui-Builder aufzubauen und sauber das Layout (was) vom Code (wie) zu trennen.

Die hierarchische Struktur von XML passt natürlich prima zu der Hierarchie, die es bei grafischen Oberflächen gibt: Ein Fenster enthält Container, die wiederum Elemente enthalten, usw. Für unser kleines Beispiel soll eine Oberfläche drei Elemente bieten: Eine Beschriftung, ein Textfeld und eine Schaltfläche. Drückt der Anwender die Schaltfläche, soll der Text im Textfeld in Großbuchstaben konvertiert werden.

Die XML-Datei covert2UpperCase.fxml sieht so aus:

<?xml version="1.0" encoding="UTF-8"?>

<?import javafx.scene.layout.*?>
<?import javafx.scene.control.*?>

<HBox xmlns:fx="http://javafx.com/fxml"
      fx:controller="com.tutego.insel.javafx.ButtonController">
  <children>
    <Label text="Eingabe: " />
    <TextField fx:id="input" />
    <Button text="Konvertiere" onAction="#convertAction" />
  </children>
</HBox>

Die Hierarchie ist gut zu erkennen. Die interessanten Dinge sind andere:

  1. Zu Beginn gibt es eine Art import-Anweisung um Typnamen nicht voll qualifizieren zu müssen. Für den Rückgriff auf Grafiken muss <?import javafx.scene.image.*?> eingebunden werden und <?import javafx.scene.*?> für Group, Node oder ähnliches, was wir im Programm aber alles nicht nutzen.
  2. HBox hat zwei Attribute: Ein Attribut deklariert den Namensraum fx, ein anderes eine Klasse, den sogenannten Controller, der später die Ereignisbehandlung für den Klick übernimmt. Die Typen in FXML heißen genauso wie die Klassennamen. Natürlich könne auch eigene Klassen eingebaut werden, sofern sie mit <?import> bekannt gemacht wurden.
  3. Das TextField bekommt mit dem Attribut fx:id eine ID zugewiesen, unter der das Textfeld später erfragt werden kann. JavaFX geht noch einen Schritt weiter, und bildet das Objekt mit der ID automatisch auf ein Attribut der Controller-Klasse ab. Label und Schaltfläche brauchen keine IDs, da sie nicht erfragt werden müssen.
  4. Das Attribut onAction der Schaltfläche referenziert Programmcode, der immer aufgerufen wird, wenn die Schaltfläche gedrückt wird. Hier kann direkt Java-Quellcode stehen, oder, wie in unserem Fall, ein # und der Name einer Methode, die in einem Controller deklariert werden muss. Den Klassenamen vom Controller haben wir am Wurzelelement deklariert.

Die Ereignisbehandlung ist komplett aus der FXML-Datei rausgezogen und wandert in Controller-Klassen. Die eigene Klasse ButtonController, die voll qualifiziert bei fx:controller genannt wurde, enthält:

com/tutego/insel/javafx/ButtonController.java

package com.tutego.insel.javafx;

import javafx.event.ActionEvent;
import javafx.fxml.FXML;
import javafx.scene.control.TextField;

public class ButtonController
{
  @FXML
  private TextField input;

  @FXML
  protected void convertAction( ActionEvent event )
  {
    input.setText( input.getText().trim().toUpperCase() );
  }
}

Drei Dinge fallen ins Auge:

  1. Die Controller-Klasse erweitert keine Schnittstelle.
  2. Die Annotation @FXML sagt, dass der Verweis auf das TextField-Objekt aus dem Szene-Graphen in die Variable input injiziert werden soll.
  3. Da in der FXML-Datei an der Schaltfläche ein onAction="#convertAction" steht, muss das zu einer Methode zugeordnet werden. Die Annotation @FXML an der Methode unter dem Namen convertAction stellt diese Beziehung her.

Das Hauptprogramm ist nun relativ einfach:

com/tutego/insel/javafx/FXMLDemo.java, start()

@Override
public void start( Stage stage ) throws Exception
{
  Parent p = FXMLLoader.load( getClass().getResource( "covert2UpperCase.fxml" ) );
  stage.setScene( new Scene( new Group( p ), 500, 400 ) );
  stage.setVisible( true );
}

Was noch alles mit FXML möglich ist, beschreibt ein Dokument von Oracle: http://fxexperience.com/wp-content/uploads/2011/08/Introducing-FXML.pdf.

Neuer JavaFX b40 Build

~ Christian Ullenboom ~ 1 Kommentar

Änderungen: Kein Zip mehr zum Auspacken, sondern eine exe. Keine Demos mehr dabei. APIs ändern sich, viele Beispiele muss ich anpassen. Bei einer Beta ist das natürlich OK, dennoch überlege ich mir, ob ich JavaFX unter diesen Umständen überhaupt in die Insel setzen kann. An großen FX-Apps kann man so nicht denken, die Änderungen machen einen verrückt.