Fatal Error on PPC64 and PPC64LE for both JDK7 and JDK8
Andrew Hughes
gnu.andrew at redhat.com
Fri Apr 24 16:19:07 UTC 2015
----- Original Message -----
> On 04/24/2015 04:20 PM, Andrew Hughes wrote:
> >
> > ----- Original Message -----
> >> On 04/24/2015 02:43 PM, Lindenmaier, Goetz wrote:
> >>
> >>> Have there been any decisions about who will take over the
> >>> maintenance of the jdk7u repositories? If you (RedHat) will do this
> >>> as with jdk6, could you imagine to integrate the ppc port into
> >>> jdk7u? This would simplify the support from our side, and maybe for
> >>> you as well.
> >>
> >> I think we'll take over jdk7, yes.
> >>
> >> Integrating PPC is an interesting idea. My current thinking is to put
> >> jdk7, like jdk6, into long-term cold storage with nothing except
> >> critical bug fixes. It might make sense to integrate PPC, though, if
> >> it's non-intrusive.
> >
> > The PPC port has been in IcedTea since 2.5.0 [0]. I see no problem with
> > moving it into OpenJDK 7 upstream. I'd also say the same for the AArch64
> > port that will appear in IcedTea with 2.6.0.
> >
> > Generally, 7 is still a lot more widely used and current than 6, so
> > I'm not sure we should be quite as restrictive with changes there.
>
> Surely the reverse is true: OpenJDK 7 is important, so it needs to be
> treated with great care. The more critical something is, the higher
> the bar for changes. In other words, the bar set for changes to
> OpenJDK 6 is not because I don't care about it but because I care very
> much.
>
> Maintenance programming is about the wisdom to know when not to touch
> something, even though you know it could be improved, because it's not
> worth the risk.
>
> > They are quite different beasts; OpenJDK 6 was like an unloved
> > step-child of an early version of OpenJDK 7, which Oracle only
> > really maintained with security updates from the very start, while
> > OpenJDK 7 has been the basis of their proprietary 7 releases
> > throughout. I think we should be keeping a close eye on what
> > is added to 8u and backporting the majority of eligible changes
> > to 7 as well, if we want to maintain it.
>
> People using OpenJDK 6 and 7 are not doing so because they want new
> features or better performance but because they want stability. We
> must respect that. Critical infrastructure depends on OpenJDK 7, and
> will do for a long time to come, and we must not break it. The
> longer-established a piece of software is the more stable people
> expect it to be, and they have a right to.
>
> None of this should be interpreted to mean that there will not be
> back-ports where appropriate. The OpenJDK policy is still on the
> OpenJDK 6 project page:
>
> "bug fixes in JDK 7 that do not involve specification changes have
> presumptive validity for OpenJDK 6. That is, by default such fixes are
> assumed to be applicable to OpenJDK 6, especially if having 'soaked'
> in JDK 7 for a time without incident."
>
> Substitute 8 and 7 for 7 and 6 and you're where I think we should be.
> First, do no harm.
>
I think we're on the same page here; I'm suggesting we track changes that
have already passed the above validity test for backport from 9 to 8u,
not that we go introducing changes for new features or better performance.
I'm well aware of that policy, as I've been making OpenJDK 6 changes under
that policy since the project started.
I just don't want us to end up in a situation like we have with OpenJDK 6
where we lack a large number of the fixes Oracle made to the proprietary
version, leading us to situations like [0] where we had to bulk import
a huge batch of updates to internationalisation data. So we need to be
a little bit more pro-active, if possible, in tracking what's going on
elsewhere and bringing in more than just quarterly security updates.
It sounds like you are of a similar mind from your longer response,
but your initial comment on "long-term cold storage" suggested otherwise.
My note about the prevalence of OpenJDK 7 usage was more about the fact
that any changes will have a longer-term impact than they would for 6.
I think this makes changes to modernise the cryptography support (e.g.
allowing larger key sizes), as we've done in IcedTea, more appropriate
for 7 as it's going to be in use for longer and in a wider variety of
situations. We don't want to end up in a situation where OpenJDK 7
is unable to connect to modern web servers, for example.
[0] http://mail.openjdk.java.net/pipermail/jdk6-dev/2015-January/003459.html
> Andrew.
>
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
More information about the ppc-aix-port-dev
mailing list