Skip to main content

It's a long way back to Boston

Posted by bsandersen on June 30, 2005 at 5:58 PM PDT

It is the last day and I make the long trek home in the morning. I had a great time and learned a lot at this year's JavaONE. This will be my last blog from the city by the bay and I hope all you have enjoyed the show and my comments on it. Below are my parting shots for JavaONE 2005. Thanks for listening!

-- Scott

JavaONE's tradition of putting James Gosling center stage on the last day, showing off cool toys and firing tee shirts into the audience, has been preserved for another year. The last general session wrapped up by bringing some heavyweights together for a roundtable talk on Java's past and future. John Gage, James Gosling, Bill Joy, Guy Steel, and others talked about the early days of Java, the impact of Google, and more.

In my first blog "It's a long way to San Francisco" I said I wasn't a Java futurist. Well, maybe I lied just a little. Perhaps what I should have said is I'm no more of a futurist than most other people. I certainly have ideas about where we might be going. I'll play off what I saw this morning to give a couple of those ideas here.

John Gage illustrated how executing Java programs can be treated as objects which can be picked up and moved to other machines. He started a program on one machine, selected it, and did a drag-and-drop to another machine where it then began executing without missing a beat. The completely OO nature of Java and its accompanying virtual machine makes such feats possible. To further make the point, a demonstration was then made of the same execution migration technology running on small embedded Java sensors. The sensors had accelerometers in them so when one sensor was shaken, the executable was "shaken out" of the one sensor and "landed in" the other. Fanciful, sure, but it made the point.

This demonstration was moving a running executable image from one VM to another with some special services used to orchestrate the hand-off. Short of that, we in the Java world have something nearly as powerful: moving code that comes free with every Java SE platform. If you've written an applet and loaded it into a browser, you've written mobile code. Let's see what we could do with mobile Java code.

I'm in the market for a new television (really, my Proscan died this spring). When the new TV arrives, I want to take the universal remote and have it learn about all of the AV equipment I have. I shouldn't have to go through some weird button sequence on the remote; it should figure it out on its own through some discovery mechanism. Imagine now each and every device had a Java VM. They already have a common transport: the infrared link. I want to push the learn button and have the remote discover and negotiate with all of the devices in the room. It could then map all the appropriate buttons to appropriate actions.

Then again, why do I need buttons?! Put a touch screen LCD on the thing and allow a simple thumb-wheel to scroll through the available devices. Here's the important part: the devices themselves provide the code that presents the GUI on the remote. Read that part again. The code for the UI comes from the, say, CD player, but is run on the remote control unit. This part isn't science fiction, an analog exists. Check out the ServiceUI project.

Let's walk through how this works: the remote sends out a discovery is anybody out there message over the infrared port. It then selects one of those devices to work with first. The remote asks for the code for this device's human interface. But wait--there's more! The negotiation could include some criteria such as language (English, French, Italian) and locale (French? Oui! Montreal or Paris?) It might also include information about the constraints for the requesting device. The remote that sits by the easy chair has a pretty small LCD screen. But, the LCD screen on my laptop is pretty big. Oh, by the way, why can't these Java applications just run on my laptop, too?

How about configuring something you take with you? I love my iPod for its simplicity and I'm not the only one. Her Royal Highness Queen Elizabeth II opted for the Apple iPod instead of a similarly capable Sony product. According to sources, the Queen told a Sony representative, "I have a lot of trouble with your remote controls. Too many arrows." Too many arrows indeed!

Right now I have to configure my iPod with music, playlist, and other data by hooking it to a computer loaded with special software (iTunes). At this morning's keynote, a demonstration was done where a fellow created an iTunes look-a-like in just a couple of minutes in Java. Now, imagine this: the iPod has its own iTunes-like program inside it. When I hook it up to any Java-capable computer I can move that code out of the iPod and run it automatically. This application would then allow me to rearrange my playlists, or view the calendar, appointments, todo lists, or address book stored in the attached iPod. We've got plenty of space! Use some for bytecodes!

Programming the radio and other accessories in your car is a hassle. Imagine you could have a device (perhaps your cell phone with a Bluetooth link) that would negotiate with your car. When you get in the car it recognizes you and makes the appropriate adjustments: seat, radio stations programmed into memory, etc. Sure, there are systems that work this way already--after they are somehow configured. But how are they set up initially? To program the radio you sit in the car and try to use some hopeless UI presented by the little buttons on the radio itself. That's insane!

Let's walk through how this might be made better: I get in the car and tell my cell phone to capture a package from the car. The cell phone then uses Bluetooth to capture a program and some data from the car. I walk into the house and set the cell phone next to my Java-capable computer. The phone provides the program to the computer (over Bluetooth) and I can now use a nice GUI to set up the radio stations, climate control preferences, GPS routes, and anything else the car needs to know to make me comfortable. That information is then stored on the cell phone as Java objects when I'm done.

The next time I get into the car, the cell phone negotiates with the car to give it all of my personal settings as Java objects. We don't need XML here if everybody is just talking Java, right? Leave everything as Java objects. Love Java! Love Java objects!

If Sandy takes the car instead, she takes her cell phone and gets her personal settings. Doesn't that make more sense than sitting in the car with the manual open poking frequencies into the radio for an hour? Of course it does! And, this is technology that is available right now.

Start chanting this over and over: I need to move more code. I need to move more code!

Let's get some of the excuses out of the way. Don't have Java running on some small device? That's OK. The device can still hold the bytecodes for its interface that could be managed through some surrogate. The surrogate architecture provides a solid foundation for this approach. Keith Thompson did a great job on this and, while it is under the Jini banner, it is a technology that could have a very, very broad applicability.

Here's the next excuse: Java might not be where I need it. We have something to point to on this issue: cell phones. At this point, not having Java in the cell phone is recognized as a product deficiency. We need to all start pushing the benefits of mobile code, showing how discovery and integration with the rest of the Java-based-world infrastructure is an important feature. Then, we push for the inexpensive, full-featured Java SE chip I mentioned the other day so this kind of capability can be buried into everything.

These are just a couple of thoughts. I've got more but I'm sure you've all had enough for now! Like I said, I'm no Java futurist. But, I'm pretty sure I met some while attending JavaONE. You had to listen carefully, but I believe the future was outlined by some very smart and very dedicated people who are just doing what comes naturally to them: creating. Take Bruce Boyes of Systronix, for example, who said in his session, "I'm just a typical guy who lies awake at night thinking about how you would program a thousand robots." Baby, that's a guy thinking about the future!

Related Topics >>