Many developers had feared that the removal of the previous preview signalled an intent from Apple to ignore Java 6 in favour of continued minor tweaks to Java 5. It seems now that the optimists were right: Apple just needed more time to get Java 6 right, so it took a step back and made some improvements to Java 5 for the Leopard release before pressing on with its work on Java 6.

The fact remains that if Apple were only to communicate with its closest allies—software developers—in a meaningful way, we wouldn’t be left playing these guessing games over the company’s intentions.

As anyone who has attended a developer conference in the past few years can attest, developers as a group are some of Apple’s best customers. If only Apple treated its developers with as much reverence.

In a post on The Java Lobby entitled So Long Apple. The Party’s Over, Michael Urban summed up the situation nicely:

Not only did Leopard not ship with Java 6, but Apple, in typical fashion, apparently thinks it has no obligation to its customers to inform them about why the plans changed, and when (or even if at this point?) Apple will ever have a working copy of Java 6.

Now, it’s obvious that Apple hasn’t dropped Java completely. As many developers have pointed out, Apple did do plenty of work on its version of Java 5 for the Leopard release. Ben Galbraith recently gave a run-down of his favourite Java improvements in Leopard, based on Apple’s Release Notes for Java 5 on Leopard, for example.

But still, despite what is now going on two weeks of furor in the Java community, there is no word from Apple about the state of Java 6 on Mac OS X.

On the one hand, there is speculation that its release is imminent, based on Apple’s history of releasing Java 5 within weeks of Mac OS X Tiger. On the other hand, the significant improvements Apple made to Java 5 for the release of Leopard cast doubt in my mind over whether Apple has done any work on Java 6 lately.

None of this would be anywhere near as frustrating if Apple would simply break its stony silence. It’s one thing to hold back announcements of new products to maximize their marketing impact, but keeping your most important allies—developers—in the dark about the future of major technologies like Java is no way to do business.

Have you written your own AJAX framework yet? It seems all the big boys are doing it. Microsoft is bringing us Atlas for ASP.NET, Yahoo!’s User Interface Library is open source, server agnostic and beautifully documented and Adobe is working on Spry, which is off to a shaky start in the web standards department. Do we really need another?

Google’s late-but-inevitable entry into this arena is certainly no copycat. The Google Web Toolkit (GWT) is nothing less than a completely original approach to web development that allows server-side Java developers to take their skills to the JavaScript domain… without having to write any JavaScript.

In short, you write, test and debug your client-side code in Java and then use a specialized compiler to convert it all into cross-browser JavaScript for use on your site.

How’s it work?

You can write you client-side code using the usual core Java classes in the java.lang and java.util packages, as well as a nice library of classes that come with GWT that let you access the same browser features that are available in JavaScript (the Docment Object Model, alert boxes, setTimeout, XMLHttpRequest, etc.).

You also get a bunch of Java classes for adding widgets to the page, from simple buttons to complex drop-down menus and trees. All of these widgets offer events that you can subscribe listener objects to, and write Java code to respond to them.

When you’re ready to test out your application in a browser, you simply compile your classes in your Java IDE of choice and launch the GWT Shell, which pops up a specialized browser window and loads your application. On Windows, that browser window uses the Internet Explorer rendering engine, whereas on Linux it uses Mozilla.

The GWT Shell acts as a go-between between your Java classes and the special browser window, allowing your application’s client-side logic to run within the browser even though it is implemented in Java, not JavaScript. This small miracle actually lets you test and debug your client-side logic as you would any other Java code! Set breakpoints to pause and step through client-side event handlers, write unit tests to verify that your user interface works as designed. It all just works.

At this stage, your application is still a collection Java classes, and the final development step is to compile those classes down to efficient cross-browser JavaScript code. The compiler that comes with GWT actually reads the source code of your classes and generates the equivalent JavaScript code!

You can then take the generated JavaScript code, along with your static HTML, CSS and image files and dump them on a server as you would for any other web site. The resulting code is entirely self-contained — no browser plugins or special server technology required.

What about AJAX?

As I mentioned, the class library does give you access to the XMLHttpRequest object normally used in AJAX applications, but GWT also offers an even slicker method of communicating with the server.

