Skip to main content

James Says

Posted by editor on October 25, 2007 at 7:34 AM PDT


Repeat after Gosling: ME is not going away!

OK, back on Monday, we featured the CNet story speculating about the possibly of SE eventually becoming the platform of choice for mobile devices. It didn't help that CNet went with the provocative title Sun starts bidding adieu to mobile-specific Java? I talked about the article in Monday's editor's blog, talking about both the potential for such a development and wondering if it was really that practical or valuable: "Simplicity is one thing, but given that SE will surely use up a lot more of the device's memory and CPU, it is fair to ask what developers will get from SE on the device that they can't achieve with ME." In other words, SE has more stuff, but how much of it is relevant in a mobile/embedded context, and how valuable is it?

A lot of people apparently didn't take the grain of salt and assumed CNet was right in its apparent assertion that Sun seemed content to set aside the lynchpin of a billion dollar industry. So that makes today Correction Day.

To get the story straight from the creator's mouth, check out James Gosling's latest blog: JavaME is *not* dead! He continues:

It's growing up. Sheesh. Some folks are far too eager to misinterpret statements and put words in my mouth. The early versions of JavaME were very simple and limited, a direct reflection of the fact that early phones themselves were simple and limited: we had to work with what we had. But as time has passed, and cell phones have become more powerful and capable, JavaME has grown up too. Cell phones are becoming the new desktop. We've been saying this for years. Over time, it's pretty clear that Java ME and Java SE will converge and become largely indistinguishable.

That last sentence is a pretty interesting prediction, but not that implausible. Consider a definition that Kim Topley makes in J2ME in a Nutshell: "J2ME VMs are usually defined in terms of those parts of the Java Virtual Machine Specification and the Java Language Specification that they are not obliged to implement." So, whereas today Java ME is "Java SE minus float, double, runtime class-loading, etc.", maybe the improvement of devices allows for an ME that is "Java SE minus nothing". It still be valuable to have a specific mobile edition, to support user interaction models that make more sense on portable devices than the AWT's assumption of a keyboard and mouse, or to support APIs that are largely meant for mobile use (Bluetooth, for example), but still, Gosling is offering a way to think of the likely evolution of the platform that's more useful than the journo-skewed "Sun to ditch ME" meme.


The "ME is not going away" point is backed up by several items in the Java Today section.
The official Sun breaking news blog, On The Record, tries to ratchet down the SE-to-replace-ME chatter in a clarification titled Java ME - Oh the Drama! "It seems that some of the discussions around convergence & what will happen in the future caused people to think Sun is (insert your favorite descriptor here - bidding adieu, killing off, abandoning, waving goodbye) Java ME. Not happening! Java ME and Java SE are not mutually exclusive - they are complementary platforms - as James Gosling posts on his blog."

And an InternetNews.com article covers Sun's clarifications that there's Plenty of Life Left In Java ME.
"In a recent update to its Java roadmap, Sun Microsystems pretty much omitted any discussion about Java Micro Edition (ME), which would seem to be a bad sign for the embedded language. However, the company insists there is plenty of life in technology and it won't be abandoned any time soon. James Gosling today updated his blog to state rather unequivocally that Java ME is not going anywhere."

Meanwhile, in a forward-looking bit of SE news,
John Rose has a posted a JSR-292 Meeting Summary, compiling notes from last week's "kickoff" meeting of the expert group considering designs for an invokedynamic VM instruction. "To make the current Proof of Concept design public, we need to pass the "red face test". That is, the design shows a direction that we as an EG think is worth explaining and improving. Since this is not a voting milestone, the EDR [Early Draft Review] spec. can be incomplete and have unresolved issues." The notes also suggest that JSR-292 may changes beyond adding invokedynamic, and will likely launch an OpenJDK open source sub-project to develop the Reference Implementation.


Returning to today's Weblogs, Carla Mott has a lesson on
Connecting widgets in jMaki.
"Just how do I connect widgets to each other in jMaki? This blogs talks about peer to peer and anonymous connections and how you can use that in your code."

And Sean Sheedy is making
A Call for "Open Enrollment" for MSA (Mobile Service Architecture) Advanced.
"MSA Advanced has no Individual Experts on its Expert Group, and here are a few reasons why it can."


In today's Forums,
remisb wants to know
How to access EJB bean from war application deployed as separate modules.
"I have developed an ejb session bean and deployed it in separate ejb.jar. I also have a web application which uses ejb session bean through Remote interface. When I'm deploying it as ear everything works without any problem. Question is. How can I access ejb bean from war application without deploying ejb.jar and web.war together in one ear. I would like to have 3-5 separate ejb.jar and 2 .war applications with access to ejb session beans from those separate ejb.jar's."

JDIC user alexrob wants to know if there's a way to get a
List of file associations?
"I've just discovered JDIC and I want to use it to obtain Windows' file associations. The API has a method (AssociationService.getFileExtensionAssociation) for getting a single file association but there seems to be no means of getting the system's entire list of file associations. Rather limiting I think. Also a pity this hasn't found its way into Java 6."

Finally, mrmorris takes issue with the arguments against having a getDepth() method for tree tables, in
Re: Purpose of TreeTableNode.getColumnCount(...) ?
"I'm but a mortal user, but considering how commonplace master-detail views are (have a look at the NetBeans API), I find it ironic that a getDepth at the node level is *too specific* while getValueAt (which forces you to deal with column indexing semantics right there in your application model) apparently isn't."


Current and upcoming Java
Events
:

Registered users can submit event listings for the href="http://www.java.net/events">java.net Events Page using our href="http://today.java.net/cs/user/create/e">events submission form.
All submissions go through an editorial review before being posted to the
site.


Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of java.net it will be
archived along with other past issues in the href="http://today.java.net/today/archive/">java.net Archive.

Repeat after Gosling: ME is not going away!