[Building Sakai] Java 1.6 for Sakai 2.7

Mon Oct 12 10:25:55 PDT 2009

I agree.  The point would not be to orphan users of 1.5, just to allow  
people to use 1.6.  Moving Sakai to depend on using features  
incompatible with 1.5 is a different decision.

- Dave

David Haines
CTools Developer
Digital Media Commons
University of Michigan
dlhaines at umich.edu

On Oct 12, 2009, at 12:33 PM, Aaron Zeckoski wrote:

> It may be worth considering making the code java 6 COMPATIBLE rather
> than starting to use java 6 only features. In other words, maintain
> the ability to build and run in java 5. This would keep things from
> breaking when building and running in java 6 (which would be great)
> but would still support those who need to run in a java 5 environment.
>
> I think you will find many shops simply cannot or will not upgrade to
> java 6 yet and switching Sakai to it means they are stuck on the older
> version. Just a thought.
>
> -AZ
>
>
> On Mon, Oct 12, 2009 at 5:10 PM, David Haines <dlhaines at umich.edu>  
> wrote:
>> Based on this and other comments I suggest that completely moving
>> Sakai to Java 1.6 is actually 3 projects:
>>
>> 1) Get all the code to compile, run tests, and run without  
>> regressions
>> with the 1.6 compiler.
>> 2) Modify the code to avoid the 1.5 compatibility hacks.
>> 3) Resolve the 1.6 JVM gc issues.
>>
>> Only the first needs to be done by the 2.7 code freeze deadline.  The
>> second is a good idea, but not critical.  The third is mostly likely
>> to be done by individual schools tuning for their own environments  
>> and
>> then sharing the results.
>>
>> Unless someone has a better idea, I'll update Jira to reflect this
>> split.
>>
>> - Dave
>>
>> David Haines
>> CTools Developer
>> Digital Media Commons
>> University of Michigan
>> dlhaines at umich.edu
>>
>>
>>
>>
>> On Oct 9, 2009, at 10:39 AM, Charles Hedrick wrote:
>>
>>> Actually I'm going to issue a service request with Sun, but our
>>> support contract was inadvertently changed to a level where I can't
>>> report problems. We're working on it with Sun.
>>>
>>> There are lots of reports of GC issues with Java, some that look the
>>> same, but it's always a bit unclear what is causing them. If you
>>> look at release notes you'll see many patches involving the GC. It's
>>> quite likely that there are multiple issues resulting in similar
>>> symptoms.
>>>
>>> This could well be an interaction between Java and Solaris, so you
>>> might not see it. One question is whether you look for it. I have a
>>> system status page that reports all kind of operational numbers. One
>>> of them is the last 3 GC's that took longer than 10 sec. (I get that
>>> by using a program that effectively tails catalina.out and watches
>>> matching reporting the amount of time applications were stopped, but
>>> can cope with the file changing when we do a new deploy.)
>>>
>>>
>>> On Oct 9, 2009, at 10:23 AM, Noah Botimer wrote:
>>>
>>>> Do we have any contacts with outside experts with expertise on
>>>> really big JVMs with a lot of churn? There have to be some other
>>>> apps that have run into this or some insight into what we could  
>>>> fix.
>>>>
>>>> Thanks,
>>>> -Noah
>>>>
>>>> On Oct 9, 2009, at 9:52 AM, Charles Hedrick wrote:
>>>>
>>>>> I'd like to note that we're just about finished moving our systems
>>>>> from Java 6 back to Java 5. I'll update the list next week on the
>>>>> details, because until we've survive Monday I won't be certain
>>>>> that we've solved our problem. But the reason for the change is
>>>>> performance problems with the Java 6 GC that we think aren't
>>>>> present in Java 5. I'm very skeptical that these will be fixed, so
>>>>> I'm currently expecting that we'll need to stay with Java 5 until
>>>>> GC1 is ready for production (which it currently is not -- I've
>>>>> tried it).
>>>>>
>>>>> On Oct 8, 2009, at 5:26 PM, Seth Theriault wrote:
>>>>>
>>>>>> Seth Theriault wrote:
>>>>>>
>>>>>>> I just tried to build again with an updated trunk, but it failed
>>>>>>> due to a repeated method in the Rwiki code. I'll be sending a
>>>>>>> separate e-mail about that.
>>>>>>
>>>>>> Just finished up some local testing using trunk, r67389, on a Mac
>>>>>> OS X Leopard system:
>>>>>>
>>>>>> $ uname -a
>>>>>> Darwin mirth.cc.columbia.edu 9.8.0 Darwin Kernel Version 9.8.0:
>>>>>> Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386
>>>>>> i386
>>>>>> $ echo $JAVA_HOME
>>>>>> /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home
>>>>>> $ $JAVA_HOME/bin/java -version
>>>>>> java version "1.6.0_15"
>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226)
>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode)
>>>>>>
>>>>>> Using the default pack-demo target, the build was without
>>>>>> incident. Of course, the default uses "-Dmaven.test.skip=true" so
>>>>>> I turned that off (and "-Dmaven.test.failure.ignore=true" too)
>>>>>> and rebuilt.
>>>>>>
>>>>>> With the tests on, none of them fails but one of them returns
>>>>>> JDBCerrors:
>>>>>>
>>>>>> [exec] [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>> [exec] [INFO] Building coursemanagement-hibernate-impl
>>>>>> [exec] [INFO]    task-segment: [clean, install, sakai:deploy]
>>>>>> [exec] [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>> ...
>>>>>> [exec] Running
>>>>>> org
>>>>>> .sakaiproject
>>>>>> .coursemanagement.test.CourseManagementAdministrationTest
>>>>>> [exec] 16:48:58,732  WARN JDBCExceptionReporter:77 - SQL Error:
>>>>>> -104, SQLState: 23000
>>>>>>
>>>>>> I'll note here that this test is imperfect because search is
>>>>>> being downloaded as an "assembly" like kernel.
>>>>>>
>>>>>> With the sakai-demo package built, I was able to start it up.
>>>>>> Initially, there are errors in blogger, chat, and samigo:
>>>>>>
>>>>>> $ grep ERROR logs/catalina.out
>>>>>> 2009-10-08 16:31:02,974 ERROR main
>>>>>> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/
>>>>>> sakai-blogger-tool]
>>>>>> - Exception sending context initialized event to listener
>>>>>> instance of class com.sun.faces.config.ConfigureListener
>>>>>> 2009-10-08 16:31:02,977 ERROR main
>>>>>> org.apache.catalina.core.StandardContext - Error listenerStart
>>>>>> 2009-10-08 16:31:02,977 ERROR main
>>>>>> org.apache.catalina.core.StandardContext - Context
>>>>>> [/sakai-blogger-tool] startup failed due to previous errors
>>>>>> 2009-10-08 16:31:04,518 ERROR main
>>>>>> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/
>>>>>> sakai-chat-tool]
>>>>>> - Exception sending context initialized event to listener
>>>>>> instance of class com.sun.faces.config.ConfigureListener
>>>>>> 2009-10-08 16:31:04,522 ERROR main
>>>>>> org.apache.catalina.core.StandardContext - Error listenerStart
>>>>>> 2009-10-08 16:31:04,522 ERROR main
>>>>>> org.apache.catalina.core.StandardContext - Context
>>>>>> [/sakai-chat-tool] startup failed due to previous errors
>>>>>> 2009-10-08 16:31:37,888 ERROR main
>>>>>> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/
>>>>>> samigo]
>>>>>> - Exception sending context initialized event to listener
>>>>>> instance of class com.sun.faces.config.ConfigureListener
>>>>>> 2009-10-08 16:31:39,136 ERROR main
>>>>>> org.apache.catalina.core.StandardContext - Error listenerStart
>>>>>> 2009-10-08 16:31:39,136 ERROR main
>>>>>> org.apache.catalina.core.StandardContext - Context [/samigo]
>>>>>> startup failed due to previous errors
>>>>>>
>>>>>> but these clear up nicely if you add the
>>>>>> "-Dsun.lang.ClassLoader.allowArraySyntax=true" to the JAVA_OPTS
>>>>>> as Matt suggested.
>>>>>>
>>>>>> Seth
>>>>>>
>>>>>> _______________________________________________
>>>>>> sakai-dev mailing list
>>>>>> sakai-dev at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>>
>>>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>>>>>>  with a subject of "unsubscribe"
>>>>>
>>>>> _______________________________________________
>>>>> sakai-dev mailing list
>>>>> sakai-dev at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>
>>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>>>>>  with a subject of "unsubscribe"
>>>>
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>>>  with a subject of "unsubscribe"
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>>  with a subject of "unsubscribe"
>>
>
>
>
> -- 
> Aaron Zeckoski (azeckoski (at) vt.edu)
> Senior Research Engineer - CARET - University of Cambridge
> https://twitter.com/azeckoski - http://www.linkedin.com/in/azeckoski
> http://aaronz-sakai.blogspot.com/ - http://tinyurl.com/azprofile
>
>