In addition to your client-side code, you can write Java server-side code. Because it doesn’t get converted to JavaScript, this code can use the full capabilities of the Java platform, and any additional class libraries you may require.

In your client-side code, you can set up classes that are able to communicate with your server-side code. When your application is compiled, GWT will automatically generate all the JavaScript needed to communicate with the server on the client-side, and will compile your server-side code to a set of Java Servlets.

You can deploy these Servlets on any Java web server, and let GWT do the rest. GWT manages the conversion between JavaScript variables on the client-side and Java objects on the server side, and again it all just works.

GWT also includes a full browser history management system, allowing you to involve the browser’s Back and Forward buttons in your application’s navigation, even though the browser never actually leaves the page containing your applications.

Sticking Points

Google has definitely put together an impressive platform with GWT, but as one would expect (especially from a beta product) it’s not perfect:

• GWT detects and supports browsers by their user agent string.

  You must rely on Google to add support for future browsers. Right now, for example, GWT applications are incompatible with IE7. You can hack the toolkit to treat it like IE6, but that’s the extent of what you can do to support new browsers.

• The bundled GWT widgets make extensive use of tables for layout.

  If you want you application to generate a standards-compliant document structure, you’ll need to write your own widgets, which isn’t a happy prospect.

• GWT was written to work with Java 1.4 or later.

  As such, it does not take advantage of Java 5 features like annotations and generics. This adds some redundancy and bulk to the code you must write, especially when working with the AJAX features of the library. For example, each server-side access point in your application requires you to write an interface to describe the servce, another interface to describe the asynchronous version of the service, and finally a class to implement the service. Using annotations, you could do it all by writing just one class.

• The development shell does not support Mac OS X.

  Google is saying that Mac support is planned, but for now GWT development is limited to Windows and Linux. Compiled GWT applications run just fine in Mac browsers, of course.

• Unclear best practices for security and performance.

  By masking the client-server division, GWT could lead unwary developers to make some serious security and performance blunders. You really need to know what you’re doing to use GWT effectively.

But the biggest thing lacking in GWT is an example of a finished, real-world application running in the wild. No doubt Google is hard at work on its next big project using GWT, but for now at least GWT is unproven technology.

One of the new key features in Java 6 (Mustang), available now in beta and weekly snapshots and slated for release in October, is support for alternative languages running on the JVM. In particular, Java 6 will ship with support for running JavaScript code as a first-class citizen, with complete access to the Java class libraries and the ability to call back and forth between Java and JavaScript code within a single application.

At JavaOne on Tuesday, Sun took the wraps off of two new projects that are taking advantage of this capability in a way that will be of interest to web developers. The first, Project Semplice, brings the Visual Basic language to the Java platform. Not meant for porting existing VB apps over to Java, but rather for allowing Visual Basic developers to transition to the Java platform while leveraging their existing skills, Semplice lets you write code using VB syntax (including all the automatic type conversion, support for properties implemented by methods, and other niceties that VB developers love so much) that compiles to Java classes that will run on the Java 6 VM. As J# is to Java, Semplice is to Visual Basic.

In the demo during the keynote, Semplice developer Tor Norbye (regular on the Java Posse podcast) demonstrated building a simple web application in VB using a pre-release version Java Studio Creator. Starting from a blank page, he dragged a number of JavaServer Faces (JSF) components onto the page, then double-clicked one to add an event handler to it. The editor that popped open contained a new event handler written in Visual Basic, to which he quickly added some simple implementation code, then compiled and ran the application.

The application, he pointed out, made use of JSF components written in Java, and he accessed properties of these directly from his Visual Basic code. Additionally, the JSF components call the Visual Basic event handling code from within Java. Semplice allows these two languages to work together transparently.

Thanks to features of the VB language, instead of having to call farenheit.getText() to obtain the value of the farenheit form field, he could refer to it as farenheit.Text, or even just as farenheit, thanks to Visual Basic’s flexibility. He was also able to use the resulting String value in an arithmetic calculation (i.e. celsius = (farenheit - 32) * 5 / 9) without having to convert it to an integer.

