Ok, but that shouldn't require UIMA itself to move the Java 6.  I can see a
particular Add-on that, in turn, depends on a Java 6 library (not UIMA), would
then require the application to be run with Java 6; that could be "documented"
in the add-on, and the add-on, could, in fact, just spit out a little error
message if it was run with Java 5.

Thanks for clarifying.

-Marshall

On 11/16/2011 4:56 PM, Jörn Kottmann wrote:
> On 11/16/11 10:50 PM, Marshall Schor wrote:
>>> 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).
>> Again, I don't know why we couldn't continue to upgrade Lucas, even if was 
>> Java
>> 5 compatible.  Wouldn't it run just fine under Java 6?
>>
>
> The point is when you want to write an addon component which depends
> on a Java 6 only library it will not work with Java 5.
>
> Therefore you need to require at least Java 6 for this addon component.
> This issue might get worse over time when more and more projects decide
> to update to Java 6.
>
> Jörn
>

Reply via email to