Skip to main content

Do What You Have To Do

Posted by editor on May 21, 2007 at 4:26 AM PDT

A detailed road-map for consumer-side Java

So did you ever think you'd see something so frank from Sun?

The reality is, we have several outstanding issues with Java as a consumer desktop platform, which need to be fixed soon in order to make us competitive now and in the future.

If you did, did you think it would come with a compreshensive response like this:

The good news is that we are, in fact, aware of these issues. The better news is that we're working on the problems. The best news is that we are close to solutions and intend to delilver them as an update to the SE 6 release, in a release that we call the Consumer JRE.

We're starting off today's Weblogs section by highlighting Chet Haase's remarkably thorough desktop/client/consumer-side road-map, Consumer JRE: Leaner, Meaner Java, which covers a number of different technologies to launch in this SE 6 update: faster launching for applets and applications, the "Java Kernel" to optimize downloading just the parts of JRE to get an application up and running, a deployment toolkit to detect and install the JRE, a better cross-platform look-and-feel, and improved installation, Windows graphics.

It's highly encouraging to see these issues being addressed, and with a comprehensive approach. There's a lot to cover, and Chet's blog has already kicked off a long conversation in the comments.

I also find myself drawn to the term "consumer" in the sense of these user-facing SE technologies. "Desktop" Java never seemed right to me, since SE might be running on set-top boxes or high-end phones, and "client" Java implies a server that isn't necessarily there (not every task needs to be networked; in fact, I don't want to collaborate when I'm working my finances). We'll see if this term gains traction, or if it gets people to think differently about the role and possibilities of Java SE.

Also in today's Weblogs, Max Poon
has a recap of

JavaOne2007 Hands-On Lab 1420:
"My colleagues Paul Cheung, Luis-Miguel Alventosa and myself together developed, and presented for, this year's JavaOne Hands-On Lab1420 on 'Non-instrusive Monitoring and Troubleshooting of Java Applications using Java Management Extension (JMX), JConsole and Aspect-Oriented Programming (AOP)'."

Finally, Kirill Grouchnikov reports on
BugParade, Iconistan and the proverbial lipstick on a pig: "It's not a big secret that a lot of people hate BugParade. It was great 10 years ago, but it's still stuck there, with complete lack of transparency, arcane voting and comment system and quite a few other problems."

In Java Today,
the jxta-overlay project is an effort to use JXTA technology for building an overlay on top of JXTA offering a set of basic primitives (functionalities) that are most commonly needed in jxta-based applications. This set of basic functionalities is intended to be as complete as possible regarding the needs of jxta-based applications. The overlay is built on top of JXTA layer and provides a set of primitives that can be used later by other applications, which on their hand, will be built on top of the overlay.

In Java Mobility Podcast #4, you can catch Roger Brinkley's and Terrence Barr's interview with Vringo, an independent software vendor (ISV) who launched a video-sharing community that enables you to share video ringtones (or "Vringos") with your buddies.

Cologne JUG leader Michael Hutterman points out the recently updated JUG Events Overview wiki page, allowing you to add your JUG event or look for events nearby. He also points out that you can submit your JUG event to the main events listing via an online form.

This week's Spotlight is on the Shoal project, a Java based clustering framework that provides infrastructure to build fault tolerance, reliability and availability. The framework can be plugged into any product needing clustering and related distributed systems capabilities without tightly binding to a specific communications infrastructure.
For a quick introduction, you can go through the Shoal Overview Presentation (PDF). and for further details, read the Shoal Overview document for details on Shoal's functionalities.

In today's Forums,
alnrelly is looking to pick up graphics optimizations in
Making a BufferedImage managed:
"I am having problems getting the performance I want when drawing images. I load a BufferedImage using ImageIO then draw it to a JPanel using the Graphics2D.draw(Image, AffineTransform, ImageObserver) method. The first time I draw this image it is much slower than subsequent calls. I think that the BufferedImage becomes 'Managed' through the creation of a CachingSurfaceManager that creates an accelerated SurfaceData object (I have be looking at the Java source). I want my calls to drawImage to be as fast as possible (I am scrolling an area with many images drawn on it in various places). So much so that if I have not got an accelerated BufferedImage already then I will skip drawing it and return to it later. I currently load the image from file in a separate Thread and it is here that I want to explicitly make the BufferedImage 'Managed'."

swpalmer has a hopeful answer for the original question in the thread
Re: Is the Synth L&F dead?
"I've just been looking at the Nimbus project. It looks good, but I see that they come right out and mention that they will likely need to patch Synth and are targeting Java 7. The good news is that they also mention back-porting the changes to Java 6. So there is hope! Perhaps a few updates from now Java 6 will have a fully-functional Synth LnF. So my question is answered. Synth is alive and will be fixed. Awesome."

i30817 thinks through the issue of arbitrary resolutions for icons in
Re: Multi-resolution or resolution independent Icon class:
"I would guess that it would be smarter to provide a multi resolution icon. What happens in a hypothetical OS that requests another icon size? This i think is one of the problem points in the native-to-java land. Java is just implementing and using the interfaces of the OS, and that is propagated into the API (where it suppostly is set in stone, not that i agree with that, refactor swing ftw). When the sane way to fix this would be to provide a api that takes and independent largish image or svg and scale it to whatever the OS ask, and if it indeed asks for SVG use that. Not that i think sgv is a standard "now". Adapt the general api to the OS don't propagate it to us."

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.

A detailed road-map for consumer-side Java