I should add that when installing 1.6 from Sun it doesn't uninstall 1.5 or
any previous version. So sites can easily add new versions, still using
old ones.
Michel
--On jeudi 29 novembre 2007 08:53 -0600 Troy Dawson <[log in to unmask]> wrote:
> Thanks for the input, both on the list and off the list.
> It's sounding like things are leaning heavily towards the 3rd option.
> Upgrade the java to be version 1.5, the same as in SL 5, modifying the
> compat rpm to deal with the j2sdk rpm.
>
> Here is a summary of what I've received.
> - Most experiments who rely on a certain version of java for their code,
> already have that version installed. Hense updating j2sdk (and
> potentially removing their version) probably isn't a good idea, or
> doesn't affect them.
> - Those people who have tested, have found that their 1.4.2 code runs on
> java 1.5, so an update wouldn't affect them really.
> - Jumping to java 1.6 or above *might* affect some peoples code. Most
> people have only tested it on 1.5.
> - Jumping to java 1.6 or above *might* affect tomcat. That hasn't been
> tested.
>
> So, it's sounding like moving to java 1.5 in SL4, just like we have in
> SL5 is the way to go. We'll have to do some further testing before
> jumping to 1.6 or above.
>
> But I think we should start that testing because when the GPL'ed version
> of java becomes stable, I want to move to it. I'm going to try to get it
> into contrib (many thanks to the efforts of people in CentOS) so that
> people can start testing if they want.
>
> Thanks
> Troy
>
> Michel Jouvin wrote:
>> I support Jan's opinion. Our experience here at LAL with several
>> different Java apps, including grid ones, is that there is not
>> compatibility problem between 1.5 and 1.6 and a significant performance
>> benefit for multithreaded applications (20%).
>>
>> Michel
>>
>> --On jeudi 29 novembre 2007 09:50 +0100 Jan Iven <[log in to unmask]>
>> wrote:
>>
>>> On 28/11/07 23:26, Troy Dawson wrote:
>>>> Hi All,
>>>> We have a bit of a problem with java on SL4, and I believe most of you
>>>> know at least part of it.
>>>> Our java rpm's come straight from Sun with no changes. Even signing
>>>> them causes problems with the rpm.
>>>> The 1.4.2 rpm that comes from sun, for some unkown reason, says that it
>>>> obsoletes jdk. This means that when you update the j2sdk, it deletes
>>>> any jdk rpms an admin might have added even if it's newer. So if I
>>>> send out an update to the current j2sdk for 1.4.2, it will delete the
>>>> 1.5.0 java and/or the 1.6.0 java.
>>>>
>>>> But I'm really hating not getting the security updates out for this
>>>> java.
>>>>
>>>> I see three options.
>>>> 1 - We just push it out as it is, and say "sorry" to everyone this
>>>> hurts. (That's what we did last time ... and trust me, that's alot of
>>>> "sorry" I had to say)
>>>> 2 - We rebuild the j2sdk rpm, leaving out the obsolete line.
>>>> 3 - We drop j2sdk and change our supported java to be version 1.5 and
>>>> above.
>>>>
>>>> I am leaving heavily towards option 3. Just move everything up to java
>>>> 1.5 or above.
>>>>
>>>> But the question is, how much is that going to hurt people and/or
>>>> experiments?
>>>>
>>>> I *think* that moving to jave 1.5 isn't going to affect programs
>>>> running 1.4.2, but I don't know.
>>>>
>>>> Also, why stop at 1.5, what if we just did the latest 1.6, and maybe
>>>> say we're always going to stay at the latest stable release for java.
>>>>
>>>> I need some second opinions.
>>> here we go. Background is that we have our own J2RE-1.4 and JDK-1.5
>>> repackaged RPMs - only available within CERN since we never got any "OK
>>> to distribute" from SUN (but of course the .spec is free). These are
>>> loosely based on jpackage.org "nosrc".
>>>
>>> * We haven't seen any issues from 1.5 with older (-1.4) programs so far.
>>> But our usage is somewhat limited (browser plugin, some simplistic
>>> apps). Most heavyweight Java users seem to have their own installation
>>> somewhere.
>>>
>>> * the 1.4.2 RPMs from SUN are indeed broken, up to and including
>>> mismatch between RPM filename and metadata content - this screws some
>>> RPM tools that assume
>>> http://someplace/%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm should
>>> exist, just because the metadata is present. It used to affect YUM, not
>>> sure whether this is still the case.
>>>
>>> * we have (ourselves) little experience with 1.6. 1.7/openjdk is not in
>>> usable form yet, but set to be getting there relatively soon since F8
>>> now comes with icedtea (a completely free instance of the
>>> partially-encumbered 1.7 JDK). I'd rather look at 1.7 since that will
>>> remove any lingering doubts about lawful redistribution.
>>>
>>> My personal opinion would be to go for a repackaged 1.5 that properly
>>> obsoletes your previous version of 1.4.2 (but nothing else, to allow for
>>> parallel installs), and at the same time declare that you may change
>>> versions later. After all, this is not part of the release TUV SRPM set,
>>> so not as tightly bound to the "do not change" commitment.
>>>
>>> Best regards
>>> Jan
>>
>>
>>
>> *************************************************************
>> * Michel Jouvin Email : [log in to unmask] *
>> * LAL / CNRS Tel : +33 1 64468932 *
>> * B.P. 34 Fax : +33 1 69079404 *
>> * 91898 Orsay Cedex *
>> * France *
>> *************************************************************
>>
>>
>
>
> --
> __________________________________________________
> Troy Dawson [log in to unmask] (630)840-6468
> Fermilab ComputingDivision/LCSI/CSI DSS Group
> __________________________________________________
*************************************************************
* Michel Jouvin Email : [log in to unmask] *
* LAL / CNRS Tel : +33 1 64468932 *
* B.P. 34 Fax : +33 1 69079404 *
* 91898 Orsay Cedex *
* France *
*************************************************************
|
