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


Generics do help in specifying APIs involving collections, and other new features such as enums and covariant return types are also potentially helpful in creating more descriptive APIs contracts.  However, the reality is that Java 5 is a far more complex language than Java 1.4, thus API specification and evolution becomes trickier. I.e., there's a lot more rope available in Java 5, but whether you use the rope to build better APIs or hang yourself is largely up to you ;)

We have begun some discussions within the platform about the API implications of new language features such as generics, annotations, enum types, variable arity methods, covariant return types, etc. The output of this process will be updating the API evolution guidelines, recently wikified at:

http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs

Here is a bug report tracking the effort:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=149805

I encourage everyone interested in the subject to follow along and help iterate the guidelines with us. I have also created this discussion page on the wiki for capturing notes, discussions, and experiences on API specification in Java 5.  The page is currently blank, but I'll extend the usual wiki welcome for anyone to jump in and add material there:

http://wiki.eclipse.org/index.php/Notes_on_Evolving_APIs_in_Java_5

John



"Mik Kersten" <beatmik@xxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

16/10/2006 07:51 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To
"'Cross project issues'" <cross-project-issues-dev@xxxxxxxxxxx>
cc
"'Mylar developer discussions'" <mylar-dev@xxxxxxxxxxx>
Subject
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
 
--
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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top