For developers that want the power of Java when writing server-side business logic, but want a more flexible and loosely-typed language when writing web presentation logic, Visual Basic running on the Java VM could well be a very attractive option!

Even more flexible than Visual Basic, however, and likely much more familiar to them as well is JavaScript. So why not write the server-side code of web applications in JavaScript? That’s exactly what Project Phobos will do. With Project Phobos, you can either write server-side application logic with JavaScript directly within your HTML templates (much like you can in PHP or JSP), or in separate “helper” scripts to keep your code separate from your markup.

Along with the many other projects working to bring other languages to the Java VM, these two projects give developers even more choices when considering Java as a web development platform.

The video of both demos may be found in Segment Three of the Sun Technical General Session: Java Platform Roadmaps: The Big Stuff, Today & Tomorrow from Day 1 of the JavaOne 2006 conference.

Full details and screenshots of Semplice in action on project developer “HerbertC”’s blog.

During his opening keynote at JavaOne 2006, newly annointed Sun CEO Jonathan Schwartz welcomed to the stage Rich Green, Executive VP of Software, with the hard question: “Are you going to open source Java?”

After a little mock evasiveness, Green explained Sun’s latest thinking on the matter, ending with the bottom line: “It isn’t a question of whether, but a question of how. And so we’ll go do this.”

Green did take the time to point out that, from the perspective of community involvement and contribution to the development of the Java platform, Java is already effectively open source:

There’s two battling forces here. There’s the desire to completely open this up–complete access–I mean, so many changes of the licenses have been made that it’s virtually all there. But there is the sense of wanting to complete the program. The flip side is compatibility really matters. I don’t think anybody wants to see a diverging Java platform. One of the great values of Java has been that we’ve been able to keep it together–something you can all rely on in terms of its consistency and value and evolution. And the challenge, going forward, is how to solve for both of those things.

C|Net has video of the conversation, and of course the full webcast of the session is available on the JavaOne web site.

But whether due to time, money or geography, not everyone can make it to San Francisco to bask in the Java love for a week.

Thankfully, you can follow the big picture from wherever you happen to be. All of the general sessions (i.e. keynote speakers and demos) are available for viewing via live and on-demand webcasts that are almost as good as being there (plus you get to skip the boring bits!).

As for the more focused technical sessions, most of them have published downloadable PDFs containing the slides for free download from the session catalog. You can also wait until the dust settles and the slides will be freely available with synchronized audio from JavaOne Online.

And if podcasts are your thing, PodTech.net is hosting a series of podcasts from JavaOne, including the full audio of all the general sessions. Unfortunately, there is no dedicated feeed for just the JavaOne programs, so you might find yourself downloading some programs from other tech conferences going on at the same time.

But now it looks like JRun might be set to rise from the ashes, with Adobe looking for beta testers of a major new release. At this stage, Adobe is tight-lipped on what new features will come with this version–EJB 3.0? Jetty-like continuations? More affordable pricing?

I’ve asked for a look at the beta, and will report what I can when I can.

Tomcat, of course, provides the reference implementations for the Servlet and JSP specifications, but by virtue of the fact that it is free, it’s also the server of choice for many small-to-medium businesses. I took a critical look at Tomcat myself awhile back, while looking for a beginner-friendly Java web application server (I’m still looking).

Suleiman’s critique of Tomcat is based, somewhat refreshingly (he often resorts to unpersuasive, if entertaining, personal attacks on the developers), on the quality of the project’s code–or rather its lack thereof. Choosing a pivotal but relatively uncomplicated class (DefaultServlet, which is responsible for serving static resources like HTML/CSS/JavaScript files and images), he points out many examples of terrible coding practice, of which these are only a sampling:

Initialization code that lazily catches Throwable

        // Set our properties from the initialization parameters
        String value = null;
        try {
            value = getServletConfig().getInitParameter("debug");
            debug = Integer.parseInt(value);
        } catch (Throwable t) {
            ;
        }
        try {
            value = getServletConfig().getInitParameter("input");
            input = Integer.parseInt(value);
        } catch (Throwable t) {
            ;
        }

