Skip to main content

Eminence Front

Posted by editor on July 7, 2006 at 6:00 AM PDT

Why not rule the server and the client?

OK, tying together some threads from this week...

On Tuesday, Daniel Steinberg guest-blogged in this space and in a brief aside, he wondered aloud why Java DB was tossed into the JDK and not, say, Jini or JXTA. On Wednesday and Thursday, I suggested an implementation of JSR-80, the USB API, be added to the core, arguing this would improve device support in Java by reducing the need for JNI code to be written for multiple platforms to support these devices. And if you listen to the Java Posse podcast long enough, you'll surely hear Dick Wall talking about the struggles of working with multimedia in Java SE.

So what does this grab-bag of proposed feature adds have to do with one another? Simple: these are all things that desktop applications are far better suited to than are web apps. Ajax may be the everybody's favorite toy right now, but that doesn't mean it's well-suited to every kind of user-facing application. Here are a few tasks that Ajax probably isn't meant to do:

  • Working with external devices
  • Audio/video editing and production
  • Shared-document editors (like SubEthaEdit)

So, how would you write such apps? Well, let's see... with a USB API, we can write a desktop app to use our external devices. With a multimedia API, we could put together A/V apps like podcast editors, and Jini and JXTA can connect the users of our shared-document app, either on the LAN or across the internet.

Daniel asked for a vision on Tuesday. Here's one that desktop Java could adopt: focus desktop Java on technologies and applications for which webapps and Ajax are poorly-suited. In other words, identify these areas in which desktop Java can make a difference in a unique and valuable way, and then do what's necessary to support it.

It's understandable that so many people, inside and outside of Sun, are so focused on enterprise Java because of its consistent success. Challenged by both .NET on the bloat side and the scripting languages on the lightweight side, it might be tempting to adopt a siege mindset and focus just on protecting EE, to the exclusion of desktop Java, but that's probably a mistake. Enterprise Java is not well served by having a neglected, underpowered desktop cousin. A stronger desktop presence would raise Java's esteem among the next generation of programmers, and would be a valuable recruitment tool: hobbyist kids are more likely to code games and media managers than enterprise messaging systems and financial applications.

Would Microsoft even be relevant in servers if they didn't already own the desktop? Well, maybe Java should run the table in the opposite direction: build on its server-side success and move back to the desktop. Maybe by focusing on the apps that need to be on the desktop, and giving desktop developers the tools they need to deliver uniquely-valuable apps, we can do just that.

Speaking of Jini, the starter kit has a new home on
The starterkit project hosts downloads of Sun's implementation of the Jini technology infrastructure services, including helper classes and services such as JavaSpaces. The starter kit will help get you started developing with Jini technology, as well as assist your advanced development and deployment of Jini technology-enabled solutions.

Also in Java Today,
JBoss' Manik Surtani tears down popular misconceptions in The Myth of Transparent Clustering, which argues that rather than expect clustering to be enabled and tuned behind the scenes, application developers should instead plan for and develop with clustering in mind. "Keep clustering in mind when designing it, even if there is no immediate requirement for clustering. It will save you the headache, cost and effort of refactoring your code at a later date when you find that your application does not scale as well as you thought it would."

Planning on applying for a Java job soon? Java Developer Journal enterprise editor Yakov Fain has collected common questions you're likely to face in Secrets Of The Masters: Core Java Interview Questions: "If you are planning to hit the job market, you may need to refresh some of the Java basic terms and techniques to prepare yourself for a technical interview. Let me offer you some of the core Java questions that you might expect during the interviews."

Jonathan Bruce takes on what he calls the Ridiculousness of JavaOne reviews ratings in today's Weblogs. "Has the JavaOne rating system been infiltrated with Katherine Harris-like vote counting procedures?"

The Grizzly Comet or why space shuttle Discovery launch was delayed, Jean-Francois Arcand writes:
"Space shuttle Discovery was delayed recently, and the real reason was kept secret. Something strange was observed by the Hubble Space Telescope. The Hubble Ultra Deep Field(HUDF) image was showing a new star coming extremely fast to earth. Even after washing the main mirror with AJAX, the HUDF was clear: the Grizzly Comet is entering our atmosphere..."

Eamonn McManus blogs about
Creating type-safe MBean proxies:
"MBean proxies allow you to access an MBean through a Java interface, writing proxy.getFoo() instead of mbeanServer.getAttribute(name, "Foo"). But when you create a proxy, there is no check that the MBean actually matches the interface you specify, or even that the MBean exists. Why is that, and what can you do about it?"

The latest Poll asks "What new feature do you most want to see in Dolphin (Java SE 7)?" Cast your vote on the front page, then visit the results page for results and discussion.

In today's Forums,
toreba continues working a Fast Infoset problem in
Re: how can i generate and use a FI external vocabulary:
"I put together the snippets of code and was able to print out an external vocabulary. Is there going to be a way of persisting an external vocabulary to a file and using that to initialise a parser for either deserializing/serializing? Because i want to save the fi XML to a database i would need to persist the external vocabulary as well. Or would that be too risky? Perhaps it doesn't make sense to use an external vocabulary in this case? The improved compression is what i am after.

robilad asserts that the
JavaDoc license is bogus:
"Since Peter Ahe sent me to the Mustang collaboration site to get a peek at the Java Compiler API's spec under a saner license than the JSR draft one, I've looked at the licensing conditions for the API specs. It turns out that they have the same problem as the JSR draft license: anyone using the Mustang JavaDoc needs to stop developing and distributing whatever they are doing as soon as the final spec ships. That's a rather unfortunate licensing restriction to put into a specification, if one may assume that Sun's interested in feedback from implementors and users.

In today's
News Headlines

Registered users can submit news items for the href=""> News Page using our
news submission
. All submissions go through an editorial review before being
posted to the site. You can also subscribe to the href=""> News RSS

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.

Why not rule the server and the client?