Skip to main content


Posted by editor on February 21, 2008 at 8:42 AM PST

Prominent developers ponder Java's future

In general, I'm not a big fan of panels at conferences. I think they're frequently self-indulgent and self-congratulatory. In voting for OSCON '08 sessions, I voted against one with the following comment:

Sounds a little bit like a "hold hands, sing kumbaya" type panel. Do participants have more to say than "hi, I'm from , and I think open source is good."

Given that, I have to say I'm impressed with the participants and topics that QCon San Francisco pulled together for their panel discussion, What will the Future of Java Development Be? Consider the participants:

  • Joshua Bloch - Google's chief Java architect, Java Puzzlers co-author
  • Chet Haase - Swing team member, Filthy Rich Clients co-author, co-owner of timingframework, animation, and other projects
  • Rod Johnson - Creator of the Spring Framework, member of servlet and JDO expert groups
  • Erik Meijer - Creator of LINQ
  • Charles Nutter - Co-creator of JRuby

OK, with participants like that, you can't help but have a good discussion, especially given some of the topics covered:

  • Can we modify the Java platform to utilize a core library with pluggable modules?
  • Do we ever want to remove code from the Java APIs, or create a new modular platform within Java?
  • Do you think the Java platform is already too complex?
  • Shouldn't programmers be able to understand and utilize new language features? Aren't we supposed to be intelligent?
  • If you have to use a rich IDE or some other tool in order to be able to program in a language, isn't that a bad sign?

Having said all that, I have to admit I haven't taken 50-some minutes to watch this panel before getting the page up this morning. It's too bad this one isn't available in an audio-only form for listening on the go, but for now, the only option is a web-embedded video. Still, these are the questions a lot of us have been kicking around recently, and it should be well worth the time to hear what this particular group has to say on the topics.

Also in Java Today,
the Little Springs Design blog reports that customers still want their mobile apps developer in Java ME, in the blog Java ME is dead. Long live Java ME. Despite the growth of the mobile web, the blog says four the company's six first quarter projects use ME. "Why are they using Java ME? Because they need to store some of their application logic and/or data locally. Because the app or data needs to be available without the network. Because the application would be dreadfully slow as a web app. Because they are creating a push messaging client that needs more rich interaction than simple SMS (and better interoperability than MMS)."

While implicitly conceived for C/C++ developers, the Intel Software College article 8 Simple Rules for Designing Threaded Applications offers a sufficiently high-level view to be of use to many Java developers dealing with concurrency in the multi-core era. Author Clay Breshears writes, "multithreaded programming is still more art than science. This article gives 8 Simple Rules that you can add to your palette of threading design methods. By following these rules you will have more success in writing the best and most efficient threaded implementation of your applications. "

In today's Weblogs, Wolfram Rittmeyer explains
Virtual Servers on Glassfish.
"Glassfish v2 supports virtual servers pretty well. In this blog entry I will show how to set up virtual servers and how to map webapps to these using Glassfish's asadmin command line utility."

Eamonn McManus introduces
VisualVM - All-in-One Java Troubleshooting Tool.
"VisualVM is a new graphical troubleshooting tool that is being developed in a project on"

Finally, Michael Nascimento Santos offers suggestions for
Making your components work nicer inside Matisse.
"Have you developed the killer component for your application, but it takes too long to load inside Matisse? Or worse - you face class loading errors since it has too many weird dependencies? Well, here is a small tip to make it work faster and without much hassle..."

In today's Forums,
david_hall discusses the practical realities of table API design in
Re: generic table model for JXTable.
"The thing that I've found in using a generic table model is that we still ended up binding to the beans anyway. We have an application where each bean can be edited in two places (a table and a form) and that both can be on screen at once, depending on how the user chose to navigate. To keep the UI consistent, we had to register a property change listener with each bean in the list. We don't bind by individual properties -- when a property changes, we lookup the column and forward the event through the table's normal event channels."

kbr updates the open-source status of new deployment code in
Re: Java SE 6uN-b11 Linux 64-bit download?.
"Unfortunately the Java SE deployment workspace is not yet open source, although we are trying to figure out how to do this as quickly as possible without disrupting our development flow. Progress on this will be made soon as development begins to wind down on 6u10."

Finally, eppesuig asks
How to find icons for current Look and Feel style?
"I would like to show a menubar with common icons (open file, save file, save file as, ...) on the topmost part of my swing jframe. I adopted the system look and feel with this command: UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); but now I still have to change all my icons based on the current theme. Is there any way to find the current icon set (as included in the current theme)?"

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

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 it will be
archived along with other past issues in the href=""> Archive.

Prominent developers ponder Java's future