Throwable is the base interface for all Java exceptions an errors, many of which have no business being caught by this sort of code, let alone being ignored as this code will do. If the server happens to run out of memory while initializing a DefaultServlet, for example, this code will ignore the resulting error and attempt to continue running.

Attempts to identify particular exceptions by portions of their message strings

        try {
            serveResource(request, response, true);
        } catch( IOException ex ) {
            // we probably have this check somewhere else too.
            if( ex.getMessage() != null
                && ex.getMessage().indexOf("Broken pipe") >= 0 ) {
                // ignore it.
            }
            throw ex;
        }

Fortunately, the if statement in question (which, from the comment, it seems the developer was rather uncertain about) doesn’t actually cause the exceptions it identifies to be ignored (as the second comment says it should do), so this confusing twist of poor programming is actually useless anyway.

A method that returns an exception instead of throwing it

    protected IOException copyRange(InputStream istream,
                                  ServletOutputStream ostream) {

        // Copy the input stream to the output stream
        IOException exception = null;
        ...
            try {
                ...
            } catch (IOException e) {
                exception = e;
                ...
            }
        ...
        return exception;

    }

As a believer in open source development, I looked at every issue he pointed out to give it the benefit of the doubt. “Okay, it looks silly, but there must be a good reason that they did that.” There wasn’t, of course, unless you consider laziness or ignorance a good reason.

For a project produced under the public scrutiny of the open source development, these are disturbingly fundamental issues indeed. For me, the most important question becomes not whether or not Tomcat sucks, but whether this level of code quality is the exception or the norm in the Apache camp.

I know for a fact that there is plenty of good quality open source Java code in the wild. I’ve probed into the code of Jetty a number of times, for instance, and have been pleasantly surprised by what I found there. I also know that poor open source code isn’t just a problem that faced by Java. But Apache is supposed to be a leader in the field.

If the repeated condemnations of The BileBlog are any indication, the majority of the web could be running software like this–code that looks like it was written in a desperate push to meet a deadline with something that works… most of the time… just barely.

Before the day’s sessions began in earnest, Sun organiser David Coldrick got up to plug two useful resources for Java developers to keep up with the latest developments between Developer Days conferences: The Java Posse podcast (which I highly recommend as well!), and javapassion.com, which I have covered in this blog before.

Building Great Games for the Mobile World, Chuk Munn Lee (Sun)

Having done some work on mobile games already, I was hoping for some insight into the technical issues that face game developers on this platform: device-specific API fragmentation, application size and processing speed limits, inconsistent control methods, and more. What we got instead was a non-technical overview about the pros and cons of developing games for mobile handsets as compared to the PC- and console-based game platforms.

In brief, Java Micro Edition (ME) is a lightweight platform that can let you produce a fully-realized game for millions of potential users with as little as one man-month of development time. Successful games for this platform should take into account the fact that gamers will be playing on-the-go, for brief periods, and may stop playing at any time. Given this, the popular practice of adapting old games from other platforms to handsets is not a great approach.

Optimizing Performance for Java SE & Java EE Applications, Simon Ritter (Sun)

Again, my expectations were a bit off the mark for this session (I really wish the conference programme had included session abstracts). Rather than a grab bag of useful techniques for writing speedier code, or an overview of certain common performance anti-patterns, what we got was a tutorial on tuning the garbage collection algorithms in the Sun Java Virtual Machine (VM) using a variety of undocumented (or poorly documented) command-line switches.

I quite enjoyed the explanation of the VM’s heap management techniques, and how they allow for the tendency of Java applications to make extensive use of short-lived objects that must be garbage collected quickly and efficiently for Java to work, as well as the look at the biased locking algorithm that was introduced to further improve performance in version 1.5.0_06 of the Java 5 runtime. But the vast majority of the performance tweaks discussed would apply really only to high-load, multi-processor servers, so were little more than technical curiosities for me.

SOA, JBI, BPEL: Strategy, Design & Best Practices, Rima Patel (Sun)

In his day one session, Ashwin Rao showed off some of the tools Sun is cooking up for developers to tackle the unique challenges of building applications based on discrete, specialized services — a practice known as Service Oriented Architecture (SOA). Ms. Patel took a step back with this session and looked at the motivations and technical challenges of SOA, which must be considered long before development tools come into the picture.

