> 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
> 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
http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html 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
> been alluding, having generics in APIs is limiting because you break
> binary compatibility if you change the types of a collection used
> an API. But that's the tradeoff of static typing: instead of
> a cast break at runtime, the client gets a compile error. In
> 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
> Bloch would update his "Effective Java" to outline best
> 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
> 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
> 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.