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

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 Kersten,

Mylar Project Lead,


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...>


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>


Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>




[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
cross-project-issues-dev mailing list

Back to the top