I am really coming around to Java Studio Creator. I spoke with Jim Inscore from Sun today about it, after detailing my initial impressions on it, and we spent some time discussing the product, its positioning, and its future role.

For one thing, he never called it "Rave," that I remember. I like the name "Rave;" it's distinctive, it has a certain panache. That said, it's only a code name for Sun, and lacks Sun's typical vanilla naming, so we have "Creator," instead.

We talked about where Studio Creator fits in the developer landscape. Sun places Studio Creator squarely in the corporate developer's arena. To understand this, he said that one of the most common development tasks in Java yielded a small, one-off, pragmatic web application - not an n-tiered, scalable monster enterprise application. Developers who create things like this don't spend a lot of time mastering Struts, or EJB, or much of the other J2EE APIs. They're looking at pragmatism in programming, more than structural elegance - just "get it done," rather than "do it correctly." They're the rank and file. (If you're one of these people, don't take it as an insult - you're where the tire hits the road for Java.) The API isn't important, here: the task is. Using available resources is more important than making resources available.

Contrast that group with the more technical set - the technologists and the architects. Both of these groups tend to focus on the APIs, where doing it correctly is more important than timeliness. These people will be more of the ISO crowd, the elitists and eggheads. These groups would rather write a framework, or use an acronym API, than just talk to a database and render via JSP. While these groups will (usually) yield a more scalable application, it typically takes much longer simply because they spend more time on infrastructure than application.

The latter groups want an IDE like JBuilder, Eclipse, IDEA, or NetBeans; something that helps them write code. The corporate developers tend not to care about code; they want something that helps them write applications. If they can get away with writing absolutely no code, that's fine. (Yes, I know, I'm generalizing. Many corporate developers enjoy writing code, and some technologists would rather stay away from it.)

Studio Creator is aimed squarely at the corporate developer, meaning that it's got the primary goal of enabling component reuse, whether it's a JSF component or a web service. Pre-packaged elements are king, here; think about the impact component development had for Visual Basic. This is something Java has been looking for for a long time, and I think it's finally coming around, with a product geared for component inclusion (JSF), and an IDE designed from the ground up to use component-based development.

JSF is still in its infancy, to be sure. I've not been circumspect with my own doubts about the technology, which I feel would be far too easy to abuse. However, most infants grow over time, hopefully into functioning adults; JSF's lifecycle surely has the same potential. As a new technology, its pitfalls are still being discovered and it's certainly improving.

Studio Creator actually helps that along, by encouraging usage of JSF in ways that don't expose its weaknesses. Because it still gives developers the ability to see raw code, it also allows coders to use every feature JSF provides, which will help JSF itself improve.

Creator, too, is still new. I found a lot of small things that didn't seem intuitive: absolute positioning on the pages, package structures seem underexposed, and the snippets feature looked like a bit of an afterthought. More critically, Studio Creator feels limiting. I'm personally comfortable with leveraging the J2EE stack, and Studio Creator, with its drag-and-drop approach, seems to discourage me from really working with projects in the ways I'm familiar with.

That's all right. Mr. Inscore pointed out that Studio Creator is only in pre-release, and he detailed some features that they wanted in future releases, such as being able to create rich desktop applications and mobile applications, leveraging EJB components, publication of web services (as opposed to simply using existing services) and others. As far as my personal preferences working with Studio Creator is concerned, there are a few reasons that my response is appropriate as well. I tend to fall outside the target market for Studio Creator, and even so, I find that I might end up relying on it for more pragmatic projects - because, psychologically speaking, having choices tends to be empowering, but having an incredible array of choices is actually a source of frustration. (See The Tyranny of Choice, by Barry Schwartz, published in Scientific American, April 2004 issue.) From that vantage, Studio Creator - by providing a straight line implementation choice instead of leaving the developer to decide whether to use Velocity, FreeMarker, JSP, or Cocoon... with Struts, Tapestry, WebWork, or raw servlets... with EJB, JDO, Hibernate... and let's not forget the array of testing possibilities.

Altogether, Studio Creator is workable. It's not good yet, but its prerelease status makes that acceptable. Furthermore, Sun is expecting it to help supercharge the reusable component market that the Java community hasn't quite leveraged yet, if only by focusing attention on the components instead of the tools that use them. It's a very focused product, and in my opinion, it's focused well. I'm looking forward to final releases, as well as the competition other vendors offer it.