Sun has asked for feedback in a "J2SE Client developer survey," http://java.sun.com/webapps/survey/ display?survey_id=1064.

Scott Violet himself went onto javalobby.org asking for input and my initial thoughts were, "Fantastic - finally Sun is taking Java seriously on the client." I got myself a fresh latte coffee and sat down to complete the survey.

Unfortunately, the survey questions were a tad different than what I was hoping for. After a lot of questions about what desktops I used and what I was planning to use, I felt like I was filling in a Computer Weekly subscription form. Finally, up came the burning issues that Sun wants to get our input on: two questions about JFileChooser.

Here's my answer folks: I don't care diddly squat about the file chooser, nor do my users. I build applications that are concerned with viewing, displaying, and editing database entries. The software has to integrate with multiple back-end technologies, make use of different messaging protocols, and interface with call-center telephony and voice response systems. My users' programs have to calculate claim amounts based on catastrophe reinsurance spirals, and they do this by interfacing to spreadsheets and news services. This is the bread and butter of application development for anyone who is involved in serious business software.

This is what I want to see done to J2SE client development.

Ditch emulated widgets. It's yesterday's problem, and users want their applications to look and behave like other desktop programs. Most companies standardize on a desktop, and instead of Sun spending time writing lots of fancy Java code that pretends to be a native widget, just use the native widget. Infragistics JSuite and Quest JClass already provide good native extended AWT controls, and I'm tired of hearing that it can't be done because of different cross-platform focus processing. If SWT and others get it to work, so can you. Antialiased fonts and mitred line corners in Java 2D can be used by people who need them, but for most business apps that are concerned with data display and entry, just give us the extra native controls we need. And, on Windows give us better ActiveX integration. One user told me, "It's not even a case of Swing programs playing second fiddle to Visual Basic on Windows; the best it can do is stand in the back row of percussion and occasionally burp."

Rethink what layout managers are all about. If they're designed to allow multilingual GUIs, they're the wrong solution. I've worked for international companies that deploy apps in different branches across the world, and more often than not they standardize on a single language. If the program does need translating, then J2SE needs something similar to the .nib files of InterfaceBuilder, where the entire GUI is serialized as a separate file that's hand customized for each locale. The XMLEncoder sort of provides the beginnings of this, but this needs to go further and be formalized into a standard GUI architecture that allows true separation of business from display logic.

Segueing into my final point, rethink how listeners work. J2SE client development tends to encourage almost reckless use of inner classes for event handling logic, and inner classes are expensive to load and require flashy VM trickery to work. Someone needs to go back to square one and look at how other languages such as Python and Smalltalk deal with this, and maybe introduce some way of soft typing event callbacks.

I looked for the bit at the end of the survey that lets me type in comments that I want the Swing team to read; however, there was only a tiny text box available. Next time make the box bigger, please guys.