Fatal Error on PPC64 and PPC64LE for both JDK7 and JDK8

[Andrew Hughes]

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