Updating doesn't give us any advantages for the core framework, Java 5 is minimum version requirement and newer Java versions work as well. Or do you plan to refactor something which would depend on Java 6?
It is a different story for sandbox/addon projects, there we could make this decision
independent of the core framework. Anyway I wouldn't mind to switch to Java 6. It seems more interesting to update the eclipse version, since it ages quicker than Java, and there are some features here and there we cannot use in the Cas Editor or must use now deprecated APIs. Jörn On 11/16/11 9:45 PM, Tommaso Teofili wrote:
Hi all, looking at the roadmap towards 2.4.0 release of UIMA SDK I was wondering why not migrate to Java 6 and consequently drop Java 5 support. The 2.3.1 version is known to be stable enough to keep it as the last Java 5 enabled version in my opinion to allow backward compatibility. This way we may also open up to integrate easier with a number of other open source projects which adopt Java 6. Just as an example, some months ago I was working on the RDF CAS Consumer using Clerezza but then (my fault) I realized it was not possible to use it on Java 5 as Clerezza uses Java 6 however this alone wouldn't be a strong enough reason. Other much more important reasons, in my opinion, lie in bugs in Java 5 which have been fixed only in Java 6, see this one from Lucene as an example: https://issues.apache.org/jira/browse/LUCENE-3235 Consider also that some bugs have been resolved in minor versions of Java 6 so this wouldn't secure things 100% from previous bugs, but I think that doing a minor version upgrade (usually to at least 1.6.0_18) is trivial while changing major versions could be an issue with a big project. By the way, it seems Lucene 3.x is going to drop Java 5 support thus this would block any further update to Lucas/Solrcas (Lucene/Solr 3.4 still has Java 5 but 3.5/3.6+ will probably migrate to Java 6). What do you think? Tommaso
