Chaotic Java

Lukas pointed me to the NetBeans Graph Library used by Mobility Pack to create the flow charts between mobile forms, splash screens, etc (and in my humble opinion, will be used later to design flow charts for JSP pages, like in Java Creator Studio).

They also have a Web Start application there for you to test. The snapshot is from there. It actually got me thinking of reopening the dusted code of GenCore, my genetic algorithms framework of years past. One of the worst parts about it was the complexity of creating genetic processing circuits. To that end I was planning to write a front-end graph client, but just hated to start writing it all from scratch. You could say I was lazy, and even searching for existing frameworks didn’t quite get good results.

Risking by sounding even more like a marketing guy for NetBeans, this Graph Library brings some added value to the NetBeans rich client platform that actually makes me take a second look at it (I usually don’t like RCPs. Dunno why.)

Too bad there aren’t many tutorials on the subject, though (at least not on the graph’s site; I didn’t look around yet)..

I’ve recently asked out loud why the Mobility Pack is not available for Mac OS X downloads. Java being “Write Once, Run Everywhere” and NetBeans is carrying the flag of “using only standard Java packages”, that fact seemed weird to me.

Lukas answered the post by saying that in order for NetBeans’ Mobility Pack be available on the Mac, it needs to become a more interesting platform for J2ME development. In other words, there aren’t enough J2ME developers working on the Mac platform. In addition, he said that companies providing emulators usually do so for Windows and Linux, but not for the Mac.

He is correct, though. Currently, the only Mac emulator I know of is MPowerPlayer, provided for free for developers. It seems good enough – And I know it’s a shame people can’t play with Mobility as I know that just by showing Mobility Pack to a few friends (dotNet developers, no less!) they downloaded NetBeans at home and started playing with it. I can’t imagine them giving the same reaction if I showed them how I hand-code a MIDP application.

Lukas also provided a link to the “no Mobility Pack for Mac bug” in the NetBeans bug list, and told me to vote for it. Now, I implore you, the Mac developer: Vote for this bug. Even if you don’t work with J2ME today, you might want to do that in the future – And just like we, new-age programmers, don’t hand-code (or at least, don’t want to hand-code) Swing Forms, J2EE Deployment XMLs and even Ant scripts, we don’t want to hand-code J2ME forms.

So, vote for Mobility Pack on the Mac!

There you go.

I was asked recently whether I am still objective about the whole IDE market with all these NetBeans articles. I think that it’s safe to say that I am still objective; no-one at Sun are paying me anything to make it any different, nor do JetBrains of Eclipse.

It’s just that in the last month, I’ve come to gradually see the major difference the NetBeans team have made in the new NetBeans. Matisse, Mobility, Profiler, the new Editor (which still doesn’t conquer all fields but is certainly on its way) – They all show good work and good thought for user experience, something that was lacking in NetBeans and is lacking in many IDEs today.

The future will tell if NetBeans 6.0 would provide the promised refactoring and inspectors, and if NetBeans.next brings the promised J2EE integration to the same level as Mobility brings the J2ME integration. These guys aren’t out of the race yet; they just caught up the distance, even gained a few meters ahead, and made the whole thing more interesting now.