J1 Day 4: Gosling Keynote, Open Sourcing Java Panel, Summary

Discussions

News: J1 Day 4: Gosling Keynote, Open Sourcing Java Panel, Summary

  1. Day 4 coverage looks at some of the cool demos given during James Gosling's keynote and delves into a panel discussion on issues surrounding a more open development model for Java. On the Pavilion, Ted Farrell talked about various JSRs Oracle is driving for IDE plugin standards. Some perspectives are offered up on this year's event, which seemed much more well attended than last year's.

    Read JavaOne 2004 Coverage: Day 4

    Threaded Messages (4)

  2. J2SE 5.0, release date?[ Go to top ]

    Did Sun announce a release date for J2SE 5.0?

    Did HP announce a release date for J2SE 5.0 on HP-UX?

    Did IBM announce a release date for J2SE 5.0 on AIX?
  3. Release Date[ Go to top ]

    No, but BEA did for JRockit. :)
  4. So was J1 any good this year?[ Go to top ]

    After last years J1 which received a lot of bashing about how down hill it had gone I was wondering if these years event was any better?

    There has definately been less negative comments (or comments in general) this year so did Sun get the message? I must admit I was one of the people that after 6 years of attendence decided after last year SunOne mess it was time to move on and try out things like the symposium and nofluffjuststuff.

    David
  5. Interesting commentary[ Go to top ]

    I found this commentary to be a bit interesting:
    We at TheServerside.com are still a little concerned, as the challenge of building a universal API for plugins that can integrate into any IDE is enormously complex, and we're not convinced that JSR 198 can deliver. In many ways, the plugin API must be strongly coupled to the design of the IDE itself. Thus, betting on JSR 198 as a way to compete with the Eclipse's plugin ecosystem seems iffy.
    What is your basis for this analysis? At Compuware, we build plugins for OptimalJ into all the major IDEs (Eclipse, IntelliJ, NetBeans, JBuilder, WSAD), and we find the opposite to be true. In fact, we couldn't feasibly build all those plugins if it were as "enormously complex" as you suggest. The complexity, we find, is when we have to do the same thing in different IDEs, and there are similar but slightly different APIs. This problem would be solved with the JSR that Ted is describing.

    To us at Compuware, this JSR is not as much as enabling IDE vendors to compete with Eclipse as it is giving plugin vendors the widest possible audience for their value-added offerings. This should provide the Java community with a rich set of IDEs and plugins that can be mixed and matched to meet the needs of each organization. Openness fosters competition, competition fosters innovation, and that is nearly always good for the consumer.

    Mike Burba
    Compuware OptimalJ