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