Posted by editor
on March 30, 2009 at 9:40 AM PDT
Editorial changes this week... also:
Java Today: JSR 317 (JPA 2.0) proposed final draft, Project Coin week 4, and JTHarness 4.2 milestone 1
Weblogs: SwingX pushes towards 1.0, JSF to Struts to SEAM to Spring, and calling a Metro web service from Clojure
Spotlight: SIPCommunicator in Google Summer of Code 2009
Forum Posts: Java Firefox extensions, GlassFish startup actions, LWUIT demo, and Xerces and Metro
Editorial changes this week
So, a meta item to start the week: I'm stepping down as java.net editor, and my last day will be tomorrow, March 31. As of Wednesday, the front page will come to you courtesy of O'Reilly editor Kevin Farnham, who filled in for a few days last year while I was moving. He's also a veteran of several other O'Reilly community sites, and definitely knows what he's doing. I don't think he plans to continue the musically-themed blog titles, but we did have a long IM session over the weekend about Roxy Music and David Bowie, and how to get to Rasputin Records while in San Francisco for JavaOne, so I can recommend him to you both as an editor and someone to talk about music with.
As I plan to reserve tomorrow's blogs for thank-yous and shout-outs, I've got one opportunity left to get an opinion out. Actually, the degree of opinion in the editor's blog is something I've always been very sensitive to. As prominent as the editor's blog is -- even though its purpose in life is largely as an RSS feed of the front page -- I've always been wary to put too strong an opinion in here, for fear I'll pre-empt or silence someone with a less-prominent voice, but just as valid an opinion. With most things, I try to act more like an emcee, deejay, or host: I'll link to news or blogs, see if there's a counter-opinion in the follow-ups, and then throw it out to you folks with a "and what do you think" kind of conclusion.
Yet, on the other hand, an editor can't completely retreat from the issues and claim absolute "objectivity" and "fairness". For one thing, that would be boring to read. Moreover, it's impossible: my own interests, perceptions, history, and biases inform the kinds of things I pick for the front page. Even if I consciously work outside of my comfort area, it's harder for me to find and evaluate topics that I'm not interested or experienced in (say, security, messaging-oriented middleware, licensing, etc.), than in those that are high on my to-do list (for me, that's media, devices, GUIs, etc.).
Still, I've kept a lot under my hat, and will continue to. But with one more shot in this space, I want to get out one thing that's been lurking on my mind for years now. My biggest fear for Java's future is insularity. Not licensing skullduggery, not a corporate take-over, not technical issues. The one thing that I think the Java community needs to do better is to bring its solutions to the rest of the world, and to incorporate outside ideas into the Java world. When I see engineers spend three or four months working on demos for JavaOne, it raises a red flag: the only other people who will ever see this are those who are already so committed to Java that they'll afford the time and expense of being at JavaOne. Instead of solving the problems of the larger computing communities -- devices, Linux, networks, etc. -- we seem to have a tendency to please each other by developing stuff for use by other Java developers. How many Java webapp frameworks do we have now? Why are people creating new ones? Maybe because its too easy to talk to and please each other, than to risk going outside the Java Comfort Zone. Frankly, I wonder if it would do more good to de-emphasize JavaOne in favor of more Sun Tech Days and similar traveling conferences, which take the best of Java out on the road to where developers are, developers who might not even be full-time Java people, but can take an afternoon to see some presentations on cool new stuff.
By "insularity", I don't just mean Java, I mean "Java as it is today". As Kevin and I have worked to rebuild the feature article pipeline (I think we now have at least 10 articles approved and being worked on, which should freshen things up as those get published), we've updated our suggested topic list , with a focus on up-and-coming technologies, such as successful java.net projects like Hudson and Grizzly , and the various constituent parts of EE 6 and SE 7. Yet the pitches we get are often for older topics that are not only well-covered, but aren't even particularly fresh. I mean, Wicket ... really? Nearly four years after its last full-point release? If we all care so much about the future of Java, that future is right in front of us, in the form of up-and-coming projects, and finished or nearly-finished JSRs (many of which have reference implementations). This is the stuff we'll be using eventually... why not get into it now? Try it out, see if it solves your problems in new and useful ways. And if it doesn't work, file a bug!
Much of the innovation in the Java world right now involves incorporating ideas from other languages into the Java language, and bringing other languages to the JVM. There's a certain appeal to solving the closures argument by saying "so just drop into Scala or Groovy if you need closures so bad," but there's a sense that some of the most enthusiastic and adventurous people in the Java community, including a whole "Posse" I could name, find fleeing to Scala more appealing than doing stuff in Java. That's a worry. Is it that Scala's really that much of a solution, or is it just the "new hotness", a shiny reprieve from well-worn Java conventions?
But I'm not about to start digging a grave for Java. The pundits have been doing that since about 1997, and they've consistently been wrong (anyone remember ActiveX controls, or seen a web page that used one?). There's too much value here, too much proven results, and those are things that can't be tossed aside lightly. I do believe that the Java community will move forward and do important work.
With more and more device and format fragmentation, the very idea of device-independent executable code has never been more important or more valuable. In 1996, you could pooh-pooh Java by saying everything seemed to be switching to Windows; who needs "write once, run anywhere" in a world of "Windows everywhere"? Now in 2009, we have multiple viable desktop platforms, smartphone platforms, devices like Kindles and Blu-Ray players (both Java-based) with sophisticated computing needs, etc. There isn't a technology better suited than Java to work with all of those. Look past the habitual pursuits and see all the places that Java can take us.
Final farewells tomorrow. And the answer key for the editor's blog musical reference game.
In Java Today ,
The Aquarium notes the release of the proposed final draft of JSR 317 , in Type-Safe Criteria and MetaData API in JPA 2.0 - Expert Group Delivers Proposed Final Draft . "One more JavaEE 6 specification in Proposed Final Draft: Linda has announced the availability of JPA 2.0 PFD. This draft includes a number of significant changes, including the replacement of an earlier version of criteria API with a typesafe API, support for validation, and a metamodel API. As pointed by Linda, the changes to the criteria API and the new metamodel API came through a proposal from Gavin to the EG ; a great example of how the EG can pool the expertise from experts in the Java community, regardless of their company affiliation."
Ahead of today's deadline for submissions, Joe Darcy has published a week 4 update for Project Coin , the small language changes for Java 7 project. Joe lists the week's 19 (!) new proposals, and adds, "The field of over two dozen proposals previously sent in over the first three weeks of Project Coin was narrowed to six proposals still in consideration for inclusion in JDK 7. The proposals submitted this week and until the end of the call for proposals period will be similarly evaluated for their appropriateness to be added to the language."
The JT Harness project has announced their 4.2 milestone 1 release . " Version 4.2 fixes bugs, adds service management capability, and modifies the Quick Start Wizard. The service management feature provides the ability to map services to tests, manage the ports associated with services, and start and stop services manually and automatically. The Service Manager component allows users to interact with service in a particular test suite. Also, test suite architects now have the option of omitting the Quick Start Wizard."
In today's Weblogs , Karl Schaefer previews the future of SwingX in
SwingX Pushing Onward . "SwingX pushes toward 1.0, preparing the final(?) pre-1.0 release and a new demo application."
Dominic Da Silva's work has taken him
From JSF to Struts to SEAM to Spring . "Java web frameworks have definitely evolved in the last few years and Seam definitely makes working with JSF a joy this time."
Next, in Calling a Metro Web Service from Clojure , Harold Carr writes, "I show how to use the JVM-based Clojure language to call a Metro-based web service."
This week's Spotlight is on the SIP Communicator project, which has once again been accepted as a mentoring organization for the Google Summer of Code program as a part of its 2009 edition. If you're a student and you want to write open source this summer (and get paid to do so) pick up one of the SIP Communicator summer of code projects . The deadline for applications is April 3.
In today's Forums ,
provides a helpful answer in the thread
Re: Glassfish equivalent of weblogic startup class
. "You can create a ServletContextListener which will get called when your context starts. That's in the web tier, in EJB 3.0 which is bundled in Glassfish 2.1 there's no such equivalent so one technique is to call your EJB(s) that need to run on startup from the ServletContextListener. You will also need to make sure to add EJB refs to your web.xml. The Glassfish EJB FAQ here might be useful to you as well."
It's been quiet lately...
"Maybe a demo will liven things up? See LWUIT in rare form, visit: http://smooth.pro/info.php?game=WOA
using a JSR-184 device w/ at least 1.5MB of heap. Comments & criticisms are certainly welcome and appreciated!"
Finally, Clive Brettingham-Moore shows how to handle a Xerces class-loading difficulty in
Re: Xerces not playing nice with Glassfish / Metro? "If your application (or library) uses Xerces directly (rather than relying of xerces specific features via JAXP, which is bad form) then you can prevent Xerces interfering with JAXP simply by removing the service configuration from the Xerces jar (expand jar remove META-INF/services/javax.xml.parsers.DocumentBuilderFactory & META-INF/services/javax.xml.parsers.SAXParserFactory, re-jar and use this version). Similar applies if Xalan is the problem (META-INF/services/java.xml.transform.TransformerFactory). JAXP will see the default implementation, and the other code can still use Xalan/Xerces directly."
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
Editorial changes this week