My introduction to collaboration software was a talk by Pavel Curtis at a USENIX conference in January 1995. He talked about his research project, Jupiter, at Xerox PARC. That talk spoiled me ... none of the available collaboration software has measured up to the vision of Jupiter that Curtis presented that day.

Curtis and most of the Jupiter team spun off a startup, PlaceWare. They reimplemented the core architecture of Jupiter in Java, and began selling a successful product, PlaceWare Conference Center. (Although it's a nice product, I've always been a bit disappointed that they didn't offer a product aimed at the same space as Jupiter -- passive, continuous team collaboration and awareness.) I was interested to learn during Jonathan Schwartz's general session on Tuesday morning that PlaceWare has been acquired by Microsoft. It'll be interesting to see how Microsoft deals over time with this large system built in Java -- and also whether Microsoft's stability and clout will allow PlaceWare to resurrect that original vision.

In the meantime, though, there are others in that space. After the Wednesday general session (notable primarily for demos gone wild) I went to a session on the wonderful support for Java in Mac OS X. It was a great talk, with a really compelling and completely successful demo ... a demo of collaboration software that gave me an unmistakable sense of deja vu. Marratech is team collaboration software along the lines of the old Jupiter project.

The speaker, Alan Samuel, opened an online video conference with Serge Lachapelle and two other developers from Marratech. The Marratech group was in Sweden, and the conference was conducted over the public Internet. Four audio and video streams (although presumably the audio streams were dropped when there was relative silence) plus shared documents, with the other Marratech developers annotating the slides while Serge talked. Marratech is a Java product, and while it wasn't developed initially on OS X, the port was very easy and it's now their flagship platform. Best of all, the demo went off without a hitch.

I was particularly pleased with the quality of the audio. I was sitting right in front of one of the rear speakers in the lecture hall. Serge's audio feed, encoded in real time, shipped across the Internet, decoded on Alan's PowerBook, sounded just as good as Alan's voice, going directly into the Moscone microphone and sound system.

I think everyone present was impressed -- and the best part was that the Marratech guys in Sweden got to hear our applause.

This was my sixth JavaOne. I wasn't quite sure what to expect this year; I was afraid the conference would be a lot smaller, and that the energy might be low. I'm glad to say it was great. I heard from two sources that the conference was slightly larger than last year, at just over 15,000 attendees.

Other impressions:

• There was less swag on the show floor, but the floor was still crowded and interesting. A friend who was an exhibitor said it was fantastic -- conference attendees were interested in learning about their product, and excited about finding tools and systems that could help them.
• It's nice to hear about a focus on the desktop, and fun to read Amy Fowler's and Hans Muller's blogs on the topic. My talk on Wednesday was related to Java on the desktop, and I had great turnout and a lot of interest. But the messages are mixed -- booths on the show floor were labeled with icons indicating whether they had a focus on mobility, or the enterprise, etc. ... but there was no icon representing the desktop.
• Josh Bloch continues to be one of my role models as a speaker. I was only able to catch one of his talks this year, but it was fantastic.
• Sun, O'Reilly, and Collabnet have done a great job with the java.net site, and it's exciting to see all the activity. Sun still has a long way to go in opening up Java and the process, but this is a great start.
• Duncan is right that the real action happens outside the lecture halls. Conversations in the halls, at the show booths, meals, and evening parties are the heart and soul of JavaOne.
• This conference needs wireless!
• It may just be the crowd I run with, but so far as I can tell Sun continues to misjudge the kind of content that their attendees want to hear. I heard more than one person say that they wish the talks -- including the keynotes -- were more technical, more geared toward developers. The talks that were packed to overflowing were on very technical topics. Unfortunately, Sun doesn't collect feedback on speakers at JavaOne, and I've heard from more than one source that they don't feed attendance data back into the following year's selection process. That, combined with the fact that they don't pay speakers, keeps the technical quality lower (overall) than it could be.
• Speaking of the JavaOne speaking experience: this year all of the speakers got shirts that we were supposed to wear during our talks. Unfortunately they were hideous, and the only speakers I saw wearing them were Sun employees. I'm not here as a marketing shill, but I did want to take the opportunity to get exposure for my company (after all, that's just about the only compensation involved) so I just wore my company logo shirt. What were they thinking?

There's a mix of good and bad there, but I've had a great time. Now I have to go hop on my flight to Milwaukee to speak at the Milwaukee Java Software Symposium!]]> 2008-01-02T17:42:16Z 2003-06-12T18:35:40Z tag:weblogs.java.net,2003:/blog/glv/18.510 2003-06-12T18:35:40Z

Communities are built by the inhabitants. You can't just decide to go build a thriving, vital community. But that doesn't mean you can't seed one, and cultivate it. To do that, you persuade people to move in, provide basic services, and let them build their own community.

It might be useful to remember Levittown, the first planned suburban housing development. It was sterile and artificial, and there was a lot to criticize about it. But it met a need, and families flocked to it. And they didn't leave things the way they found them. They took ownership and built a unique community with character and life.

Sun, with the help of some partners, has built the streets and the infrastructure, put up some houses, and persuaded a few of us to move in. There are more houses open. It may feel a little sterile at first, until we can move some walls, slap up some chartreuse paint, and put the flamingos in the lawns. But people are already starting to do that. It'll be fun to see what java.net feels like by this time next year.

Then came the "serious" segments, complete with demos. That's when the fun really started. Unintentional comedy is nearly always better than the planned kind.

Three demos -- two by Sun, one by SAP -- went awry in one way or another. And of course, speakers at events like this never obey the first law of demos (Never say anything more optimistic than "Watch this!"). The unfortunate SAP developer got flustered and never actually pulled his demo off, but the guy with Sun's "Project Rave" did a fantastic job under pressure, quickly recoding the entire demo application as everyone watched. And it was lots of fun to see Rich Green and another presenter both unable to figure out how to work one of the projectors, only to have the programmer onstage lean across them, touch a button, and bring everything into instant focus.

I know that's not how things were planned, but it was very entertaining, and it gave us all a chance to root for the underappreciated heroes of such events: the lowly programmers, brought onstage to run the demos while the speaking roles go to someone else.

Big conferences like JavaOne are always accompanied by the introduction of new books. This time's no exception.

I stopped by the JDOCentral booth to visit my friend Patrick Linskey of SolarMetric, and he surprised me with a free copy of Bitter EJB, the new book he wrote with Bruce Tate, Mike Clark, and Bob Lee. I'm very pleased to have it, because early glimpses of some chapters have been posted on The Server Side, and it looks even better than Bruce's original Bitter Java.

With apologies to Patrick, the first chapter I turned to was Mike Clark's "Bitter Tunes," about performance tuning for EJBs. Mike and I have an interesting history. Last year I gave a talk at JavaOne called "Stalking Your Shadow: Adventures in Garbage Collection Optimization," and about two months later I gave the same talk at a No Fluff, Just Stuff symposium in Dallas. The talk may sound extremely technical and arcane, but it's actually a "stealth agile" talk, in which I use the complexity of GC interaction and optimization to advocate a tightly iterative approach to optimization -- avoiding both premature and "way too late" optimization by developing iteratively and building performance testing into your development process.

In the talk, I recommend using a package called JUnitPerf to automate performance testing and integrate it into your build and test process. In Dallas, I got to that slide and heard "Thanks! I'll pay you later" from the back of the room. That's how I met Mike Clark, the author of JUnitPerf. And I'm glad I did, because he's one of my favorite folks in the industry.

Mike and I independently began delivering the same message: although the hazards of premature optimization are well known, it's also possible -- easy, in fact -- to wait too long, and only learn about performance issues at a stage when they're so deeply embedded in your architecture that it's all but impossible to eliminate them. JUnitPerf is designed to help with that, making automated performance testing an easy and repeatable task, so that you can find performance problems as soon as they appear and deal with them before it's too late.

The first antipattern in Mike's "Bitter Tunes" chapter is "Premature Optimization" (and rightly so, because many developers still need to hear that message). But the solution to premature optimization isn't to just wait 'til the end of the project; it's to wait until you see real performance problems, and then attack them as soon as possible. So the second of Mike's antipatterns is "Performance Afterthoughts," and the solution is "Plan Early and Often" (a title I really like). Mike's advice applies not just to EJB projects, but to all software projects.

I've focused here on one chapter of Bitter EJB, but from what I've seen, the rest of the book is just as great, and our industry has needed a book like this for quite a while now. You owe it to yourself to buy a copy.

It was both amusing and refreshing to hear Jonathan Schwartz acknowledge in this morning's keynote that Sun has been guilty of pushing multiple, separate platforms rather than emphasizing Java as a single platform. He promised that they would do better.

Of course, they aren't in a full retreat from the multiple editions, and such a retreat wouldn't make sense anyway. There are real distinctions between those environments, and the facilities available on them need to reflect that. But I do hope they spend more time focusing on what all the editions have in common.

Unfortunately, for those of us who like to stay informed about what's coming in future releases, it's necessary to pick an edition. This afternoon at 3:30, the "Overview and Roadmap" sessions for J2SE and J2EE are scheduled opposite one another.