While developers are used to facing new accronyms and buzzwords that, once grasped, bring technical benefits including performance, usability, and ease of development, SOA is very different, in that the motivations that drive it are largely business-centric.

Many big businesses today are straining under the weight of overlapping legacy systems that have been developed and connected on an ad hoc basis, on conflicting, often vendor-specific platforms. The SOA approach to this problem is to identify key services that exist within these systems and to either reimplement them or wrap the existing systems in interfaces such that applications can discover and access them openly, asychronously, statefully and securely through the exchange of XML documents that mirror the business documents that would change hands in the paper-based equivalents to the relevant business processes.

Ms. Patel went on to briefly outline the Java Business Integration (JBI) specification, which provides the plumbing for SOA applications in the form of an open framework that is both vendor and platform neutral. Not a bad option if you’re rearchitecting the IT systems for a major bank, which I’m not. For me, this session was mainly about confirming that my vision of what SOA means roughly matches with Sun’s. I make no guarantees as to whether or not it matches yours.

Java SE: Tiger, Mustang and Dolphin, Simon Ritter (Sun)

A relatively straightforward session, this talk rattled through an overview of the most high-profile features coming in Java 6 (codenamed Mustang) later this year. There’s plenty of good coverage of this going around, especially because Sun has been very open about Mustang’s development, with weekly builds available for download and testing.

Changes most likely to affect web developers in Java 6 are: full support for XML web services built in, the inclusion of the Rhino scripting engine, which will permit JavaScript code to run on the Java VM and make full use of Java class libraries; JDBC 4.0, which will simplify and enhance the primary API for Java applications connecting to databases; and better debugging support, making it easier to detect and diagnose deadlocks, memory leaks, and other runtime issues.

Personally, I’m most excited about the enhancements for desktop-based Java applications, but Mr. Ritter skipped over most of these in favour of more core changes to the platform.

Mr. Ritter did take a few minutes to give some hand-wavy examples of the sorts of things planned for Java 7 (codenamed Dolphin), including support for XML code appearing natively within Java code, and bytecode changes to support dynamic languages (such as scripting languages) running on the Java VM, but with almost nothing set in stone for Dolphin, every scrap of information was accompanied by the disclaimer: “On the other hand, we might not do this at all.”

Making AJAX more effective with servlets, JavaServer Pages Technology, & JavaServer Faces Technology, Doris Chen (Sun)

The confused title should have scared me off, but I went along to this session hoping at least to see some elegant examples of supporting AJAX applications within server-side Java code. I gave up and left after watching roughly 45 minutes of the speaker’s confused and confusing attempts to simply define what AJAX was. I wasn’t the only one to walk out.

I hate to pan the presenter further, but it’s a sad day indeed when you can’t keep a room full of developers interested in a presentation about AJAX.

Sun Developer Tools, Bob Brewin (Sun)

In his keynote, Mr. Brewin spoke chiefly about the push Sun is making towards Ease of Development (EoD) across the entire Java platform and the set of Sun developer tools. Key examples of this included the new language features in Java SE 5.0, the release as a free download of Java Studio Creator, and the Java Persistence API, which is set to replace entity beans in EJB 3.0. This is all old news, however, and Brewin looked like he’d delivered this keynote fifty times before. Though some of the improvements being made to the Java landscape may be inspiring, this session was not.

Changing the Landscape of Software Development, Simon Ritter (Sun)

Mr. Ritter’s keynote essentially covered all of the ways Sun is fostering open source development with Java. Again, there was very little in this talk that would have been news to the people in the room, and Ritter seemed vaguely embarassed by this fact (even wondering aloud at some of the choices of imagery “his boss” had made in assembling his slides for him). The end of the session, which described all the ways in which Java was as good as, if not actually open source, seemed downright defensive… which was especially odd because a quick poll of the audience indicated only a small minority thought that it should be.

Rapid Web Application Development Using Sun Java Studio Creator, Ashwin Rao (Sun)

