JavaOne - Day 4 - All in the Details

by Sue Spielman

JavaOne has certainly been focused on the WS/Wireless areas. And what they both have in common, at the core, is the prolific use of XML. Most of us have been dealing and working with XML for quite some time now. It is important to be as productive as possible when dealing with XML so that we can all concentrate on building the services and apps that utilitize it. Until recently, there's been some amount of elbow grease needed to parse and do data bindings. I'm sitting in some of the specific implementation sessions today to get a sense of what's coming down the pike that can be applied to upcoming development. I Thought I'd share some of the new features on the XML and Mobile front to give you a sense of what should be up in the very near future.

Enter JAXB. JAXB (JSR-37) is the XML binding for Java objects spec. It can be found in the javax.xml.bind package. JAXB allows for the automation of Java binding. It uses W3C XML Schema definition (a common theme in many JSR's is that DTDs seem to be slowly drifting away, in case you haven't noticed). The expert group is working on the community draft at the moment, but here are some highlights of what to expect. JAXB will support:

  • Subset of XML Schema and XML Namespaces

  • More flexible unmarshalling/marshalling capabilities

  • Enhanced validations

  • API level changes to allow for alternate implementations (before you were forced to have a pull-parser, but now you can use SAX if you want)

  • The fundemental changes that are being made to JAXB will allow for more flexibility of implementations.

    XML Binding is used for mapping instances of an XML document to in-memory Objects. The binding facility consists of a binding compiler which binds the schema to derived classes. While this is only one way to go, and seems to be the direction at the moment (XML->Objects), the future looks like it will have both Objects to XML documents. This means you will be able to have a JavaBean and generate the Schema from it. When compiling, there are options that allow the validation to be turned off. This flexiblity will allow users to determine when to run the validation. Seems that the validation code generated by the compiler can be almost 1/3 of your code space and have some significant performance hits.

    It's also possible to use the Schema and include Binding Schema information in the the same logical document. This allows for setting default rules as well as specifying custom bindings in the Schema. We'll be able to override defaults for XML->Java name mappings, XML data types -> Java data types, as well as XML Namespaces -> Java package names. Included will be meta-level customizations to override the default values. Fine-grained XML components can be mapped to primitive, reference, and Collections, although the specific Collection support is still up in the air at this point.

    On the MIDP front, I sat in the MIDP-NG (MIDP 2.0) session. JSR-118 has been in progress for the past year and just entered public review last week. There's lots of new stuff going into the next generation of MIDP including functionality for application delivery, UI, Multimedia, Security, and Networking. In the app delivery area, OTA (Over The Air) provisioning is formally being added to the spec, enhancements are being made to enable reliable delivery service, and there'll be notifications for successful install and deletion of a MIDlet. Some UI enhancments (all built on lcdui) include: custom item support, layout control, and graphical enhancements (including transparent image support). Also coming: a rich set of Game API's for 2D games and Sound API's. This will allow for rich sound audio for MIDLets including tone generation. And sampled sound files (i.e. wav, MIDI files). JSR-135 (now called Mobile Media) is a superset of what's being provided in JSR-118.

    Security is playing a key role (no pun intended) in the NG spec. Untrusted apps will follow the same sandbox model as in MIDP 1.0. Trusted apps will have permissions on the device for restricted APIs. There will be one Protection Domain for each MIDLet suite. It will be up to the device to implement the policy as it's not being specified in JSR-118. The reason for this is that security policy is device- and market-specific. Certificates will be able to live on the device as well. Permissions (a boolean, granted or denied) can be applied:

  • blanket - until the permission is revoked by the app

  • session - single invocation

  • oneshot - single call to API

  • There are also a number of network enhancements coming. Sockets have been added, as well as UDP Datagram support. Support will be available for HTTPS (using SSL 3.1, TLS 1.0, WTLS). APIs are coming to get socket options, as well as have dynamic port assignments made so that the AMS can support push to the device on incoming socket requests. However, it will be up to the AMS to support whichever protocols are applicable to the device. So beware when designing and writing your MIDLets.

    There certianly has been a lot going on at the conference the last few days. Four days down, one to go. Someone get me some (more) coffee.