Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cross-project-issues-dev] Java 1.5

Mik Kersten wrote on 10/16/2006 07:51:09 PM:

> Jeff, that's a very useful guideline, and I think it would be good
> to put up on an EE guidelines wiki page if not there already.  But
> while keeping a minimal EE clearly makes sense, this raises a few questions.

> Q1: Can anyone offer specific guidance on the cost of not supporting
> 1.4 and below?  

> With Mylar there was the problem we noticed with the Linux distros,
> but that should be resolved before Europa (thanks for the reply
> Andrew).  The fact that Mylar users have not been complaining is one
> data point, but is limited because as with other pre-1.0 tools
> Mylar's user community is largely early adopters.

This will very much depend on the consumer community.  You point out one community for which the cost is zero.  There are others (e.g., eRCP, various RCP scenarios, ...) where the cost is infinite.   That is, they just don't have 1.4 (or any J2SE for that matter) so the point is entirely moot.

> Q2: What is the opinion of Jeff and other API gurus on the *benefit*
> of moving to Java 5, and is this something that Platform is planning
> at any point?  

I certainly don't qualify as an API guru.  Jeem, Boris B and John A are far better qualified to comment.  Actually Ed likely has felt the pain the most here...  I can however pretty much guarantee that "the platform" will never move en masse to require 1.5.  Check out the plugin list at the bottom of the 3.3 plan
It details each plugin and what EE it requires.  Note that most of the obviously RCP related plugins are based on Foundation 1.0.  There are no particular plans to change this and new plugins have to justify dependencies on Java 5 or 6.

Sidenote:  J2ME-based EEs are not just for embedded devices.  Lotus Sametime 7.5 is shipping today on a JRE that is a severely cutdown version of 1.4.

> The key benefit I've seen is with how generics improve APIs, both
> those that we’re creating and the JDK’s that we’re consuming.  For
> example, a client always knows what the types in a collection are,
> and pretty much the only time we see ClassCastException at runtime
> is when working with a non-generic API.  As I think Jeff might have
> been alluding, having generics in APIs is limiting because you break
> binary compatibility if you change the types of a collection used by
> an API.  But that's the tradeoff of static typing: instead of having
> a cast break at runtime, the client gets a compile error.  In my
> experience although the benefits of generics may seem subtle, they
> provide a substantial improvement to code quality and modularity,
> and have made our APIs safer and easier to use.  (I just wish that
> Bloch would update his "Effective Java" to outline best API
> practices with generics.)  

Yup.  There are likely benefits.  However, you have to weigh that against requiring 50MB more (for the JRE) in your product deliverable/runtime.  Its fine (perhaps) if you are doing tooling but remember you are doing components.  For example, you'd think that the CVS guys are doing the quintisential IDE thing, version management.  But the guy writing a standalone CVS client or somehow using CVS as a data store for his RCP app isn't doing tooling at all.  This is the wonderful part of Eclipse!

The point is simply that increasing the required EE has a cost.  Like all costs, you should decide if it is worth the benefit.

> Q3: In case other projects find themselves in a similar position and
> wanting generics-aware APIs, but can live without JDK1.5, has anyone
> evaluated using Retroweaver, or perhaps an extension to the jdt.core
> compiler, to create 1.4-compatible bytecodes?  

> We briefly evaluated Retroweaver a year ago and it appeared to work
> well enough, but chose not to use it due to the convenience of some
> JDK 1.5 libraries.  But depending on the answer to Q1 we may decide
> to forego the JDK 1.5 benefits if we can use something like
> Retroweaver to keep our APIs generics-aware.

Not sure.  JDT may already support this experimental mode of compiline 1.5 but outputting 1.4 compatible bytecodes.  That was the subject of a JSR at one point I think.  Its not clear if this is a scalable approach (i.e, what happens with Java 6?)  It might be worth investigating none the less.


Back to the top