A brief update on what's happening this year at JavaOne in the Mobile device space, the domain I was most interested in? One major announcement - although not completely unexpected - was the convergence of J2ME platforms and variations into one single Mobile Service Architecture implemented through 2 stacks. JSR-248 defines a low-budget, but less flexible mass-market device; JSR-249 defines the functionality for mid to high end devices style SmartPhone with enhanced levels of manageability. It is exactly this manageability that will be one of the challenges for the next few years. With so many (legacy) variations in the market dealing with embedded software deployment will become an increasingly complex issue. JSR-233 (J2EE Mobile Device Management and Monitoring Specification) and JSR-246 (Device Management APPI) define java interfaces to management systems, the latter for the device, the former for integrating management functions into the back-end infrastructure. JSR-233 extends JSR-124 J2EE Client Provisioning (also known as ?The Vending Machine?)

JSR-232 (Mobile Operation Management) defines embedded service interaction and is based on the OSGi industry standard (http://www.osgi.org). This specification will allow concurrent embedded applications to be deployed in such a way that component dependencies and access control are preserved. This runtime model is currently used by vendors such as Nokia on SmartPhones, SiemensVDO and IBM in Telematics and on residential gateways by e.g. Motorola. Wednesdays keynote showcased both Nokia and IBM showing tools facilitating the development of such applications.

JSR-179 (Location API for J2ME) nicely abstracts the need embedded applications might have for locating themselves from the underlying implantations. Devices (such as phones) might get location data from the network, the local cell and/or (Assisted)GPS. What counts is the desired interval and the required quality of service. Initialization of the GPS (fixing) might take more time then a user might expect (minutes!) and some programming techniques should be applied to work around the latency and storage issues inherent to mobile devices.

One session had an interesting analysis on the current state of the art: MIDP 1 was nice but not realy useful for real application deployment due limited API availability and the lack of security. MIDP 2 solves most of these problems and can very well be used for corporate application. However, for end-user services the deployment is very complicated and for now in practice only possible though the network provider. Read: Business to Consumer will need to be resolved by widely implementing the management API's mentioned earlier in this summary.

What was missing for me this year? Automotive/Telematics. Java will hit the Blu-Ray/Multimedia market before it will proliferate to our cars... It once seemed to be the other way around....

It was also interesting at JavaOne to walk in the exhibit hall where the sponsors explain their product and services. I'd like to point out a funny story that happened to my at the Sun corner there. I was impressed with the many clever projects shown at the Sun corner, as the looking glass project. Then I saw "JavaHelp for desktop" on a wall. Oh, that's interesting: Sun will provide, part of Java SE 6, an integrated help system. It looks similar to the system proposed by Eclipse RCP. So I started a dialog with the girl doing the demos: John: Hey, looks nice. Girl: Thank you. Do you know JavaHelp ? John: No, and I?d like to know more. Can you tell me the feature difference between JavaHelp and the Eclipse help system ? Girl: Hum, .... mmmm .... you know, we propose NetBeans, and ... John: No, no, I don't mean the Eclipse Java IDE to develop Java programs. I mean the Rich Client Platform that let you run a Java business application into the Eclipse container, so you may benefit, for example, of the help system for your Java application. It's cool that now we can have that with Java SE. Girl: Hum, .... mmmm .... I don't know, you should ask the question to my colleague, please wait a minute.

An senior man who apparently was more involved in the JavaHelp project came and we started the discussion:
John: Good morning. I just discover the existence of JavaHelp. Interesting. I've a stupid question.
Man: go on.
John: How do you compare, technically, JavaHelp with the Eclipse RCP help system?
The man turned green and looked at me as it I was a Muslim terrorist.
Man: Hum, .... mmmm .... We don't do Eclipse, we work with NetBeans. You should ask your question to the marketing department.
John: I'm sorry, probably my English is too bad and my question is not clear. I don't talk about Eclipse as a Java editor.
Man: I've understood your question, but you have a press/analyst badge and I can't answer to you. Please go and ask your question to a salesman.
John: Oh, I completely forgot. I find your idea of JavaHelp in Java SE pretty and I asked you this question because I practice desktop programming myself. I did not intend to write anything on it.
Man: Please see with a salesman.

I wish I went to the salesman to tell you what happened (because he would not have been able to answer such a technical question), but I didn't.

I'd like to join Robin in his ?SpringOne?? post yesterday. Sun pushes hard to provide what developers needs (at last) for productivity in the standard Java stack. But they look like upset by competition. The only Eclipse session happened in the smallest room of the conference and was fully booked days before the conference begins (pretty rare).

JavaOne - Day 4 Summary

Today was the last day of the JavaOne conference 2005. So, this is the final episode of my talk. As usual, the last general sessions are showcases of cool things possible in the different Java domains, consider it as ?toy day?. It was also difficult to find some interesting sessions today. I?ve the impression that all the sessions that didn?t fit in one of the first three days have to fit in day 4. This is clearly the round-up of the conference. For me, today = mobility day. This year, the focus of the toy day was on Java in the mobility space. There has been shown 5 hip demos of which almost of them dealt in one way or the other with mobility.

All of the SUN demos were running on the Netbeans IDE; guess why . Of course, it?s their own product and it?s not bad at all, but while SUN is advocating the ?community? spirit during the whole JavaOne conference, SUN is almost the only one that still focus on Netbeans while the rest of the ?community? clearly made the move to Eclispe, well-or-not enriched with a bunch of plug-ins. One day, they?ll get the message I hope, but when I read Cedric Beust's impressions on JavaOne way back in 2002 (http://www.beust.com/javaone2002.html), I found out that he's also referring to anoying Netbeans pop-ups during general sessions.

Talking about plug-ins.. The message is clear: ?Everybody does it, everybody should it? (Just a phrase from George Michael?s ?I want your sex?). Almost every vendor, community or individual is writing plug-ins to do whatever what. Nice to see such a creative and constructive movement!

The first one was a demo where from within the Netbeans IDE you could ?move? a Java application from one machine to another. Here I?m not talking about J2EE applications running on an application server where hot(re)deploy solves this for you, but about straight J2SE applications. The IDE had a visual representation of the two machines and you could simply drag and drop the app from machine A to machine B, just as you drag en drop objects. Really cool!!! Also nice to see, that this all happens at runtime! When moved, you could see the app stopped working on machine A and started on machine B. This creates a lot of opportunities in the mobile space to transfer Java applications among mobile devices.

The second demo had showed the future evolution of Swing using rich Swing components in Netbeans. Nice to see of course; the demo was pretty cool (CD library and integrated player), but this doesn?t add anything that was not present in, let?s say, Visual Basic 3.0 or Delphi almost one decade ago. I admit that this is nice to see these things in the Java world, but at the end of the day, it didn?t add anything more than the basic concepts of visual programming; meaning that you pick a Swing ?component? from a palette, drop it on a canvas and set some properties. Haven?t we done that all 10 years ago when the first visual programming tools appeared on the Windows front? The third demo was quite impressing. It had to do with J2ME development and debugging. When you develop J2ME applications, you usually build them in an IDE and test and debug them against a software emulation of a mobile device. Well? what we saw today allowed doing real-time debugging of your J2ME application, even wireless via Bluetooth, directly on the device. Is this cool or not?

The last but one demo showed how water sensors in the ocean here in the Bay area do some water analysis and use a mobile device to dial in into the network to transfer the information to an application that monitors the water quality, triggering some alarms when necessary.

The last demo showed the use of Real Time Java for autonomous navigation of unmanned aircrafts. Boeing is doing some experiments (Scan Eagle) with unmanned aircrafts where a RT Java application is the pilot. Scary or not, judge yourself.

The nicest thing about it is that the RT Java application acts as a Web-Service! To me this is the weird web-service I?ve seen so far. Flying back to Belgium tomorrow, I convinced myself that this kind of technology is (still) not used in their 747-400 airliner.

Continuing in the mobility space, I attended the ?Blueprint for creating high-performance portable J2ME applications?.

What are today?s challenges for mobile applications?

• Fragmentation in both devices (+400 and +20 new devices every month) and operator level (+140). Devices have proprietary operating systems, APIs, ?
• Optimization challenges: Take into account JAR size limitation, available heap space, processor, screen (resolution size), ?

Portability guidelines for application re-use over different mobile devices:

• Applications need to be designed with portability and localization in mind.
• Porting is most efficient when it is a ?no-compile? process; just start from a master copy and then port (also known as ?developer-disconnected? model)
• Most effective when done by dedicated porting team
• Following the eight portability guidelines

Eight portability guidelines:

• Application can dynamically adapt to different screen sizes
• Don?t hardcode sound data
• Provision for incoming calls/messages and pressing ?end? button. Just foresee it in case of?
• Maintain separate data files. Easier to adapt when moving to slower/faster devices
• Preserve localization issues upfront.
• Carefully consider device specific API before using them.
• Recognize size/memory constraints of handsets
• Pay attention to the operator?s requirements.

How to optimize mobile applications?

• Four key factors: Performance, JAR size limitation, Heap memory size, screen size
• Normally, you have to trade one off for the other.
• Does not mean ?lowest common denominator? implementation. Take advantage of the features provided by the device, don?t use only the features all devices have in common.
• Delay optimization till the last minute.

Performance optimization:

• Keep it simple!
• Use only 1 application thread. When using too many threads, the device grinds to a halt
• Minimize use of ?synchronized? as much as possible. Appears to be very slow and buggy on a lot of devices.
• Avoid using the Timer class, an extra thread is created
• Create background thread in startApp
• Network thread is the exception cause the network sometimes blocks. It?s handy to have a separate thread to avoid device lock-up.
• Handle system callbacks. Paint, keyPressed, ? and return asap to avoid slowing down the VM.
• ?Do not assume? when porting applications from one device to another. Performance may different than expected.
• I/O: I/O calls are very expensive; read/write operations should be buffered. Streams are extremely slow (sometimes 20 bytes/second)
• API: Some APIs are considerable slower than others.
• Avoid unnecessary object creation and/or memory creation

— The End, Thanks for reading! —

My overall impression about J1? Well, as I already stated in my day 1 summary: It was all about ?SOA? and ?lightweight?. SUN was really hard pushing the whole SOA story. Somehow, I can understand this cause other vendors are doing this as well. But what makes SUN really different to me is that they are currently missing the products (or they are not mature at all) to fill in a real SOA implementation. I?ll speak for my own company, but we at BEA have our AquaLogic product range that provides mature building blocks for concrete SOA development; the tools are there! Maybe it will change when SeeBeyond is a full SUN family member after the acquisition phase.
I followed a lot of SOA related sessions, but it was still vague or very limited. I missed the broader picture and some real world examples.
Netbeans? same story. They managed it to get Netbeans in every keynote of the general sessions, while the whole J1 crowd was thinking and dreaming of Eclipse with some cozy plug-ins.
Besides these litte side notes was the conference quite interesting.

k