[sakai2-tcc] Java 1.6 and Sakai 2.9

[Jean-Francois Leveque]

Are any of the 2.8 or later QA servers still running with Java 1.5 ?

If not, we should make 1.6 only binaries for 2.8 in order to avoid 
having to support a Java version we won't test with 2.8.

Cheers,

J-F

Matthew Jones a écrit :
> I agree too, and I was planning on sending this out, but now I can as a 
> followup.
> 
> As mentioned on the source install guide, "Oracle's Sun Java SE 6 
> <http://java.sun.com/javase/6/>, a.k.a Java 1.6, is the preferred 
> version to use with Sakai 2.7." [1] However there is still some 
> confusion about what this means. As we know Java 5 is nearly a year now 
> past the End of Life (11/09) and also harder to find for new people 
> looking for it.
> 
> Possible problems:
> 
> * The install guide mentions that Sakai 2.7+ is preferred to run under 
> Java 1.6, but maven still targets 1.5 for binaries. We are also still 
> (mostly) producing binaries that are compatible with 1.5. However as 
> recently evidenced on the list [2] some binaries are in 1.6 and this 
> causes some confusion.
> 
> * The workaround "-Dsun.lang.ClassLoader.allowArraySyntax=true" 
> (SAK-17578) is still required for many tools. From following this, it 
> seems that this is mostly because of the use of older jsf and other 
> libraries which could be very time consuming to upgrade. (SAK-19282). 
> 
> I agree with Seth that we should:
> 
> * Make the decision to switch the compilation for trunk (2.9) to 1.6. 
> Sakai after this version will no longer be guaranteed to be compatible 
> with JDK/JRE 1.5 and apis/methods/libraries specific to 1.6 could be 
> used if necessary. 
> 
> * Accept that we will be keeping this workaround flag along through this 
> release, possibly indefinitely for Sakai 2.x. This was something that 
> the project planning *wanted* to achieve [1], but doesn't seem 
> incredibly realistic. This is considering the effort involved in the 
> fixes and across all tool QA compared to the effort involved leaving in 
> the known workaround.  Steve Swinsburg has also recently marked SAK's 
> like SAK-17578 as "Won't Fix" with the comment which I agree with of:
> 
> /"//Marking this issue as Won't Fix as we do not have the resources to 
> fix this. The workaround of specifying the extra JAVA_OPTS is suitable."/
> 
> There are also a number of outstanding issues to upgrade to Tomcat 6 
> (SAK-8544, SAK-10720, SAK-17891) and even one for Tomcat 7 (SAK-187600 , 
> but I feel this is less of a critical issue than the JDK is immediately. 
> Something we should look at though.
> 
> [1] http://confluence.sakaiproject.org/display/DOC/Install+Guide+-+Source+Install+(2.7)
> 
> [2] http://collab.sakaiproject.org/pipermail/sakai-dev/2010-November/010013.html
> 
> [3] http://confluence.sakaiproject.org/display/MGT/Sakai+2x+Project+Planning+Goals
> 
> 
> On Wed, Nov 10, 2010 at 11:26 AM, Seth Theriault <slt at columbia.edu 
> <mailto:slt at columbia.edu>> wrote:
> 
>     Hello,
> 
>     The hybrid artifact Java version mismatch in trunk reminds me
>     that we probably need to deciede which version of Java we are
>     using going forward.
> 
>     For 2.7.1 and probably 2.8, we recommended 1.6, but left the
>     possibility of using 1.5 out there. I don't think we can maintain
>     this situation.
> 
>     What do people think about moving fully to 1.6 in trunk
>     (maintaining the workarounds)?
> 
>     Seth