[SAK-15874] Switch to Java 1.6 (Java 1.5 EOL 30-Oct-2009) Created: 18-Mar-2009  Updated: 14-Mar-2011  Resolved: 04-Feb-2010

Status: CLOSED
Project: Sakai
Component/s: Global
Affects Version/s: 2.8.0
Fix Version/s: None

Type: Task Priority: Blocker
Reporter: Peter A. Knoop Assignee: Unassigned
Resolution: Won't Fix Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
depends on SAK-13126 Remove file to allow compilation unde... CLOSED
is duplicated by SAK-17578 Compiling with Java 1.6 breaks tools ... CLOSED
relates to SAK-10716 Switch to Java 1.6 for Sakai 2.6.0 CLOSED
relates to SAK-16741 Search unit tests fail when built wit... CLOSED
is related to SAK-15562 Upgrades/Additions Under Consideratio... CLOSED
is related to SAK-17938 Switch to Java 1.6 (Without any worka... CLOSED


Java 1.5 is approaching its End-of-Life (EOL), which is scheduled for 30-Oct-2009:



For Sakai 2.5 and Sakai 2.6 (which currently is being QA'ed for release with Java 1.5) this means a switch to Java 1.6 at some point during their maintenance cycle.

For Sakai 2.7, which is tentatively scheduled for code freeze in late 2009, this means we should start thinking about switching development of trunk/2.7 to using Java 1.6, and when it enters QA, it will be QA'ed with Java 1.6.

For Sakai 3.0, which is still early in development, this likely also means a switch in development and QA to Java 1.6 at some point soon.

Comment by Mustansar Mehmood [ 09-Apr-2009 ]

JAVA_OPT -Dsun.lang.ClassLoader.allowArraySyntax=true seems to solve this problem pretty decently

Comment by David Horwitz [ 10-Apr-2009 ]

Search (2-6-x) currently seems to fail to build with java 6:

[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure

/usr/local/src/vula_2-6-x/sakai2/search/search-impl/impl/src/test/org/sakaiproject/search/indexer/impl/test/TDataSource.java:[98,2] <anonymous org.sakaiproject.search.indexer.impl.test.TDataSource$1> is not abstract and does not override abstract method isWrapperFor(java.lang.Class<?>) in java.sql.Wrapper

/usr/local/src/vula_2-6-x/sakai2/search/search-impl/impl/src/test/org/sakaiproject/search/indexer/impl/test/TDataSource.java:[109,4] <anonymous org.sakaiproject.search.indexer.impl.test.TDataSource$1$1> is not abstract and does not override abstract method createStruct(java.lang.String,java.lang.Object[]) in java.sql.Connection

/usr/local/src/vula_2-6-x/sakai2/search/search-impl/impl/src/test/org/sakaiproject/search/index/soaktest/SharedTestDataSource.java:[120,2] <anonymous org.sakaiproject.search.index.soaktest.SharedTestDataSource$1> is not abstract and does not override abstract method isWrapperFor(java.lang.Class<?>) in java.sql.Wrapper

/usr/local/src/vula_2-6-x/sakai2/search/search-impl/impl/src/test/org/sakaiproject/search/index/soaktest/SharedTestDataSource.java:[142,4] <anonymous org.sakaiproject.search.index.soaktest.SharedTestDataSource$1$1> is not abstract and does not override abstract method createStruct(java.lang.String,java.lang.Object[]) in java.sql.Connection

Comment by Mustansar Mehmood [ 14-Apr-2009 ]

This is "probably" due to JDBC 4.0 in Java 6. Some methods need to be overridden due to JDBC changes. I would compile with this option
Note: Overriding those methods(assuming they don't do any thing except fulfilling the OOD needs) using eclipse should be a few clicks away for those interested in fixing this.
Preffered -Dmaven.test.skip=true
OR add this line in ~/.m2/settings.xml
compling search with no tests enabled works fine rest of the sakai doesn't complain.

Comment by Dominic Hargreaves (Inactive) [ 27-Oct-2009 ]


30th October 2009 is nearly upon us. Are there any updated plans for this task?


Comment by Steve Swinsburg [ 27-Oct-2009 ]

One of the big issues seems to be with JSF based tools:

Do we need to wait for this to be fixed in the JSF library itself?

Comment by Matthew Buckett [ 27-Oct-2009 ]

As Steve mentions JSF 1.1 libs need fixing.

Options for the JSF tools seem to be:

  • Run with -Dsun.lang.ClassLoader.allowArraySyntax=true passed to the JVM. Even if we document this it will catch new users out. It might help if we check for 1.6 and if this option isn't set log an error message, but even this isn't ideal.
  • Wait for an official fix to the 1.1 JSF libs. I think this is unlikely to happen officially, looking how long this bug has existed.
  • Upgrade to never JSF which doesn't have the bug. I don't think this is trivial as attempts have been made in the past to migrate and there are quite a few tools that use JSF.
  • Fix JSF 1.1 ourselves and deploy custom version to our maven repo, then update tools to use this fixed version. License issues?
Comment by Matthew Buckett [ 27-Oct-2009 ]

Search tests should work on 1.6 now.

Comment by Steve Swinsburg [ 27-Oct-2009 ]

I think option 3, upgrade to a newer JSF (1.2) is the ideal solution (assuming this bug isn't in that version). What were the issues with upgrading JSF based tools?

Comment by Matthew Buckett [ 27-Oct-2009 ]

SAK-8932 Andrew Polland tried to compile message center against 1.2 and it didn't work out the box.

Comment by Seth Theriault [ 04-Nov-2009 ]

Final 1.5 JDK public release is 1.5.0_22:

"J2SE 5.0 reached its End of Service Life (EOSL) on November 3, 2009, which is the date of the final publicly available update of version 5.0 (J2SE 5.0 Update 22)."

Comment by David Haines [ 18-Nov-2009 ]

Perhaps we should break this into 2 tasks. The first would be to switch over to using the Java 1.6 SDK and JVM with 1.5 source and target settings. This avoids relying on critical yet unsupported software to run Sakai. The second would be to move to using Java 1.6 features and targetting the 1.6 JVM. The first task can be accomplished with few changes. The second can then be accomplished more gradually.

Comment by Steve Swinsburg [ 18-Nov-2009 ]

I've been using JDK 1.6 for about a year now. No issues. Startup includes -Dsun.lang.ClassLoader.allowArraySyntax=true. However if we want to really fix this the JSF tools will need work (preferably a JSF upgrade so we don't need to maintain a workaround). Can we contact the project leads for those tools to get their input and estimated work required?

Comment by Jean-François Lévêque [ 19-Nov-2009 ]

Which are those JSF tools?

Comment by Steve Swinsburg [ 19-Nov-2009 ]

Any tools using JSF 1.1. The bug exists there so upgrading should solve, but will need work.

Comment by Jean-François Lévêque [ 19-Nov-2009 ]

As far as I can check, it seems the following are using JSF (grep "^import javax.faces", haven't checked Maven dependencies for anything else than versions)
chat (1.1.01), reports (1.1.01), osp (1.1.01), gradebook , syllabus , podcasts , samples (1.1.01), user (1.1.01), usermembership , msgcntr , tool (1.1.01), mailtool (1.1.01), roster , sections , sam (1.1.01), profile , jsf (1.1.01), postem , blog (1.1.01)

some get the deps for sjf poms others define them themselves

msgcntr, sam, jsf have independent releases for 2.7. Maybe they are good candidates.

This is a large chunk of Sakai. I can't imagine this being solved for Sakai 2.7 and I wonder if it could be done for Sakai 2.8.

I hope all those parts of the code are currently maintained.

Comment by George Pipkin [ 07-Dec-2009 ]

I have tried compiling 2.5.x with Java 1.6 and I ran into the JJDBC error as well:

[INFO] Compilation failure
/Volumes/MacExt_SAK-1367/sakai/trunk/sam/samigo-services/src/java/org/sakaiproject/spring/DataSourceWrapperAutoCommit.java:[36,7] org.sakaiproject.spring.DataSourceWrapperAutoCommit is not abstract and does not override abstract method isWrapperFor(java.lang.Class<?>) in java.sql.Wrapper

This happened AFTER changing the settings.xml file to include the line:

  • George Pipkin
Comment by Seth Theriault [ 07-Dec-2009 ]

The description of this bug probably needs to be updated to exclude 2.5 and 2.6 from Java 1.6 consideration. These releases are out the door and I think it is unlikely they will be modified further for 1.6 compatibility.

Comment by David Horwitz [ 23-Jan-2010 ]

Maintenance team review: If this issue is being worked on please take ownership of it by assigning it to yourself. Otherwise it is likely to be closed as an abandoned issue. If this is not being pursued please close the issue.

Comment by Jean-François Lévêque [ 25-Jan-2010 ]

I thought this issue was still a community goal.

Comment by Alan Berg [ 04-Feb-2010 ]

Closed as per request of Release managemenet meeting to be reopened for affect version 2.8. Currently two options set in JAVA_OPTS to allow running under Java 1.6

Generated at Tue Feb 18 22:55:42 CST 2020 using Jira 8.0.3#800011-sha1:073e8b433c2c0e389c609c14a045ffa7abaca10d.