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