Springy

How long do you need to work with Spring Webflow before it clicks and you wonder how you ever lived without it?

I only ask because I desperately look forward to that day. Today I'm still doing repetitive text searches through a half-dozen xml files to find out what happens when the user presses the OK button.

Parleys Flex Client

I consume a lot of technical media, and one of my favorite sources is Parleys.com. They provide recorded presentations from Javapolis, SpringOne and other shows. They recently rolled out a beta Flex version of their site and a companion Air desktop app. It's a very cool application, offering a lot of long awaited features including local downloading of video and full screen viewing.

Parleys is making this release just as I'm pushing out the first milestone of a small flex app at work. I may post a little about Flex after I've had a little time to absorb it. Right now, I'm well within the honeymoon period, and don't think I can give a real balanced viewpoint.

Lines Of Code

There is a reoccurring misconception that I've seen at several job sites now. Developers seem to be proud of their API, Framework or Library because of how few lines of code the user needs to write, without concern for how many concepts a user must understand. A well written Library will expose as little of its implementation as possible. It will provide a single mental model for the user and a consistent way of interacting with it. While generally, this results in less repeated code, the success of the library cannot be judged on a strict line count.

Too many times, I've seen internals of a library exposed for the sake of removing a 2-3 lines of code from the caller (usually a simple if or for loop). The result is often obviously messy APIs, and a lot of learning on the user's part. It seems that when developing APIs for use internal to their company, developers simply don't have much regard for usability.

Microsoft Volta

I first heard about Volta on the Java Posse (#154). It was carelessly referred to as a GWT rip-off. Being a long-time listener (and fan) of the Java Posse, I was well aware that opinions expressed about Microsoft products are seldom well researched. I did a little more reading and was interested in what I found.

While Volta does generate Javascript, it does so in a slightly different way than GWT. While GWT reads Java code and compiles to Javascript, Volta reads bytecode (.NET IL) and compiles to Javascript. And while GWT defines its own UI APIs, Volta uses the existing .Net APIs. This means, you can write an app in C# or VB using the form designer, add some annotations to tell the system which parts are client code, and compile the same source to both a thick client and a web app.

Of course, while I can't attest to how well it works (like those at the Java Posse, I don't own a Windows PC), I do think it give us some interesting things to think about in the Java community.

• If GWT read bytecode rather than source code, it could support Groovy as well. For those who haven't tried, Groovy builders are a very clean way to write Swing code. They could have been helpful for GWT as well.
• Could a single set of UI APIs apply for Applets, Applications and GWT-like Web apps, like Microsoft's Avalon APIs span Silverlight, Windows Apps and Volta UIs?
• How many interesting ideas do we miss because we don't watch developments in competing environments?
  

Applets Still Suck

Despite all the effort Sun announced at the last Java One, applets still suck. They have for years, so why would it matter? Because JavaFX Script, Sun's latest whiz-bang technology still needs a container to run in. Embed one in a web page, and they still have all the disadvantages of an Applet.

Recently, I've worked on a web project that took advantage of both Applets and Flash technology. The difference in user experience is clear. And despite a complete rewrite of the Java plugin in Java6 Update 10, Sun is still a day late and a dollar short.

First the good news: Sun's version detection scripts work fairly well. The rewrite of the plugin for Firefox was sorely needed and will make a dramatic difference. And although I haven't seen the results, I suspect the modular nature of the new JRE will make for a much lighter weight experience for users.

So what's still missing?

The Applet framework has not been altered in any way. An Applet is still heavy-weight. It still makes an OS call to draw its window. This means that applets (and by extension JavaFX scripts) embedded in your web site will not play nice with CSS Z-orders. You cannot open a CSS dialog or popup on the same page as your applet, as your applet will always be on top.

Although the new plugin will be available as part of Java 6 (beginning with Update 10), it will need to be manually enabled by the user from the control panel. I assume this is because Sun doesn't want to ship new features in an update, which seems reasonable. But because of this, it won't be safe to assume your users can view your applet in a reliable way until Java 7 is widely available. Of course the new plugin won't work in Firefox 2 anyway. It requires Firefox 3. Oh, and it doesn't support Safari. If you run Safari, your at the mercy of Apple. Lets hope none of those JavaFx libraries get compiled to Java 6, because Apple doesn't seem to have plans to support my Powerbook with Java 6... ever.

What about the current plugin? Using the existing plugin can cause unpredictable results. In Firefox, resizing the applet can cause your applet to re-initialize (not just fire events, or call start() again). I've also seen the plugin randomly ignore the page layout and get stuck in an odd place on the screen. Refreshing the page usually fixes the problem, but that isn't something I really want to tell my end user to do. And of course the current plugin has none of the performance improvements made to the new plugin.

With all the excitement over JavaFx lately, I thought it might be a good time to remind people that there isn't a JavaFx plugin. JavaFx in the browser will still suck for all the same reasons Applets do. I expect them to continue to suck, as I see no evidence from Sun that they plan to follow through and actually fix any of this.

JLINQ - Lame

Wow.

IBM has outdone themselves. I'm struggling to find words to express what I think of their latest announcement. IBM has released a new Eclipse plugin that they call JLinq. It's essentially an O/R mapping tool that does most of its work using design time code generation. It generates SQL from beans or beans from SQL. It's essentially a bunch of Eclipse wizards that generate code. Not especially impressive, and a surprising direction after all the recent hype about JPA, Hibernate and EJB 3.

Of course bad software being released from IBM is nothing new. What I find truly exasperating about JLinq is the name. Surly a Java technology named JLinq would have some resemlence to Microsoft's LINQ technology. It's not only the same acronym, but it stands for the same thing in both technologies: "Language Integrated Query". But while Microsoft's LINQ, is a query language integrated into the programming language (go figure), IBM's LINQ is a code generator integrated into an IDE. WTF?

These kinds of projects are not just an embarrassment to IBM, but might be harmful to the Java community as well. Too many Java developers are completly ignorant of advancements outside thier own community. This kind of confusion isn't helpful. How many developers are going to assume this is a Java port of LINQ, and judge LINQ on the merits of IBM's 3rd rate Eclipse plugin?

LINQ ScreenCast

The Screening Room has a great screencast on LINQ. It's a little early to get too excited about LINQ, but the demos are very impressive. The combination of declarative type-safe queries and object oriented code makes many of our hot new trendy languages and language features seem like dirty hacks. Specifically many of the new Java features and JSRs take advantage of EL or queries embedded in Strings to get the job done -- effectively dropping down into a dynamic language. While dynamic languages may be the most pragmatic solution today, its nice to see someone is working on a more practical permanent solution.

On a related note, O'Reilly has a good shortcuts book on the under-pinnings of LINQ (LINQ: The Future of Data Access in C# 3.0). My interest in it wasn't about learning about LINQ itself, but what language features had to be added to support it. It does a good job of showing how ambitious this project is.