News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
ASP.NET MVC 2 Ships
ASP.NET MVC 2 has shipped.
03/12/2010 10:26 AM EST

Microsoft plans 'open' Silverlight analytics framework
Microsoft is going to announce a multipurpose analytics framework for Silverlight at MIX.
03/11/2010 09:51 AM EST

About CSS processing
Two sites that lead to a startling CSS conclusion.
03/10/2010 02:29 AM EST

 

Events calendar tab
3/14/2010 to 3/18/2010
Seattle, Wa.
SHARE

3/15/2010 to 3/18/2010
Santa Clara, Calif.
TechWeb

3/15/2010 to 3/17/2010
Las Vegas
Microsoft

3/16/2010 to 3/19/2010
Las Vegas
Penton Media

3/17/2010 to 3/19/2010
Las Vegas
TechTarget


 
Most Read Latest News Blog Resources

Java Studio Creator




August 15, 2005 — 
I’ve been spending the past day or so fooling around with Sun’s new Java Studio Creator, and this column gives my first impression. (I reserve the right to change my mind once I’ve worked with it more.)

At the risk of putting Descartes before da Horace, I’ll start with my conclusion: There’s so much wrong with this product that it’s hard to figure out where to begin.

Java Studio Creator is one of a long line of products that started out with Microsoft’s “Visual” tools, circa 1985. Microsoft had come up with a miserable “foundation-class” library (Microsoft Foundation Classes) that nobody could use to build real applications. Once you got past the executive-demo stage, MFC was very difficult to program, buggy and not really up to the task. It took months of study to get good at MFC programming, and systems built with MFC were far from robust. I know of several projects (Sun’s original AWT library was one) that were simply discarded and rewritten using the underlying Windows APIs because MFC proved so ungainly.

The Microsoft solution was unfortunate. Rather than replace the library with something more reasonable, Microsoft chose to wrap it. Microsoft built a series of “wizards” that wrote bad code for you. In fact, since it was machine-generated, the actual program—at the source-code level—was even worse than it would have been had you built it by hand. At least you didn’t have to look at it.

Java Studio Creator follows in Microsoft’s footsteps. Sun has put so much PR hype into the J2EE APIs that it can’t really admit that these APIs are flawed. Like Microsoft, Sun has provided a tool that writes hideously overcomplex code for you so you don’t have to do it yourself. I’d rather write good code to a good API than wrap a bad API with machine-generated code that I can’t understand. (Let’s hope they’ll fix some of the problems with the existing APIs in future versions of Java.)

Sun has actually done an OK job on the tool itself. Using Studio Creator, you can put together a trivial Web application based on JavaServer Faces in almost no time. Studio Creator isolates you from the complexity of JSF, with it’s XM-hell configuration files and complex plumbing.

The process looks like Visual Basic, treating an application as a user interface with intelligent warts (written in Java) hanging off of it. This Java executes when you interact with various components such as buttons. You can lay out your screen, insert controls, modify properties and edit the attached code. A graphical tool lets you set up navigation. You can easily bind data (both fields and database tables) to widgets. If your app does nothing but expose the database to your end user, Studio Creator will work great for you.

The problem is that most of the apps that I’ve worked on are not this simple. Take database binding. I usually work very hard to hide the database from my object model. That is, I start by designing and building an object-oriented system around user-defined use cases. When necessary, I store an object’s state in a database using a transparent persistence mechanism like Hibernate. The object model comes first, then I add persistence. My goal is to be able to change the database schema without impacting the object model (or vice versa).

I apply the same reasoning at the user-interface level. I start with the object model, then I figure out how to let objects display themselves. I want to be able to change the UI without significantly impacting the object model and vice versa. Again, the object model comes first. A program is not a UI with intelligent warts on it; it’s an object model that exposes a user interface.

An application built with Studio Creator doesn’t even have an object model, though. The direct binding of the UI to the underlying implementation (both at the field and the database level) makes this sort of modularization impossible to accomplish. As a consequence, applications built with Studio Creator will be both difficult to maintain and difficult to extend. If you change the object model, you’ll either have to root around in all that machine-generated gunk or go into Creator and manually change the code associated with each control. This is way too much work for me.

The core flaw in Creator is the chimera of programmerless programming. I’m sure that some managers will look at Creator as a way for nonprogrammers (or at least very junior programmers) to program. Though they’ll certainly be able to throw together something that appears to work in record time, in the long term, Creator is not a substitute for good structure and carefully hand-crafted code.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.


Share this link: http://www.sdtimes.com/link/28781
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading