Tonight's SeaJUG meeting was the annual panel of JavaOne attendees. One interesting thing that happened during the discussions was the amount of concern raised over the new language features, particularly generics and attributes. There was some feeling that Java 5 was going to create two languages, pre Java 5 and Java 5. The fact that many of the new JSR's are already incorporating generics and attributes will only strengthen that separation. A few people felt that it would be even worse, that due to the timing of the releases, Java developers would actually have to deal with 3 dialects of Java. Takes a bit of wind out of the write once run anywhere sails. Thanks to an unknown SeaJUGer for the title of tonight's post

Another thing that I found interesting was that there was almost no mention of EJB 3, despite the fact that it's much simpler than EJB 2. Most of the time was spent talking about J2ME, JNDC and JDIC, Looking Glass, and generics. A few people lauded the benefits of JNDC -- apparently one of the panelists discovered that some of the JNDC components were Swing extensions that were written when members of the Swing team tried to actually write a Swing application. A few people spent portions of their reports talking about whether or not Sun was understanding the importance of developers, and on their perceptions of Sun's financial health.

Joe Bowbeer and I disagreed over the usefulness and openness of the JCP. Joe has had a good experience with the JCP, while I've mostly had indigestion over JSRs, and the long process of getting the JCP to be more open. It appears that some SeaJUG members have me pegged as Mr. Groovy, a title which should be reserved for James. I haven't actually been very involved with Groovy in the last few months. I haven't made up my mind over whether I'm going to participate in the JSR process, for a variety of reasons. One if them is that since the announcement of the JSR, I feel that there are more people pushing for Groovy to be more like Java, which (at least in my mind) defeats the purpose of having Groovy in the first place. Apparently, I'm not alone in my thinking -- this week eWeek published an interview with James Gosling in which he said

I think they could be a little more outlandish and get a little more interesting.

(thanks to Dion Almaer for the pointer to this - you'll have to read Dion to find the eWeek interview). I'm not really in the mood to fight with a whole bunch of people who have a different outlook on what Groovy ought to be, especially when it's starting to look like there are other people out there who have an outlook closer to mine (more on this another day).

As we got into the car to go over for our ritual after meeting beer and food, I turned to Wilhelm and said "this session made me glad that I'm not doing Java stuff at the moment". He responded that all the hue and cry over generics was reminiscent of the hue and cry when objects got introduced. We talked a bit more, and I said "if you're going to have static typing, then I want the computer to figure out what the types should be". I've done templates in C++ -- I used some of the template metaprogramming techniques that Barton and Nackman first showed. Of course, I'm not a fan of statically typed languages to begin with.

Java programmers are going to have a lot to swallow over the coming years. The good news for them is that C# isn't any better. C# already has annotations (attributes) and is about to add generics, so the two languages are remaining essentially equivalent. But as one person asked "what happened to making it easier"?

Dan Bricklin's latest article is titled Software That Lasts 200 Years, but "Societal Infrastructure Software" was the idea that really resonated with me.

I'm not sure that I agree with a 200 year horizon, especially for a field that is less than 50 years old. However, I think that many of the issues that he describes in the article are important and worth thinking about. Foremost among them is the notion that a certain classes of software are societal infrastructure. While he doesn't use the terminology explicitly, Bricklin, argues that these classes form a commons, and because they form a commons they ought to be conceptualized, designed, developed, and funded differently than other classes of software.

I haven't worked on the kind of software that he classifies as Societal Infrastructure Software, but I think that there is a class of software, call it Personal Infrastructure Software, which plays a similar role for individuals. At the moment, my personal description of that class includes RSS Aggregator, web browser, text editor, e-mail program, address book, calendar, and program development environment. I think that instantiations of these programs form a similar commons, and that we're seeing that come about in various degrees via open source implementations, but there are still issues that need to be deal with. Probably the most important one is data format lock in. Close behind it would be the staying power of the various communities working on various pieces of that commons.