Die Informationen von Mikroformaten lassen sich mit JAXB relativ leicht in XML konvertieren:

import java.util.*;
import javax.xml.bind.*;
import javax.xml.bind.annotation.*;

public class MicroformatViaJaxb
{
  public static void main( String[] args ) throws JAXBException
  {
    Microformat mf = new Microformat();
    mf.elements.add( new Element( "name", "Christian Ullenboom" ) );
    mf.elements.add( new Element( "address", "tutego Allee" ) );
    mf.elements.add( new Element( "phone", "2873568956928" ) );

    JAXBContext context = JAXBContext.newInstance( Microformat.class );
    Marshaller m = context.createMarshaller();
    m.setProperty( Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE );
    m.marshal( mf, System.out );
  }
}
@XmlRootElement( name = "div" )
class Microformat
{
  @XmlAttribute( name = "class" )
  public String key = "person";
  @XmlElement( name = "span" )
  public List<Element> elements = new ArrayList<Element>();
}
class Element
{
  @XmlAttribute( name = "class" )
  public String key;
  @XmlValue
  public String value;
  public Element() { }
  public Element( String key, String value )
  {
    this.key = key;
    this.value = value;
  }
}

XML HK2 WSIT ESB JMS SSO SAO JSR JAX-RS JCP DOJO AJAX WSDP jBMP RIFE RAILS MC4J CAPS SAML WS-* WSRP SAW JXTA HTTP URL IIOP ORB JMX TCP/IP WSDL MEX XWSS MTOM XSD SMTP WSA SOAP JBI JCA CMT LDAP BMT CMPI VJM CDDL GPL BSD API JAX-B StAX JSP JSTL EJB JPA TCK JDBC JDK JRE JAXP XOP REST POJO SQL GUI URI XMLDSig JAAS GSSAPI META-INF NIO ACL JNL CORBA CDC CLDC MIDP ACID SSL DRDA UML SAX DOM XOM XML-RPC MVC XSLT DAO SVG COM FTP PDF JNA ANTLR SLF4J WiX

Alles klar?

Mit 10 oder so hatte ich meine erste, ich erinnere mich noch genau, ich hatte sie in einem Buch kennengelernt. Basic war ihr Name. Immer was verträumt, aber eine treue Seele. Ich war jung, sie auch, wir stellen keine wilden Sachen an. Ein Jahr später lerne ich Assembline kennen, WOW, das war eine zackige Braut, der war ich lange treu. Ganz schmutzige Sachen haben wir gemacht, sie war auch ein bisschen devot. Bin dann umgezogen nach Amiga-City und hatte mich in die ältere Schwerster von Assembline verguckt, die war auch heiß und ging ganz schön ran. Da war ich um die 14. Aber ich wurde älter und mit Assembline war es immer so anstrengend, sie war total nachtragend, jeden kleinen Fehler nahm sie mir übel und wollte dann erst mal nicht mehr mit mir sprechen. Also habe ich Schluss gemacht. Zu der Zeit hatte ich auch Pascaline und Zee kennengelernt und viel erlebt, was man eben zu Dritt so macht. Das ging dann so ein paar Jahre, aber jetzt habe ich fast seit 20 Jahren nur noch eine: mein Java-Mäuschen. Die hat mir auch den g-Punkt und fillRect gezeigt, hui. Manches Mal zeigt sie mir den roten Kringel, aber mit ihr kann ich fast alles machen. Und was mich früher an Assembline scharf machte (ich sage nur „bare metal“), interessiert mich heute überhaupt mehr. Passt also, eine glückliche Beziehung.

https://blogs.oracle.com/java/entry/java_se_7_update_25. Mit den üblichen Security-Udates und sonst noch ein paar Änderungen: http://www.oracle.com/technetwork/java/javase/7u25-relnotes-1955741.html. Nicht uninteressant finde ich folgendes, was die Kompatibilität von existierenden Anwendungen beeinflussen könnte:

Changes to Runtime.exec

On the Windows platform, the decoding of command strings specified tojava.lang.ProcessBuilder and the exec methods defined by java.lang.Runtime, has been made stricter since JDK 7u21. This may cause problems for applications that are using one or more of these methods with commands that contain spaces in the program name, or are invoking these methods with commands that are not quoted correctly. For more information see JDK 7u21 Release Notes.

