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






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.





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.

Comments (18)
  1. Groovy: I think your take on that is right. I’ve looked into it a bit, and it seems very hodge-podge, like someone just said, "Hey, that’d be cool, and I bet we could do it" without thinking about a larger picture. Of course, that’s also a good description of Perl (which also has closures), and Perl’s been reasonably successful — but Perl has Larry Wall, who’s a legitimate tech-genius.

    There’s a real need for a light-syntax, low-overhead language for the JVM. And since Jython is a bit too burdened by back-compatibility to Python and Scala is more than a bit academically-oriented, Groovy may be successful anyway; but on its own merits, enh.

    IDEs: It’s definitely true in my experience that IDEs are way, way less prevalent/standardized in Java than they are in .NET. I happen to think this is a good thing as it forces people to understand what’s really going on, instead of just doing the clicky-thing bit (and I like to believe that I’m a better .NET developer for having done my first ASP.Net project with Emacs, Nant, and the SDK), but it’s definitely less novice-friendly. Still, I think the latest version of NetBeans looks reasonably welcoming. And the plus side of that diversity is that if someone comes up with a good idea (like, oh, refactoring support), you don’t need to wait for the single monolithic IDE vendor to eventually get around to adding it…

  2. FL says:

    IDE’s are standardized in .NET becuase for all intents and purposes, there’s only one. 😉

    My biggest issue with Java IDE’s is that, for some reason, they are written entirely in Java. I could see the reasoning behind that, but since most developers in the corporate world develop on Wintel boxes, why not just leave the egos behind and write in c/c++ mfc?

    Just a rant. 😉

  3. Kannan Goundan says:

    I’ve only read about Groovy on their website, but I’m impressed. It seems like a good adaptation of a Ruby-style language to the Java runtime. Also, operator overloading and closures are perfect for scripting languages.

    I’m pretty sure Perl has some form of closures. The Groovy syntax seems to derive partly from Ruby’s syntax. Closures also let you do functional-programming-like stuff, which is often much more concise and readable than can be done without closures (notice how it’s a pain to use the STL’s for_each and find_if without lambdas?). You should take a look at Ruby’s great block syntax for another example of just how much more can be done with closures. (I wish C# had a lighter-weight way of creating an anonymous function. Something like "#(params) {code}" or "#{code}" would have made it convenient to use them more often.

    Overloading is used pervasively in the Python and Ruby libraries. The [] operator is especially useful.

    You say that closures and op overloading do not belong in a "simple" language and you could be right, though I’m not sure "simple", by itself, should be a design goal. For example, the lambda calculus and BF ( are very simple languages but are definitely not convenient for everyday programming. The creator of Ruby has some slides about using "the principle of least surprise" as a design goal when developing a programming language. That term, I believe, more accurately captures what you had in mind (

    The other thing Groovy has is some syntatic support for XML. While I think XML is pretty much total crap, Groovy has some synactic support for it, resulting in very clean code. It lets you create structures in a declarative manner (

    As a side note, I think that "dynamically typed language" is a more appropriate term. The term "scripting language", to me, implies a language that is used to glue together external objects (like in a videogame scripting language or shell scripting language).

    While Perl/Python/Ruby/Groovy may have features that make them convenient for scripting, they are also powerful enough to write full-fledged programs in.

  4. 101 says:

    AOP: I’m using AspectJ and it _greatly_ reduced the code size… ant it results in better maintainability.

    Of course it requires more brain, but I always have problems with the expressibility of mainstream languages. And AOP helps a litte in that.

  5. Joe Cheng says:

    Great post, thanks for the insights. I’ve found comparing the generics and annotation facilities in C# and Java fascinating; it’s nice to hear a C# authority voice his opinion on these subjects.

    Almost all the programming I do these days is C#, but whenever I get the chance to knock out a Ruby script or two, it’s an absolute pleasure. Groovy feels a lot like Ruby, with a superficially more familiar syntax. And Ruby would simply not be Ruby without closures. Personally I think closures will really help people build more natural abstractions for the kinds of tasks Groovy is likely to be used for (e.g. build scripts, unit tests).

    I’m not sure what other Java IDEs you are talking about, but IntelliJ IDEA is way WAY ahead of VS.NET as far as code editing is concerned, and has been for years. Although they are coming out with the VS.NET add-in Resharper, which narrows the gap significantly.

  6. Cameron says:

    I can’t believe you came to JavaOne and didn’t stop by to say hi .. glad you enjoyed it .. see if you can send me a pass for the next .NET show and I’ll return the favor 😉

  7. gab says:

    about groovy, I think you’re not looking at it in the right sense: if you look at it as a "scripting language" as "dsome kind of shell script or batch file" it is not good.

    If you think of "scripting as an attitude" (quoting matz and ward cunningham) it is ok: it empowers the user allowing him to get quick results with small code, not necessarily perfect or super efficient.

    The so called "scripting languages" in this days (Groovy,Io, Ruby, pnuts, Python) include lots of powerful features like closures,coroutines or continuation handling, this is the reason they’re getting hype over ‘classical’ scripting languages (beanshell is a good example in javaland): developers want power, not just lack of static typing.

  8. Geoff says:

    I think most people who do not get AOP make the same assumption that it is going to be more difficult to debug. But one of the major plus factors of AOP is to remove lots of redundant code in order to simply the classes and methods and then add totally standardised code to that. This will simplify debugging not complicate it.

  9. John Rusk says:

    >our approach is “Get feedback, design, get feedback”, while the JSR approach is “design as a group”.

    I hope you don’t swing the pendulum too far towards the "design as a group" thing. I don’t know about large scale projects like language design, but on typical IT projects there are some benefits to having a small number of people do most of the thinking. (Fred Brooks said it better than I can in "The Mythical Man Month".) The important thing is that the small "core" group gets plenty of feedback from the wider community.

    There’s definitely a balance that should be struck between the two extremes. Personally, I think you guys on the C# team are already doing fairly well. While there are one or two "extras" I’d like to see added to the language, I appreciate your efforts to retain consistency and simplicity as the language evolves, and I hope those principles are never diluted by "design as a group".

  10. Christopher Bartling says:

    I will second Joe Cheng’s resounding note about JetBrains IntelliJ. I program in both Java and C#, and I’m always happiest in IntelliJ. It is truly an "intelligent" IDE, and it does have a decent forms painter, if that’s what does it for you. The refactoring support and editing tools (intentions, live templates) are simply awesome. If you program in VS.NET 2003, you can try Jetbrains Resharper VS.NET addin, but it’s very shallow in its support of the complete IntelliJ feature set (though it’s not even a 1.0 product yet). Hopefully MS is watching the "entire" Java landscape and taking note of the products that are really good and are successful in that area. Such observation would only improve on the .NET experience.


    — chris —

  11. MBA says:

    Helpful For MBA Fans.

Comments are closed.

Skip to main content