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 java.net.
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?"
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.
robiladasserts 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 java.net
News Headlines :
- ASM 2.2.3 and
- eSh Client
- curn 3.0
Registered users can submit news items for the
href="http://today.java.net/today/news/">java.net News Page using our
form. All submissions go through an editorial review before being
posted to the site. You can also subscribe to the href="http://today.java.net/pub/q/news_rss?x-ver=1.0">java.net News RSS
Current and upcoming Java
- July 7 - Experten Forum Stuttgart
- July 7-9 - Lone Star Software Symposium 2006: Austin Edition
- July 21-23 - Central Iowa Software Symposium 2006
- July 24-28 - O'Reilly Open Source Convention 2006
- July 28-30 - Desert Southwest Software Symposium 2006
- August 4-6 - Southern Ohio Software Symposium
- August 18-20 - New York Software Symposium 2006
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 href="http://today.java.net/today/archive/">java.net Archive.
Why not rule the server and the client?