In JDK 7u25, the system property jdk.lang.Process.allowAmbigousCommands can be used to relax the checking process and may be used as a workaround for some applications that are impacted by the stricter validation. The workaround is only effective for applications that are run without a security manager. To use this workaround, either the command line should be updated to include -Djdk.lang.Process.allowAmbigousCommands=true or the java application should set the system property jdk.lang.Process.allowAmbigousCommands to true.

Quoting and escaping commands on Windows platform is complicated. The following examples may be useful to developers if they are impacted by the stricter validation.

Example 1: The application needs to be launched with C:\Program Files\foo.exe.

Here are 3 possible ways:

Process p = new ProcessBuilder("c:\\Program File\\foo.exe").start();
Process p = Runtime.getRuntime().exec(new String[] { "c:\\Program File\\foo.exe" });
Process p = Runtime.getRuntime().exec("\"c:\\Program File\\foo.exe\"");

Where it is not possible to change the application to use one of the above approaches, then the system property jdk.lang.Process.allowAmbigousCommands may be used as a workaround.

Example 2: The application needs to launch "dir > dir.out".
This case requires launching cmd.exe, and also it needs the output to be redirected to a file. The best approach is to use the ProcessBuilder as shown in the following example:

Process p = new ProcessBuilder("cmd", "/C", "dir").redirectOutput(new File("dir.out")).start();

Where it not possible to change code to use ProcessBuilder or redirectOutput, then the following approaches can also be used:

Process p = new ProcessBuilder("cmd", "/C", "dir > dir.out").start();
Process p = Runtime.getRuntime().exec("cmd /C \"dir > dir.out\"");

Example 3: The application wants to launch a command with parameters that require special quoting; for example "log.bat \">error<\"".
Here are 3 possible ways to do this:

Process p = new ProcessBuilder("cmd", "/C", "log.bat", ">error<").start();
Process p = Runtime.getRuntime().exec(new String[] { "cmd", "/C", "log.bat", ">error<" })
Process p = Runtime.getRuntime().exec("cmd /C log.bat \">error<\"");

Normalerweise nimmt eine JVM den Bytecode der Hauptklasse, lädt zur Laufzeit Klassendateien nach, interpretiert diese und übersetzt sie Zwecks Optimierung in Maschinencode. Dem gegenüber steht ein anderer Ansatz, der sonst eher typisch für klassische Programmiersprachen ist, genannt ahead-of-time-Compilation. Bei diesem Verfahren ermittelt ein Werkzeug zunächst alle abhängigen Typen und generiert dann direkt Maschinencode für eine Plattform — kein Interpreter ist somit nötig. Für Java sind solche Compiler selten, aber wer Java auf iOS-Geräten nutzen möchte, kommt darum nicht herum, denn Apple gestattet keine interpretierten Sprachen auf den kleinen Geräten. Dafür springt RoboVM (http://www.robovm.org/) ein, eine Open-Source-Software unter der GPL- und Apache-Lizenz, die Java-Programme direkt in Maschinencode (ARM bzw. x86 Code) übersetzt. Zum Bauen der Zieldateien nutzt RoboVM unterschiedliche Tools, um eine Kette von Schritten zu realisieren: Zunächst übersetzt ein installierter LLVM den Bytecode in Assembler-Code, dann folgt ein Tool, was Assembler-Code in Binärcode umsetzt, und dann ein Linker für den letzten Schritt, der das Ergebnis zusammensetzt; Assembler und Linker kommen vom GCC. Die Übersetzung ist kein großer Akt, denn für RoboVM ist ein Eclipse-Plugin verfügbar, in dem die App auch – zumindest beim Mac – im Simulator gestartet werden kann.

RoboVM bietet den Entwicklern die Standard-Klassen der Java-Bibliothek sowie sie auch bei Android verfügbar sind und bildet die Klassen der iOS-Bibliothek (genannt Cocoa) auf Java ab. Weiterhin integriert es die Typen vom Android-Paket und die OpenGL ES API, sodass Android-Anwendungen auch unter iOS abgebildet werden können. Interessant wird das Projekt auch durch eine Umsetzung von JavaFX, sodass die proprietären Cocoa-Bibliotheken nicht verwendet werden müssen, und es im Prinzip möglich ist, die gleiche Java-Anwendung auf iOS oder Windows, Linux, … zum Laufen zu bringen. Bisher ist RoboVM in einer frühen Phase.