Sun Developer Days 2006: Day One
Sun Microsystems is winding up a tour of Australia and New Zealand with the final stop of its Sun Developer Days 2006 conference today and tomorrow in Melbourne. Fellow SitePointer Lachlan Donald and I were there today to take in the Java vibes, and as with most free conferences there was a great deal of variation in the quality of the sessions we attended.
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!