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