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
__________________________________________________
|
