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.
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?
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.)
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.
Mik
--
Mik Kersten, http://kerstens.org/mik
Mylar Project Lead,
http://eclipse.org/mylar
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff McAffer
Sent: Friday, October 06, 2006 3:46 AM
To: Cross project
issues
Subject: Re:
[cross-project-issues-dev] Java 1.5
<crank up the broken record player...>
Project
teams should consider very (very) carefully the implications of increasing the
level of their required execution environments. In particular, consider
what (dis)service you are doing for your consumers. In what way will
their lives or functionality be improved by the move? "Needlessly"
upping the required EE limits the scenarios in which your function can be used.
That may in turn limit its uptake and spread.
If
you find that upping the EE level makes sense, it would be good to then
consider method and techniques for provising degraded function on lower EEs. For
example, (and just as an example) you might introduce a 1.5 layer over the
1.4-based APIs or change the implementation to conditionally use 1.5
functionality.
Note
also that careful consideration should be paid to API evolution issues. If
you create API that uses 1.5 language features, you should familiarize yourself
with the implications and gotchas associated with these structures. I don't
remember the details but do recall that there were some subtleties around
generics that, unless handled well, could severly limit you in the future (or
break your users).
Finally,
also consider that it may be possible to limit the scope of this impact to a
particular set fo (hopefully higher level) plugins. As John pointed out in one of the replies, the platform
team is successfully targettting a wide ranges of EEs from Foundation 1.0 to
Java6 in its plugin set. PDE has first class support for this approach so
confusion and error should be virtually elimintaed.
All
of this is not to say that you should not use 1.5 etc but rather consider
including in your plans the goal of limiting dependencies as much as possible.
</spin
down and I'll fade away...>
Jeff
|
Doug Schaefer <DSchaefer@xxxxxxx>
Sent
by: cross-project-issues-dev-bounces@xxxxxxxxxxx
10/05/2006
04:13 PM
|
Please
respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
|
|
|
To
|
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
[cross-project-issues-dev] Java 1.5
|
|
Hey gang, I’m just wondering if any of the projects participating
in Europa are planning on dropping support for Java 1.4, i.e. are planning on
using Java 1.5 features.
Doug Schaefer
QNX
Software Systems
Eclipse CDT Project Lead
http://cdtdoug.blogspot.com
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