Very much a quick introduction, this session took a quick spin through Java Studio Creator, a tool for drag-and-drop web application development using JavaServer Faces (JSF). I’ve seen a couple of introductions like this in the past, and while I applaud what Sun has achieved with Creator in terms of making it possible to throw together Java web applications in a hurry, I’m still not sold on its merit for producing best practice code (at least, not out of the box).

Much like Microsoft’s Visual Web Developer edition of Visual Studio (with which Creator was obviously designed to compete), Creator lets you quickly produce web user interfaces by dragging ready-made components onto a design view. I shudder every time I consider the accessibility repercussions of using this development mechanism naively (particularly in the default “grid” layout mode, which makes use of absolute pixel coordinates to position all page elements).

That said, the JSF technology that Creator is based on is certainly capable of producing standards compliant, accessible web sites. What I want to know is whether the quick-and-dirty results that Creator seems so ready to produce are the fault of the tool (in which case I humbly suggest Sun should go back to the drawing board), the bundled components (in which case a dedicated group of developers could produce a more “responsible” set of components to use in Creator), or just the way the developer chooses to use them (in which case SitePoint should probably write a book similar to its recent Dreamweaver title).

SAP Technical Session: Running Open Source based Java EE Applications on the SAP Web AS, Taib Lokman (SAP)

While I’ve certainly seen the name SAP bandied about, I didn’t really understand how it fit into the Java space. It turns out that SAP has been in the Java enterprise development business for awhile, and today it offers its own suite of Java EE servers and Eclipse-based development tools. SAP sponsored the conference, so I was expecting a sales pitch in this session. What I got instead was unexpected, and very confusing.

In his talk, Mr. Lokman introduced and even demonstrated a number of popular open source Java enterprise technologies (Struts, Axis, Ant, etc.), seemingly held them up as great things that we should all be using, and then explained that SAP had its own more or less proprietary alternative that you would have to deal with if you were ever called upon to work on a project that relied on SAP’s platform. And that was it. Seriously, it was like “Who uses Struts? Great! Isn’t it cool? But if you use SAP, you’ll need to learn NetWeaver, which is quite different, instead.” Rinse and repeat.

Persistence for Java SE & Java EE, Rima Patel (Sun)

As the co-author of the book Mastering EJB, 3rd Ed. (free PDF download), which apparently has a 4th edition coming out soon that will also be freely available for download, Ms. Patel really knows her stuff when it comes to Enterprise JavaBeans (EJB). That translated to a dynamic and illuminating talk about what we can expect from the soon-to-be-released EJB 3.0.

The single biggest change to EJB 3.0 is the radical rethinking and simplification of entity beans. Used to represent database records (and other persistent data items) as Java objects that can participate in transactions and have their state synchronized with the database, entity beans have been a serious pain point in EJB for a long time. They require developers to write a lot of repetitive boilerplate code, and were limited in many ways that Java objects normally aren’t. In EJB 3.0, entity beans have been scrapped in favour of the Java Persistence API, which lets you use label plain old Java objects (POJOs) as entities, which can do all the things entity beans could do, but without all the tedious coding overhead and without all the limitations of entity beans.

For awhile now, Java developers have had the benefits of a lot of the Java Persistence API in the form of Hibernate, an open source library that maps relational database records to Java objects. With the Java Persistence API, however, those powerful capabilities will not only become a standard part of the Java EE platform, but they will be able work within EJB architectures, with all the resource and transaction management that EJBs were designed to provide.

Tackling Complexity & Improving Productivity in Developing to SOA, Ashwin Rao (Sun)

I haven’t had much to do with Service Oriented Architecture (SOA), an emerging vision of enterprise development where discrete, specialized services can be assembled and orchestrated together to produce useful applications with high degrees of scalability and flexibility. It’s certainly the direction that large enterprises are moving in, but at ground level where most of the developers in our audience reside, it’s not much of a factor. This session was an opportunity to check in with the state of SOA.

Mr. Rao briefly outlined the realities of SOA today, and then concluded that managing the resulting complexity means coming up with tools that address the unique challenges of orchestrating disparate services in a useful way. This offered a convenient lead-in to a demo of Java Studio Enterprise 8’s UML modeling features, and the visual designer for Business Process Execution Language (BPEL) that Sun recently debuted in a preview of the Netbeans 5.5 Enterprise Pack.

