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
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."
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."
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
- OctoberÂ 21-25 - ooPSLA 2007
- OctoberÂ 21-26 - Colorado Software Summit 2007
- OctoberÂ 22-24 - Sun Tech Day - Shanghai
- OctoberÂ 24-26 - The Ajax Experience
- OctoberÂ 26-27 - IndicThreads.com Conference On Java Technology
- OctoberÂ 26-28 - Lone Star Software Symposium 2007: Dallas Edition
- OctoberÂ 29-31 - Sun Tech Day - Beijing
- NovemberÂ 2-4 - Northern Virginia Software Symposium 2007: Fall Edition
- NovemberÂ 6-8 - Sun Tech Day - Tokyo
- NovemberÂ 9-11 - Rocky Mountain Software Symposium 2007: Fall Edition
- NovemberÂ 16-18 - Great Lakes Software Symposium 2007
- NovemberÂ 19 - Triangle Java User's Group: Better Search with Apache Lucene and Solr
- NovemberÂ 19-23 - J2EE Training Philippines
- NovemberÂ 20 - Enterprise Comet Presentation by Jonas Jacobi and John Fallows at Google
- NovemberÂ 26-27 - JAX ASIA 2007
- DecemberÂ 5-7 - Sun Tech Day - Frankfurt
- DecemberÂ 10-14 - JavaPolis 2007
- DecemberÂ 12-15 - The Spring Experience 2007
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
Archives and Subscriptions: This blog is delivered weekdays as
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!