You Can't Always Get What You Want

Java Web Start article hits a nerve

I don't usually blog about the same thing two days in a row, but Joshua Marinacci's Java Sketchbook: Getting Started with Java Web Start article has generated a remarkable number of talkbacks in a single day (26 at last count). And aside from a small amount of flameage on a thread about security, most of it hits on substantial concerns people have with what Web Start does and what it could or should do.

I think deployment is a real pain point in Java SE development, perhaps even a bigger issue than the endlessly debated visual fidelity of AWT vs. Swing vs. SWT. It's hard to see how users are going to get bent out of shape over an application "just not looking right" when it's absurdly impractical to launch the app in the first place, or when that situation makes developers take their platform-independent Java code and place it in a single-platform application launcher.

Java Web Start is one answer to some of these problems (and Joshua's part two will go into further depth on JWS), but there are others. You can turn to double-clickable JARs, native bundlers, shell scripts / batch files and more, depending on your needs... and your needs may not be well served by any of these approaches. Indeed, few of those options address broader deployment issues, like versioning, updating, and document association (some of which are being addressed by efforts like JDIC).

I think you could write a book on Java deployment issues. Maybe if Joshy would take the hint -- :-) -- he will...

Java Web Start in Mustang is a topic in today's Forums. In
Webstart changes in Mustang,
prunge writes
"Webstart looks much more user friendly in Mustang when compared to 1.5. However I have some issues with it [...] The 'downloading application' screen looks better now. However, I do miss the number of Kb downloaded and the estimated time remaining messages. Especially on dial-up, users would like to see an approximation of how much time is left for downloading if it is going to take more than 10 seconds. It is also good to see the number of Kb downloaded and the total size of the app. It's probably right that users no longer have to see the names of the JARs being downloaded - end users don't care about this."

The "true" Checklists: XML Performance, kohsuke writes:
"While I knew that there are some documents named 'Patterns and Practices' from Microsoft, I didn't know that there is a section for XML Performance. Sadly, I was scarcely satisfied by that document. The checklist is so insufficient, and some of them are missing the points (and some are even worse for performance). So here I put the "true" checklists to save misinformed .NET XML developers."

In today's Weblogs,
Romain Guy says he could
Get to love web development:
"Last week I wrote an article about Wicket and I spent some time discovering and taming it. And I have to confess this: I love it."

Scott Andersen worries about
Breadth, not depth in computer science education:
"What in the world is going on?! Have we become so specialized even at the college level that we can't speak intelligently or have a reasonable intuition for things that border our comfort zone?"

David Walend has been playing around with
GraphViz Class Diagrams:
"Last week, Kohsuke Kawaguchi suggested that we could use GraphViz to generate class diagrams automatically. I built it out of parts on my workbench over a few evenings."

In Also in
Java Today:

"Pooling is great - except it's not very tunable, it's hard to map end users back to connections in the pool, and if a connection ever becomes invalid inside the pool, expunging only that connection from the pool is nearly impossible; JDBC 4.0 addresses all these drawbacks." In JDBC 4.0: A Significant Advance on the Standard and Features Worth the Wait, John Goodson describes the highlights of the JDBC 4.0 proposal (JSR 221), which is slated to be part of Mustang.

"In Java programming, composition is straightforward and almost foolproof.
With specifications, however, it's still possible for all kinds of
unexpected interactions to take place. Further, the number of technical
specifications seems to be steadily increasing with time, so that chances
of conflicts continue to rise." This problem is shown in the XML space in
Micah Dubinko's XML.com article, Composition, which looks at unintended
consequences in the XLink and xml:id proposals.

In Projects and
Communities,
the 48th Java Tools Community Newsletter announces the graduation of the TrueZip project from the community incubator. "Using this library a Java application can read/write access a ZIP or JAR file and its entries like an ordinary directory with the entries as the directory contents." The API provides classes which are compatible with equivalent classes in the java.io package.

The article JXTA Technology Brings the Internet Back to Its Origin notes the effect that the inherently centralized DNS has had on the initially de-centralized internet, and how JXTA repsresents a return to the internet's original philosophy: "JXTA technology was designed to address many of today's Internet limitations and return control to the edge of the network, where it initially started.

The new java.net Poll asks Does humor belong in javadocs? Cast your vote on the front page, then join the discussion on the results page.