Posted by editor
on April 18, 2008 at 8:17 AM PDT
Do "big thought" blogs suggest what we'll see at JavaOne? Also:
Java Today: "Method Handle" design, "compatibility" defined, and jMaki events
java.net Poll: Do you participate in Sun's Java Bug Database (aka, "Java Bug Parade")?
Weblogs: Anti-social networking, loading data into jMaki widgets, and object-only programming
Forum Posts: ME logging, JAX-WS thread-safety, and preferring just one wsdl file
Do "big thought" blogs suggest what we'll see at JavaOne?
So, with JavaOne just a few weeks away, thoughts naturally turn to wondering what's going to be announced. Last year, nobody could have seen JavaFX coming, so maybe there will be another surprise. But more likely, many attendees are going to be keen on an update on Java 7.
It's obvious that the release date has slipped: a Danny Coward presentation (PDF), linked from a December 2006 blog , shows Java 7 coming out in mid-2008. Obviously not happening. Chris Maki posted a summary blog of Danny's Java SE road-map at JavaOne 2007, and wrote "Java SE 7 may be available just before 2009." Let's give that a qualified maybe... prior experience tells us that Java has a long beta cycle, so we'd presumably need to see a first beta announced at this year's JavaOne for an early 2009 release to be plausible. But this is all speculation.
Still, it's fun, so let's speculate further. Specifically, what's going into Java SE 7 that demands a new release? After all, the dramatic changes of Java SE 6 Update 10 -- the Java Kernel, Java Deployment Toolkit, Java Auto-Updater -- didn't require API changes, so these profound changes to the VM and Java end-user experience could be made as a point update to the existing release. So what big stuff, big enough to hold for a major release of the platform (or, put another way, big enough to make a major release worth doing), are on tap? Closures has long been the big one, and that debate seems far from settled.
We can also read the tea leaves of what some of the major thought leaders on the platform are posting. Two of these are featured on the front page of java.net today -- one on a design to support dynamic languages on the JVM, the other clarifying just what "compatibility" means in a Java context. On the one hand, you could look at these and say they're just talking about the big ideas, not announcing a JSR or anything more concrete, so for this stuff to make it into Java 7, that implies that Java 7 must be a long ways off. Maybe. On the other hand, you can see in these blogs that the authors have worked through the big ideas to their satisfaction, and are sharing the results for other to see. And that might indicate that big questions are getting resolved in this pre-JavaOne timeframe.
The first of these deep-thought blogs in the Java Today section is John Rose's Method Handles in a Nutshell , which proposes a design for "method handles" to better support dynamic languages. "One of the biggest puzzles for dynamic language implementors on the JVM, and therefore for the JSR 292 (invokedynamic) Expert Group, is how to represent bits of code as small but composible units of behavior. The JVM makes it easy to compose objects according to fixed APIs, but it is surprisingly hard to do this from the back end of a compiler, when (potentially) each call site is a little different from its neighbors, and none of them match some fixed API."
What does it mean for changes to be "backwards compatible" with previous versions of Java? Joe Darcy clarifies common misperceptions in the blog Kinds of Compatibility: Source, Binary, and Behavioral . "When evolving the JDK, compatibility concerns are taken very seriously. However, different standards are applied to evolving various aspects of the platform. From a certain point of view, it is true that any observable difference could potentially cause some unknown application to break. [...] Since not making any changes at all is clearly not viable for evolving the platform, changes need to be evaluated against and managed according to a variety of compatibility contracts."
The latest SDN Enterprise Tech Tips looks at Working with jMaki Events . Author Carla Mott writes, "the following tip expands the discussion of the event mechanism in jMaki. You'll learn more about the concepts that underlie the jMaki event mechanism and how to take advantage of it to easily interact with widgets. "
The latest java.net Poll asks "Do you participate in Sun's Java Bug Database (aka, "Java Bug Parade")?" Cast your vote on the front page, then visit the results page for current tallies and discussion.
In today's Weblogs , SimonÂ Morris wonders if Google App Engine isn't an example of
Anti-Social Networking .
"We all have light bulb moments from time to time, ideas for new software which scream "code me". Google's new App Engine promises to get your ideas up and running without the traditional hassle, leaving you to focus on your code... but are there consequences further down the line?"
CarlaÂ Mott offers some answers about
Loading data into jMaki widgets .
"I've gotten a few questions about how to get data into jMaki widgets. This blog describes the different ways in jMaki to load data into widgets."
Object Only Programming (and Modelling) Considered Silly , JohnÂ Reynolds writes, "every so often I come across a blog entry that makes my own attempts to put my thoughts in writing seem pathetically inadequate. Stevey's Blog Rant: Execution in the Kingdom of Nouns is one such entry."
In today's Forums ,
terrencebarr offers some logging options in
Re: Logging in Java ME .
"JSR 47 is the logging API but unfortunately it never got much traction in Java ME land. You're right that there are a few open source packages available but I have not yet tried them. Do you need to log during development? If yes, then with many devices System.out goes to the console on the PC or into a file on the device and you can use that. If you are looking for logging functionality once your app is deployed to users then your choices for persistent storage is RMS or PIM files. In both cases you'll need to implement caching and LRU policies to minimize the activity on the persistent store as some devices are very slow in accessing flash storage."
vinodsingh would prefer to
Generate one physical wsdl file for a web service .
"The JAX-RPC used to generate only one physical WSDL file for a web service but JAX-WS generates multiple files (wsdl and xsd) for one web service. Though segregating different types of the stuff in different files looks logical but if one needs to distribute the WSDL then it is quite inconvenient to handle them. Is there anyway to instruct JAX-WS to generate only one file?"
kzho wants to know about JAX-WS thread-safety in
Need authoritative answer on whether JAX-WS client objects are thread-safe .
"We need to know whether the service objects generated by wsimport (JAX-WS RI 2.0.1 and later versions), as well as the port objects returned by the getPort() methods of those service objects are thread-safe. The spec appears to be ambiguous on this and forum posts for other JAX-WS implementations appear to indicate that these objects are not thread-safe for some implementations (e.g. Axis 2, CXF). In our performance tests with JAX-WS RI 2.0.1 and 2.1.3, the overhead of the Service.getPort() method is very heavy with average response times of 400-1000 ms. In order to achieve acceptable performance, we would need to cache and share port objects across threads. In order to do this, we need to know whether these objects are thread-safe. If we cannot do this, we may be forced to look at using an alternative web service stack."
Current and upcoming Java
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
Do "big thought" blogs suggest what we'll see at JavaOne?