> But, I really am not sure that if we move to a "new" VM platform, that it > makes sense to say the new minimum is 1.5, when so many things in 1.5 were > fixed/corrected/enhanced in 1.6.
Some specific questions I think we need to clear up: 1) should River use 1.5 language features? 2) should River use 1.5 specific APIs? Any limitations? 3) should River use (any) 1.6 specific APIs? 4) should River depend on any bug fixes present in 1.6 APIs for APIs which were already defined in 1.5? Concerning 1) it seems the consensus is yes with no limitations. The only language change in 1.6 that I'm aware of in 1.6 is that @Override can be applied to methods that implement an a method defined in an interface (thus signaling that the method in question must implement a method defined either in a superclass or a superinterface, or else won't compile). I suggest we can live without the @Override change for the time being. Concerning 2) the natural candidate is at least java.util.concurrent, but there are other interesting APIs (see http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html). The main issue with APIs is that without a backport available, the classes that depend on 1.4 won't be able to use those classes. I think we need to settle the 1.4 compatibility issue regarding APIs, and my vote is that we use 1.5 APIs without restrictions. If we remain compatible with Jini 2.1 for deployment and access of services (at the level of River infrastructure), we are covered. Concerning 3), I think it's better for the time being if River does not use 1.6-specific APIs, unless there are delicious candidates listed in http://java.sun.com/javase/6/webnotes/features.html (I don't know of any). Concerning 4), I think the reality of the current deployed base is that we will need to write and test against 1.5 JDKs and work around known bugs which were fixed in 1.6 and not backported. Regards Patrick