The BPEL designer lets you assemble multiple web services together to produce composite services, essentially by drawing a flowchart to generate an XML description of the required process behind the scenes. Although the flowcharts produced by the tool were undeniably slick, whenever we glanced that the generated XML code it seemed to me that we could have written that code in much less time than it took to step through the wizards required to produce it graphically. Assuming SOA takes off and composite services will begin to involve more complex interactions than the simple demo we saw, I could see the value in being able to visualize those interactions rather than slogging through XML code; nevertheless, I was left with the impression that the problems of SOA that need to be solved are still being discovered, and as a result the tools are at least a generation away from becoming truly useful in the wild.

NetBeans Extreme: Matisse, Collaboration, Profiling and Plug-ins, Angela Caicedo (Sun)

In this marathon 90-minute session, Ms. Caicedo demonstrated just about every aspect of NetBeans 5.0, the latest version of Sun’s free Java IDE, that has been enhanced in this latest release.

NetBeans 5.0 caused a splash in the desktop application space by introducing Matisse, a remarkable new GUI layout tool that removes a lot of the complexity that Java developers have come to accept from the Java’s Swing GUI API without sacrificing much (if any) flexibility or quality in the finished product. Instead of relying upon Swing’s existing LayoutManager classes (such as the infamous GridBagLayout), Matisse uses its own GroupLayout class, which has since been slated for inclusion in the upcoming Java SE 6.0. The demo of Matisse in this session was enticing, if not entirely convincing to a veteran GridBagLayout user like me. It may be miles and miles ahead of any visual GUI layout tool Java has had in the past, but the demo suffered from a couple of minor layout issues that I could have avoided with GridBagLayout, and I’m curious if Matisse offers a solution to these.

The collaboration features were certainly a surprise — I’m not sure how I missed their mentions in the excitement surrounding NetBeans 5.0’s release. Similar features formed the major enhancements in JBuilder 2006 last year, but with the future of that IDE in serious jeopardy, it’s nice to see these features a healthy IDE like NetBeans. Essentially, the IDE includes an instant messaging client that allows you not only to chat to your fellow developers, but also to share your local project code, browse and edit that code collaboratively through shared views, and even run shared debugging sessions to locate problems together. I had assumed that, for this to work, both developers would need to have their own copy of the project in question on their system, but the demo showcased the fact that shared coding sessions are actually centered around one developer’s copy of the project, and all the other developers need is a copy of NetBeans to participate.

Next up, Caicedo took the profiling features in NetBeans for a spin, pinpointing the thread responsible for hanging the interface of a simple Swing application, and then identifying a slow method in a web application. The new profiler is one of NetBeans’s biggest advantages over the other, more popular free Java IDE, Eclipse, which lacks built-in profiling. While not quite as powerful as a dedicated profiling product like YourKit Java Profiler, the tools in NetBeans 5.0 are certainly respectable, and will assist in resolving all but the twistiest of performance issues.

Last, but not least, we got to watch a complete plug-in for the NetBeans IDE come to life before our eyes. With Java development spanning so many different application domains, it’s impossible for a single IDE to bundle every tool that a given developer might need. That’s why all the big IDEs these days place a great deal of emphasis on extensability through plug-in architectures. NetBeans is no exception, and with the integrated wizards and packaging tools Caicedo was able to add a Google search field to the NetBeans toolbar in mere minutes. IDE plug-in development, at least for NetBeans, is certainly a far less intimidating discipline than I had previously imagined.

So will I be switching to NetBeans tomorrow? I’m afraid not. Although NetBeans 5.0 has made some impressive strides, and the new pieces in the tool are certainly impressive, many of the basic facilities still have a “toy IDE” feel that I just can’t get past. Lack of fundamental facilities like multiple run configurations and project groups just don’t quite cut it for me. Still, there’s a lot to like in new features and old (I especially appreciate the use of Ant for all build tasks), so I’ll certainly be keeping an eye on NetBeans.

All up, after a weak start, the day got a great deal more interesting as talk turned from general spin to down-and-dirty coding. Hopefully tomorrow will hold more of the same!