I would avoid word regression. It was change on demand:
 https://bugzilla.redhat.com/show_bug.cgi?id=1259241 (https://bugzilla.redhat.com/show_bug.cgi?id=1254197)
 https://bugzilla.redhat.com/show_bug.cgi?id=1217177

Isuse is, that original convention was link depending on arch:
32b - java-1.x.0-openjdk
64b - java-1.x.0-openjdk.arch
 
With start of "multipe jdks" this changed, and  only  java-1.x.0-openjdk appeared as alterantives driven simlink between java-1.x.0-openjdk.

So this Should be regression only on 32b systems.

For record: https://bugzilla.redhat.com/show_bug.cgi?id=1143771:  1143771 - Missing /usr/lib/jvm/java-1.6.0-openjdk

(In reply to jiri vanek from comment #1)
> I would avoid word regression. It was change on demand:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1259241
> (https://bugzilla.redhat.com/show_bug.cgi?id=1254197)
>  https://bugzilla.redhat.com/show_bug.cgi?id=1217177
> 
> Isuse is, that original convention was link depending on arch:
> 32b - java-1.x.0-openjdk
> 64b - java-1.x.0-openjdk.arch
>  
> With start of "multipe jdks" this changed, and  only  java-1.x.0-openjdk
> appeared as alterantives driven simlink between java-1.x.0-openjdk.
> 
> So this Should be regression only on 32b systems.
> 

I am not sure I understand ... this bug against is x86_64, so what do you mean by "this Should be regression only on 32b systems" .. 32b systems already have /usr/lib/jvm/java-1.8.0-openjdk don't they? 

On x86_64, /usr/lib/jvm/java-1.8.0-openjdk is not expected to exist as that could be used for a parallel 32b install (unsupported, but we have always left that window open).

This is a regression; /usr/lib/jvm/java-1.8.0-openjdk was there on x86_64 and now it is not. https://post-office.corp.redhat.com/mailman/private/java-team/2016-January/msg00107.html

It's still a regression even if you did it to fix another bug. The first of those listed isn't even ACKed and is 32-bit. The other two are about the use of the entire version+release in alternatives and doesn't necessitate removing java-1.8.0-openjdk.

If we must allow for both 32-bit and 64-bit installs on the same installation, why not suffix both of them and then symlink the default for that platform to java-1.8.0-openjdk? That would allow us to find OpenJDK 8, while also allowing both to be installed and making it clear that the other is 32-bit. If the 32-bit one is installed on a 64-bit platform, it's going to be confusing to have that as /usr/lib/jvm/java-1.8.0-openjdk, given that was previously a 64-bit JDK.

(In reply to Andrew John Hughes from comment #3)
> This is a regression; /usr/lib/jvm/java-1.8.0-openjdk was there on x86_64
> and now it is not.
> https://post-office.corp.redhat.com/mailman/private/java-team/2016-January/
> msg00107.html
> 
> It's still a regression even if you did it to fix another bug. The first of
> those listed isn't even ACKed and is 32-bit. The other two are about the use

6.7 version is acked.

> of the entire version+release in alternatives and doesn't necessitate
> removing java-1.8.0-openjdk.
> 
> If we must allow for both 32-bit and 64-bit installs on the same
> installation, why not suffix both of them and then symlink the default for

right now both are suffixed.

> that platform to java-1.8.0-openjdk? That would allow us to find OpenJDK 8,

Tahts a lot of code in post. I'm trying to minimalize the actual code in posts of rpms, as they are very often source of unexpected and hard to find errors.

> while also allowing both to be installed and making it clear that the other
> is 32-bit. If the 32-bit one is installed on a 64-bit platform, it's going
> to be confusing to have that as /usr/lib/jvm/java-1.8.0-openjdk, given that
> was previously a 64-bit JDK.

Our rpms are used in strange ways. Installed without scripts, just uncpioed, in strange locations and variously simlinked or installed to mirrors to be somehow synced to anotehr machines. No metter how unsupported this may be, it is how they are used.

Every time change is introduced to the top level directroiest there rise customer request how so. And luckily our customer is our lord. not our engineers. So both this and 1298972 will be closed as cant fix. The fix to the two bugs I mentioned was not simple, and with each hunk some strange side behavior appeared. But press on this fix was strong and at the end hallowed by PM.

To title. If yo insists.. Well ehy not. But the "regression" was introduced intentionally. So its not regression, but correct behavior.

(In reply to jiri vanek from comment #5)
> To title. If yo insists.. Well ehy not. But the "regression" was introduced
> intentionally. So its not regression, but correct behavior.

Okay now I am confused. So the introduction of "/usr/lib/jvm/java-1.8.0-openjdk" on x86_64 was intentional? So if it is gone now, isn't that a regression?

Deepak, I guess you recall story of those two bugs. Fix for 1217177 consisted from a lot of emails from a lot of people and form at least one call.

Shortened - jdk8 went to rhel6 with "multiple jdks" inside, but "disabled". So it had alternatives-driven symnlink java-1.8.0-openjdk. To be able to intoroduced same directory structure as 1.7 and 1.6 and so to have alternatives aligned, this simlink *had to* be removed. So it happened. So it can not be regression, when it was removed on demand (the link was the bug!).

Unluckily it introduced 1259241 which's solution actualy is to revert fix for 1217177. So we went by the hackish way of real regression on 32machines - but imho there is no other way around - and for now nobody was missing the symlink.

However good Andrew's reasons are, the link can not be simply reintroduced, and form point of view f rhel6 it was never supposed to exists.

Fixing 1217177 took two months, and was full of surprises. We can be sure that it will hjappen again if this link will go back.
About hte clone of this bug for 7. It is not an regression as on jdk7 iirc this link on 64b systems never existed.

(one general thought. The real bug below is lying in rhel4 where somebody intorudced: if (32b) then mainDir=java-1.6.0-openjdk else  mainDir=java-1.6.0-openjdk.%{_arch} fi. Which was finally fixed in rhel7 ,by NVRA+alternatives driven java-1.X.0-openjdk symlink, which went to rhel6 with good intentions with new package of openjdk8, but failed)

(In reply to jiri vanek from comment #7)
> Deepak, I guess you recall story of those two bugs. Fix for 1217177
> consisted from a lot of emails from a lot of people and form at least one
> call.
> 
> Shortened - jdk8 went to rhel6 with "multiple jdks" inside, but "disabled".
> So it had alternatives-driven symnlink java-1.8.0-openjdk. To be able to
> intoroduced same directory structure as 1.7 and 1.6 and so to have
> alternatives aligned, this symlink *had to* be removed. So it happened. So
> it can not be regression, when it was removed on demand (the link was the
> bug!).

It's still a regression because the link was there. Why it was removed is irrelevant. RHEL 6 provided this symlink and now it doesn't. Anything that was using it will break.

> 
> Unluckily it introduced 1259241 which's solution actualy is to revert fix
> for 1217177. So we went by the hackish way of real regression on 32machines
> - but imho there is no other way around - and for now nobody was missing the
> symlink.
> 
> However good Andrew's reasons are, the link can not be simply reintroduced,
> and form point of view f rhel6 it was never supposed to exists.

But it did.

Given two engineers have already reported this, I think it's only a matter of time until a customer encounters it too.

> 
> Fixing 1217177 took two months, and was full of surprises. We can be sure
> that it will hjappen again if this link will go back.

Can we? How is a link going to change anything? If you're saying it's ok to not have it, then you're implicitly saying that no-one is using it. Thus, adding it wouldn't affect anyone.

> About hte clone of this bug for 7. It is not an regression as on jdk7 iirc
> this link on 64b systems never existed.

I must be getting mixed up with RHEL 7 which does have them:

$ ls -l /usr/lib/jvm/java-1.?.0-openjdk
lrwxrwxrwx. 1 root root 40 Jan 19 01:22 /usr/lib/jvm/java-1.7.0-openjdk -> /etc/alternatives/java_sdk_1.7.0_openjdk
lrwxrwxrwx. 1 root root 40 Jan 16 11:49 /usr/lib/jvm/java-1.8.0-openjdk -> /etc/alternatives/java_sdk_1.8.0_openjdk

So are the RHEL 7 ones the correct ones and this whole RHEL 6 mess  is just legacy? If that's the case, then maybe we can just say RHEL 6 is not supported.

> 
> (one general thought. The real bug below is lying in rhel4 where somebody
> intorudced: if (32b) then mainDir=java-1.6.0-openjdk else 
> mainDir=java-1.6.0-openjdk.%{_arch} fi. Which was finally fixed in rhel7 ,by
> NVRA+alternatives driven java-1.X.0-openjdk symlink, which went to rhel6
> with good intentions with new package of openjdk8, but failed)

The logic for OpenJDK 6 is actually conditional on JIT architectures, not 32-bit, as noted in bug 1143771. You've still not answered why that is the case.

(In reply to Andrew John Hughes from comment #8)
> (In reply to jiri vanek from comment #7)
> > Deepak, I guess you recall story of those two bugs. Fix for 1217177
> > consisted from a lot of emails from a lot of people and form at least one
> > call.
> > 
> > Shortened - jdk8 went to rhel6 with "multiple jdks" inside, but "disabled".
> > So it had alternatives-driven symnlink java-1.8.0-openjdk. To be able to
> > intoroduced same directory structure as 1.7 and 1.6 and so to have
> > alternatives aligned, this symlink *had to* be removed. So it happened. So
> > it can not be regression, when it was removed on demand (the link was the
> > bug!).
> 
> It's still a regression because the link was there. Why it was removed is
> irrelevant. RHEL 6 provided this symlink and now it doesn't. Anything that
> was using it will break.
> 

I quite disagree. I would guess that they are usingwhat htey were used to see in older jdks.

> > 
> > Unluckily it introduced 1259241 which's solution actually is to revert fix
> > for 1217177. So we went by the hackish way of real regression on 32machines
> > - but imho there is no other way around - and for now nobody was missing the
> > symlink.
> > 
> > However good Andrew's reasons are, the link can not be simply reintroduced,
> > and form point of view f rhel6 it was never supposed to exists.
> 
> But it did.
> 
> Given two engineers have already reported this, I think it's only a matter
> of time until a customer encounters it too.

Who is the second?
> 
> > 
> > Fixing 1217177 took two months, and was full of surprises. We can be sure
> > that it will hjappen again if this link will go back.
> 
> Can we? How is a link going to change anything? If you're saying it's ok to
> not have it, then you're implicitly saying that no-one is using it. Thus,
> adding it wouldn't affect anyone.

Thats the issue. That you do not see how those links may cause breakages. Unluckily, they do. They always bite when it is most unexpected. I'm not going to waste more time on recapitulating history of various "broken link" "missing lnk" or "redundant link blocking something" history of packages.
  
> 
> > About the clone of this bug for 7. It is not an regression as on jdk7 iirc
> > this link on 64b systems never existed.
> 
> I must be getting mixed up with RHEL 7 which does have them:

Yes you obviously do.
> 
> $ ls -l /usr/lib/jvm/java-1.?.0-openjdk
> lrwxrwxrwx. 1 root root 40 Jan 19 01:22 /usr/lib/jvm/java-1.7.0-openjdk ->
> /etc/alternatives/java_sdk_1.7.0_openjdk
> lrwxrwxrwx. 1 root root 40 Jan 16 11:49 /usr/lib/jvm/java-1.8.0-openjdk ->
> /etc/alternatives/java_sdk_1.8.0_openjdk
> 
> So are the RHEL 7 ones the correct ones and this whole RHEL 6 mess  is just
Rhel 7 do it right. But rhel 7 do it right from begginign.

> legacy? If that's the case, then maybe we can just say RHEL 6 is not
> supported.

I guess you are just tempting us with this. Fact that the link is now missing means rhel6 is supported.

Rhel6 have different syle.  The big bug was  that the jdk8 was NOT  originally honoring this style.

> 
> > 
> > (one general thought. The real bug below is lying in rhel4 where somebody
> > intorudced: if (32b) then mainDir=java-1.6.0-openjdk else 
> > mainDir=java-1.6.0-openjdk.%{_arch} fi. Which was finally fixed in rhel7 ,by
> > NVRA+alternatives driven java-1.X.0-openjdk symlink, which went to rhel6
> > with good intentions with new package of openjdk8, but failed)
> 
> The logic for OpenJDK 6 is actually conditional on JIT architectures, not
> 32-bit, as noted in bug 1143771. You've still not answered why that is the
> case.

I did indirectly in https://bugzilla.redhat.com/show_bug.cgi?id=1298973#c7

(In reply to jiri vanek from comment #9)
> (In reply to Andrew John Hughes from comment #8)
> > (In reply to jiri vanek from comment #7)
> > > Deepak, I guess you recall story of those two bugs. Fix for 1217177
> > > consisted from a lot of emails from a lot of people and form at least one
> > > call.
> > > 
> > > Shortened - jdk8 went to rhel6 with "multiple jdks" inside, but "disabled".
> > > So it had alternatives-driven symnlink java-1.8.0-openjdk. To be able to
> > > intoroduced same directory structure as 1.7 and 1.6 and so to have
> > > alternatives aligned, this symlink *had to* be removed. So it happened. So
> > > it can not be regression, when it was removed on demand (the link was the
> > > bug!).
> > 
> > It's still a regression because the link was there. Why it was removed is
> > irrelevant. RHEL 6 provided this symlink and now it doesn't. Anything that
> > was using it will break.
> > 
> 
> I quite disagree. I would guess that they are usingwhat htey were used to
> see in older jdks.

How, when it didn't exist until this change?

> 
> > > 
> > > Unluckily it introduced 1259241 which's solution actually is to revert fix
> > > for 1217177. So we went by the hackish way of real regression on 32machines
> > > - but imho there is no other way around - and for now nobody was missing the
> > > symlink.
> > > 
> > > However good Andrew's reasons are, the link can not be simply reintroduced,
> > > and form point of view f rhel6 it was never supposed to exists.
> > 
> > But it did.
> > 
> > Given two engineers have already reported this, I think it's only a matter
> > of time until a customer encounters it too.
> 
> Who is the second?

See comment 3.

> > 
> > > 
> > > Fixing 1217177 took two months, and was full of surprises. We can be sure
> > > that it will hjappen again if this link will go back.
> > 
> > Can we? How is a link going to change anything? If you're saying it's ok to
> > not have it, then you're implicitly saying that no-one is using it. Thus,
> > adding it wouldn't affect anyone.
> 
> Thats the issue. That you do not see how those links may cause breakages.
> Unluckily, they do. They always bite when it is most unexpected. I'm not
> going to waste more time on recapitulating history of various "broken link"
> "missing lnk" or "redundant link blocking something" history of packages.

Well, no, because you've failed to explain it.

>   
> > 
> > > About the clone of this bug for 7. It is not an regression as on jdk7 iirc
> > > this link on 64b systems never existed.
> > 
> > I must be getting mixed up with RHEL 7 which does have them:
> 
> Yes you obviously do.

It's hardly surprising if it's different on every platform.

> > 
> > $ ls -l /usr/lib/jvm/java-1.?.0-openjdk
> > lrwxrwxrwx. 1 root root 40 Jan 19 01:22 /usr/lib/jvm/java-1.7.0-openjdk ->
> > /etc/alternatives/java_sdk_1.7.0_openjdk
> > lrwxrwxrwx. 1 root root 40 Jan 16 11:49 /usr/lib/jvm/java-1.8.0-openjdk ->
> > /etc/alternatives/java_sdk_1.8.0_openjdk
> > 
> > So are the RHEL 7 ones the correct ones and this whole RHEL 6 mess  is just
> Rhel 7 do it right. But rhel 7 do it right from begginign.
> 
> > legacy? If that's the case, then maybe we can just say RHEL 6 is not
> > supported.
> 
> I guess you are just tempting us with this. Fact that the link is now
> missing means rhel6 is supported.

I don't get what you're saying here. I'm saying IcedTea won't support RHEL 6 as we won't be able to find a build JDK. At least it seems to be correct on RHEL 7.

> 
> Rhel6 have different syle.  The big bug was  that the jdk8 was NOT 
> originally honoring this style.

Yes, but now people may have come to rely on the style that was initially introduced.

> 
> > 
> > > 
> > > (one general thought. The real bug below is lying in rhel4 where somebody
> > > intorudced: if (32b) then mainDir=java-1.6.0-openjdk else 
> > > mainDir=java-1.6.0-openjdk.%{_arch} fi. Which was finally fixed in rhel7 ,by
> > > NVRA+alternatives driven java-1.X.0-openjdk symlink, which went to rhel6
> > > with good intentions with new package of openjdk8, but failed)
> > 
> > The logic for OpenJDK 6 is actually conditional on JIT architectures, not
> > 32-bit, as noted in bug 1143771. You've still not answered why that is the
> > case.
> 
> I did indirectly in https://bugzilla.redhat.com/show_bug.cgi?id=1298973#c7

Not as far as I can see.

Severin was not missing it. He jsut noticed it is not there. And he got bugzilla explaining.

From me this stay close-cantfix.(In reply to Andrew John Hughes from comment #10)
> (In reply to jiri vanek from comment #9)
> > (In reply to Andrew John Hughes from comment #8)
> > > (In reply to jiri vanek from comment #7)
> > > > Deepak, I guess you recall story of those two bugs. Fix for 1217177
> > > > consisted from a lot of emails from a lot of people and form at least one
> > > > call.
> > > > 
> > > > Shortened - jdk8 went to rhel6 with "multiple jdks" inside, but "disabled".
> > > > So it had alternatives-driven symnlink java-1.8.0-openjdk. To be able to
> > > > intoroduced same directory structure as 1.7 and 1.6 and so to have
> > > > alternatives aligned, this symlink *had to* be removed. So it happened. So
> > > > it can not be regression, when it was removed on demand (the link was the
> > > > bug!).
> > > 
> > > It's still a regression because the link was there. Why it was removed is
> > > irrelevant. RHEL 6 provided this symlink and now it doesn't. Anything that
> > > was using it will break.
> > > 
> > 
> > I quite disagree. I would guess that they are usingwhat htey were used to
> > see in older jdks.
> 
> How, when it didn't exist until this change?

Exactly, it was not there, so  they were not using it when it suddenly appeared.

> 
> > 
> > > > 
> > > > Unluckily it introduced 1259241 which's solution actually is to revert fix
> > > > for 1217177. So we went by the hackish way of real regression on 32machines
> > > > - but imho there is no other way around - and for now nobody was missing the
> > > > symlink.
> > > > 
> > > > However good Andrew's reasons are, the link can not be simply reintroduced,
> > > > and form point of view f rhel6 it was never supposed to exists.
> > > 
> > > But it did.
> > > 
> > > Given two engineers have already reported this, I think it's only a matter
> > > of time until a customer encounters it too.
> > 
> > Who is the second?
> 
> See comment 3.

Severin was not missing it. He noticed it is not there. And he got bugzilla explaining.

x.
> 
> > > 
> > > > 
> > > > Fixing 1217177 took two months, and was full of surprises. We can be sure
> > > > that it will hjappen again if this link will go back.
> > > 
> > > Can we? How is a link going to change anything? If you're saying it's ok to
> > > not have it, then you're implicitly saying that no-one is using it. Thus,
> > > adding it wouldn't affect anyone.
> > 
> > Thats the issue. That you do not see how those links may cause breakages.
> > Unluckily, they do. They always bite when it is most unexpected. I'm not
> > going to waste more time on recapitulating history of various "broken link"
> > "missing lnk" or "redundant link blocking something" history of packages.
> 
> Well, no, because you've failed to explain it.

Yes I'm obviously failing.  But you are also obviosly not trying to understand.
> 
> >   
> > > 
> > > > About the clone of this bug for 7. It is not an regression as on jdk7 iirc
> > > > this link on 64b systems never existed.
> > > 
> > > I must be getting mixed up with RHEL 7 which does have them:
> > 
> > Yes you obviously do.
> 
> It's hardly surprising if it's different on every platform.
> 
> > > 
> > > $ ls -l /usr/lib/jvm/java-1.?.0-openjdk
> > > lrwxrwxrwx. 1 root root 40 Jan 19 01:22 /usr/lib/jvm/java-1.7.0-openjdk ->
> > > /etc/alternatives/java_sdk_1.7.0_openjdk
> > > lrwxrwxrwx. 1 root root 40 Jan 16 11:49 /usr/lib/jvm/java-1.8.0-openjdk ->
> > > /etc/alternatives/java_sdk_1.8.0_openjdk
> > > 
> > > So are the RHEL 7 ones the correct ones and this whole RHEL 6 mess  is just
> > Rhel 7 do it right. But rhel 7 do it right from begginign.
> > 
> > > legacy? If that's the case, then maybe we can just say RHEL 6 is not
> > > supported.
> > 
> > I guess you are just tempting us with this. Fact that the link is now
> > missing means rhel6 is supported.
> 
> I don't get what you're saying here. I'm saying IcedTea won't support RHEL 6
> as we won't be able to find a build JDK. At least it seems to be correct on
> RHEL 7.

Icedtea8? Icedte8 is not used on no rhel.
> 
> > 
> > Rhel6 have different syle.  The big bug was  that the jdk8 was NOT 
> > originally honoring this style.
> 
> Yes, but now people may have come to rely on the style that was initially
> introduced.

May and may not. Dont forget Rhel 6 is still running on jdk6.
> 
> > 
> > > 
> > > > 
> > > > (one general thought. The real bug below is lying in rhel4 where somebody
> > > > intorudced: if (32b) then mainDir=java-1.6.0-openjdk else 
> > > > mainDir=java-1.6.0-openjdk.%{_arch} fi. Which was finally fixed in rhel7 ,by
> > > > NVRA+alternatives driven java-1.X.0-openjdk symlink, which went to rhel6
> > > > with good intentions with new package of openjdk8, but failed)
> > > 
> > > The logic for OpenJDK 6 is actually conditional on JIT architectures, not
> > > 32-bit, as noted in bug 1143771. You've still not answered why that is the
> > > case.
> > 
> > I did indirectly in https://bugzilla.redhat.com/show_bug.cgi?id=1298973#c7
> 
> Not as far as I can see.

From me this stays close-cantfix (and I really cant. It will be really huge and dangerous change)

I'm giving up there.

snip...

> > > 
> > > I quite disagree. I would guess that they are usingwhat htey were used to
> > > see in older jdks.
> > 
> > How, when it didn't exist until this change?
> 
> Exactly, it was not there, so  they were not using it when it suddenly
> appeared.

"What they are used to" is /usr/lib/jvm/java-1.x.0-openjdk.${arch}, right? So how were they using that before it was added?

snip...

> > > > 
> > > > > 
> > > > > Fixing 1217177 took two months, and was full of surprises. We can be sure
> > > > > that it will hjappen again if this link will go back.
> > > > 
> > > > Can we? How is a link going to change anything? If you're saying it's ok to
> > > > not have it, then you're implicitly saying that no-one is using it. Thus,
> > > > adding it wouldn't affect anyone.
> > > 
> > > Thats the issue. That you do not see how those links may cause breakages.
> > > Unluckily, they do. They always bite when it is most unexpected. I'm not
> > > going to waste more time on recapitulating history of various "broken link"
> > > "missing lnk" or "redundant link blocking something" history of packages.
> > 
> > Well, no, because you've failed to explain it.
> 
> Yes I'm obviously failing.  But you are also obviosly not trying to
> understand.

There's nothing to be understood when you outright refuse to answer questions.

> > 
> > >   
> > > > 
> > > > > About the clone of this bug for 7. It is not an regression as on jdk7 iirc
> > > > > this link on 64b systems never existed.
> > > > 
> > > > I must be getting mixed up with RHEL 7 which does have them:
> > > 
> > > Yes you obviously do.
> > 
> > It's hardly surprising if it's different on every platform.
> > 
> > > > 
> > > > $ ls -l /usr/lib/jvm/java-1.?.0-openjdk
> > > > lrwxrwxrwx. 1 root root 40 Jan 19 01:22 /usr/lib/jvm/java-1.7.0-openjdk ->
> > > > /etc/alternatives/java_sdk_1.7.0_openjdk
> > > > lrwxrwxrwx. 1 root root 40 Jan 16 11:49 /usr/lib/jvm/java-1.8.0-openjdk ->
> > > > /etc/alternatives/java_sdk_1.8.0_openjdk
> > > > 
> > > > So are the RHEL 7 ones the correct ones and this whole RHEL 6 mess  is just
> > > Rhel 7 do it right. But rhel 7 do it right from begginign.
> > > 
> > > > legacy? If that's the case, then maybe we can just say RHEL 6 is not
> > > > supported.
> > > 
> > > I guess you are just tempting us with this. Fact that the link is now
> > > missing means rhel6 is supported.
> > 
> > I don't get what you're saying here. I'm saying IcedTea won't support RHEL 6
> > as we won't be able to find a build JDK. At least it seems to be correct on
> > RHEL 7.
> 
> Icedtea8? Icedte8 is not used on no rhel.

Not by you, maybe, but we have to make decisions as to what to support as a project. If there's no way to refer to OpenJDK 8 on RHEL 6 (or 7 or 6 for that matter, so all versions of IcedTea), then we can't find the JDK automatically.

Jiri, I am looking at the dir names now, and I see that there are jre-1.8.0-openjdk* symlinks already that point to JAVA_HOME/jre. Can we not piggy back on this mechanism for java-* too? The java* in this case would just go to the JAVA_HOME itself.

Closing this as RHEL 6 is now in phase 3 and this isn't worth altering now.