[Live-demo] Where should JAVA_HOME be set (if overriding default=openjdk 1.7)?

[Cameron Shorter]

So to cover all scenarios we want to test, I suggest we do the following:

JAVA_HOME defaults to SunJava globally, then:

Case 1: Project has confirmed application runs in OpenJDK.
* Application's start script sets JAVA_HOME=OpenJDK
* We test app with OpenJDK

Case 2: Project hasn't confirmed application runs in OpenJDK, or says 
only runs in SunJava
* Application doesn't set JAVA_HOME, so it defaults to SunJava
* Test 1: with SunJava
* User can then change JAVA_HOME to OpenJDK, then rerun the application 
start script
* Test 2: with OpenJDK
* Verify OpenJDK is running by running "ps aux | grep java" or similar


On 17/01/2012 12:36 AM, edgar.soldin at web.de wrote:
> On 16.01.2012 04:55, Hamish wrote:
>> Hamish wrote:
>>> a systemwide exchange of all java components should be done
>>> properly, true. simply i tried never to achieve that and
>>> although bruno reis gives a good introduction later i
>>> definitely think that would be wasted effort.
>> if our needs are simply to swap it out during beta-testing
>> then we don't really need to also swap out the man pages and
>> ancillary stuff, just the JVM binary, so I'd guess much of
>> Bruno's long list could be ignored and it collapses to:
>>
>> sudo update-alternatives --set java /usr/lib/jvm/java-7-sun/jre/bin/java
>>
>> or something like that.
> should be worth a try. we might stumble over complications like mentioned in comments below on that page, but supposedly this would be the proper way. but again, if we run into issues with browser components or such i really say why bother. simply exchanging the binary link does it (at least for testing images).
>
>>>> run-time scripts (as opposed to build-time scripts)
>>>> should go into gisvm/trunk/app-conf/java/ and
>>>> be copied into /usr/local/bin/ by the bin/install_*
>>>> script.
>>> could do so, if you want to. i feel some rejection on your
>>> part, which i can definitely understand.
>> just a personal opinion, explore the task or not as you enjoy.
>> The only caveat is if things aren't working 100% by release-
>> candidate time, and it comes down to me fixing it, fair warning
>> that system stability takes precedence and things will revert
>> back to the simple/built-in solutions.
>>
> as mentioned. it was meant as a proof of concept for the testers. in hindsight, communicating the options namely setting env var or switching java alternative should suffice.
>
> btw. i actually do not expect lot's of java apps to choke on openjdk7.
>
>>> telling all java
>>> projects to set proper JAVA_HOMEs in their launch scripts
>>> (do all java apps use scripts?) would achieve the same with
>>> less effort.
>>>
>>> so, any one else an opinion?
>>>
>>> btw. i'd agree to have the java projects to adapt their
>>> launchers manually. they have to do so anyway.
>> I guess hardcoding it depends on how solidly they know it works
>> with ver 7 or not. better to only hardcode it in dire situations
>> though.
> exactly my point ;)
>
> thanks ede
> _______________________________________________
> Live-demo mailing list
> Live-demo at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/live-demo
> http://live.osgeo.org
> http://wiki.osgeo.org/wiki/Live_GIS_Disc


-- 
Cameron Shorter
Geospatial Solutions Manager
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254

Think Globally, Fix Locally
Geospatial Solutions enhanced with Open Standards and Open Source
http://www.lisasoft.com