[Building Sakai] Java 1.6 for Sakai 2.7

Mon Oct 12 09:33:28 PDT 2009

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