It has always seemed a waste of resources to make the bodywork of cars different every year for no reason other than appearance. So it doesn't bother me that Java One was not re-themed this year but was again tagged with "Make the Future Java". Apparently the future is still not here, so we all need to keep working on it, at least for another year.
Again this year I was fortunate to speak, in collaboration with my long time collaborator in such things, Jim Wright, in BOF 7452 on the topic of SmartStat Micro, an open-source HVAC thermostat. This is an ongoing project and a topic for future posts.
This year things started with a Java.net community leads meeting and excellent dinner (Hotel Nikko food seems to me to be a cut above their neighbor hotels), MC-ed by Sonya Barry, who is currently battling cancer (read about that in her blog). This year events proper kicked off on Sunday. Today is Tuesday and here are some random impressions.
This is the first year that wireless has actually worked well! Kudos to the subcontractors who set it up. This has got to be hard: providing wireless to accomodate 60,000 people. Actually the JavaOne portion of that is a lot less: maybe 10,000 (just a guess), but still that is a lot of traffic.
Web Fundamentals by James Ward (at 8:30 this morning, groan) was fabulous. In a dense hour he laid out what hours of googling and reading books (online and print) has failed to give me. He works for TypeSafe and they have some nice looking web tools which I am now inspired to try. It's a 200 MB download... good thing the wireless works.
Sun SPOTs are dead. When current stock is gone no more will be made. This is the final chapter in a sad story. SPOTs could have been the Arduino for the Internet of Things. But at a commercial license fee of $100K, what can you expect? Suppose Arduino had a $10K license fee for commercial use? It would have flopped too. Now SPOTs are open source, but no one seems to care. There are better options out there: you guessed it, mostly based on Arduino. $400 gets me two wireless SPOTs and a base station, or for $75 I can get a pair of Arduino WiFi Spark Core devices.
You never have to go more than half a block in San Francisco to get a decent latte. And at JavaOne you can get as many as you want for free in the "Buzz Shack". Someone got this right!
There is emphasis this year about "embedded Java" - and here we mean some attempted rejuvenation of Java Micro Edition- and I attended several sessions related to this. Judging by attendance it may be too little, too late. Sun let Java Micro Edition languish for years, and seemed to care only about Java ME on phones. Now, what is the compelling use case? On the other hand, "embedded" these days can mean a $45 BeagleBone Black with orders of magnitude more power than an embedded device of yore. So Java SE Embedded is more apropos with current hardware. "SE Embedded is the new ME".
In past years Oracle was pushing SE Embedded on the Plug Computer which is pretty cool for around $100, but it is not hackable or embeddable. The only I/O interface is: USB. So forget about adding your own low-cost sensors, or controlling devices. No I2C or SPI, so you can't add your own OLED displays or color touchscreens
Oracle this year seems almost obsessed with the Raspberry Pi. Pi is cool - don't get me wrong - but it is for educational use only, and is not intended or appropriate for commercial use (a whole other topic, Google it if you are curious, or just try to get a data sheet for the Pi's Broadcom processor). Instead there are newer embedded Linux systems such as BeagleBone Black which are intended for OEM use, so I would expect Oracle to be all over the BBB. Maybe next year. In any case, if it will run on the Pi it should also run on the BBB. So if it can be made to run acceptably on Pi, it should run that much better on other more capable targets such as BBB. That's a wonderful side effect of both Pi and BBB running embedded Linux.
So *why* should we run Java on a small embedded Linux system? What is the compelling use case? At JavaOne there is sometimes the "we should do it in Java because Java is cool" mentality, sometimes with little consideration for whether it is practical or benefical. Ten years ago this held some weight. But now Java is the status quo and newer languages (e.g. Python) are claiming better ease of use and programmer efficiency.
For one thing, SE Embedded and Netbeans have some impressive debugging, monitoring, and tuning tools such as VisualVM and VisualGC which were featured in the presentation Deploy: Getting Up to Speed on Oracle Java SE Embedded, TUT7730. These are pretty impressive tools, if you care about what your application is really doing: how much memory is it consuming, where performance bottlenecks are occuring, and so on. Remote debugging is possible on the stable Java 7 SE Embedded, too, but only with the latest NetBeans 7.4 nightly builds.
Which brings me to the point that Oracle sometimes takes a long time to make a decision and actually do something, but if they ever reach that point, they tend to do it well, and they tend to stick with it. By "do it well" I mean including a pretty robust JVM and usable tools for debug, monitoring, and tuning. (Such tools are grossly lacking in the Arduino world). Sun would often change focus every year, driven by the current winds of marketing hype. This never played well with industrial developers who typically have to maintain and support systems for at least five years, and often at least 10. Embedded Java developers have been burned in the past so we are now more than a little shy about considering Java again. What if Oracle changes their mind in a year or two? Witness the dead end which Sun SPOTs have now become (in fairness that is not Oracle's fault, but you get my point).
This is one aspect of Arduino which helps make it popular: the whole Arduino IDE and its libraries are open source, and since the code is all standard C/C++ and the underlying compiler is GCC, how badly can you be stuck in the unlikely event the Arduino.cc developers abandon further work? If we only have access to the binary releases of the JVM for ARM, what do we do if Oracle abandons the effort?
More thoughts on this to come...
