JavaOne 2004: Final Thoughts

JavaOne 2004 FinalThoughts

 

Before you read my summary, I encourage you to read the daily posts I wrote. The comments on those posts can be very illuminating as well.

 

Day 1

Day 2

Day 3

Day 4

 

Summary:

 

Community

 

The biggest different between conferences like TechEd and PDC and JavaOne is level of community involvement. The Microsoft conferences have come a long way from where we were even a few years ago, but our conferences are more about explanation, and JavaOne is more about collaboration. While we do spend lots of time looking at what customers are asking for and incorporating it into our products, the JSR process gives a feeling of working together that our approach lacks. Or, to put it another way, our approach is “Get feedback, design, get feedback”, while the JSR approach is “design as a group”. I suspect that there’s a lot of customer wilingness to be more involved in our design process. MSDN Feedback is a start on this road, but there’s lot of opportunity for us to be closer to customers.

 

I’m also impressed at the speed at which JSRs progress and how they’re decoupled from main releases of the product. There’s an opportunity to design/code/release in several iterations rather than in one big release that we aren’t currently utilizing (though we have discussed doing this in the past).

 

I also like the fact that many of the community efforts are highlighted in the conference.

 

Java Language

 

The “Tiger” release of Java (was 1.5, now named 5.0) provides some interesting additions to the language, but after looking at the features in more detail and sampling the public reaction, I’m not convinced in the overall success of their additions.

 

  • Generics are useful, but the reference type limitation is unfortunate. Wildcards add a lot of complexity, and it's not clear if the benefit is worth it.

  • Annotations support design-time code injection (through a separate tool), which I a powerful capability, but the combinatorics of multiple processors operating on the same source is challenging, as is debugging the resulting code. I think the “your source is modified” model is tougher to get your mind around than an API-based approach.

  • Enums have more capability than you really need.

  • Static imports are of some utility, but may challenge readability

     

The combination of static import and design-time annotations is going to cause some issues around code readability and understandability. On the other hand, given the amount of boilerplate code required for J2EE approaches (changing with EJB 3.0, I understand), I can understand the desire to simplify things.

 

Yesterday I found out that noted Java architect and author Joshua Bloch has left Sun to go to Google.

 

Groovy Language

 

I forgot to write up my thoughts about the session that I attended on Groovy.

 

Groovy is a new scripting language (well, they call it an “agile dynamic language“, but I prefer the term scripting) for the Java platform. I attended this with some interest as I've written a lot of Perl, and I understand the value of such languages.

 

However, as a semi-professional language designer, I'm not sure about groovy. Their goal is to be Java-like, but they've also added a lot of “improvements“ that result in Groovy being a weird cross between a simple scripting language and a high-powered research language. For example, closures and operator overloading are not things that one would expect in a simple language.

 

I didn't see a lot of evidence of rigor in the language design. That may be okay for the target audience, but I think it may lead to a confusing set of features and weird interactions.

 

Java IDEs

 

Several features in the Java world make it hard to write IDEs.

 

The fact that IDE development isn’t coupled to API development causes a lot of problems. I’m not an expert on Java development, but the fact that there were lots of demos of laying out forms and hooking them up leads me to believe that such features aren’t as expected in the Java IDE world as they are in VS. The fact that the ASP.NET team owns the whole stack from design-time to runtime gives a much more coherant experience.

 

I also think that the sheer number of Java IDEs means that Java developers either need to learn more than one IDE (and deal with the difference in approach), or go without in some areas.

 

Many of the features demoed are either derivative of VS, or direct copies of VS.

 

Eclipse is an interesting wild-card in this area. Because users often use a collection of modules that aren’t necessarily written to work together, consistency can suffer. On the other hand, the low-level extendability is far better than what we have in VS, and the fact that you can deal with your code at the AST level is a very powerful capability that isn’t available in Visual Studio.

 

Aspect Oriented Programming

 

I attended several sessions on AOP. It’s still a fairly divisive topic – there are definitely powerful capabilities available in AOP, but my opinion is that the long-term maintainability of code with AOP is likely to be poor, especially as more than one aspect is involved. Similar to design-time annotations, code using AOP does more than it says it does.

 

Device-Contained UIs

 

The Jini (link) concept of keeping device UI code on a network-accessible device is tremendously powerful, if it can be done in a secure manner. It’s a great way to avoid having to install separate software to talk to a device. The success will depend on whether we end up with the wholly connected world that some people envision.

 

 

Misc

 

There was a big “Java Timeline” display that ran 50 or so feet in the tunnel between Moscone South and North. There was space and markers for people to write their own comments on the timeline, and by the end of the conference, there was little free space. It was a cool thing to do, and would be especially cool if it ended up online so others could look at it.

 

Sun played a fair number of games during their demos - “Utilizing Java Technology” is a favorite phrase that was used a lot, but without any clarification as to how much technology was being used.