Bug 1217177 - Inconsistent directory naming and alternatives handling between Java 6/7 and 8
Summary: Inconsistent directory naming and alternatives handling between Java 6/7 and 8
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: java-1.8.0-openjdk
Version: 6.6
Hardware: Unspecified
OS: Linux
urgent
high
Target Milestone: rc
: ---
Assignee: jiri vanek
QA Contact: Lukáš Zachar
Lenka Špačková
URL:
Whiteboard:
Depends On:
Blocks: 1172231 1271375 1254197
TreeView+ depends on / blocked
 
Reported: 2015-04-29 17:28 UTC by Bryan Totty
Modified: 2019-11-14 06:42 UTC (History)
10 users (show)

Fixed In Version: java-1.8.0-openjdk-1.8.0.51-2.b16.el6
Doc Type: Bug Fix
Doc Text:
Naming convention for _java-1.8.0-openjdk_ installation made consistent Previously, the automatically generated name for the installation directory for the _java-1.8.0-openjdk_ package was not consistent with installation directory names for the _java-1.6.0-openjdk_ and _java-1.7.0-openjdk_ packages. As a consequence, applications and automated tools that expected a consistent Java naming pattern failed when interacting with _java-1.8.0-openjdk_. With this update, _java-1.8.0-openjdk_ installation directory follows the same pattern as the previous versions, which prevents the described problem. Note that due to the changes in the path structure, it is now impossible to revert to a version of _java-1.8.0-openjdk_ prior to this update.
Clone Of:
: 1254197 (view as bug list)
Environment:
Last Closed: 2016-05-10 21:03:23 UTC
Target Upstream Version:


Attachments (Terms of Use)
suggested patch v01 (4.58 KB, patch)
2015-07-30 16:25 UTC, jiri vanek
no flags Details | Diff
patch 3 (7.67 KB, patch)
2015-07-31 11:53 UTC, jiri vanek
no flags Details | Diff
patch4 (7.67 KB, patch)
2015-07-31 11:56 UTC, jiri vanek
no flags Details | Diff
patch5 (7.82 KB, patch)
2015-08-13 14:18 UTC, jiri vanek
no flags Details | Diff
patchg6 (8.18 KB, patch)
2015-08-14 09:01 UTC, jiri vanek
no flags Details | Diff
patch7 (8.55 KB, patch)
2015-08-14 12:05 UTC, jiri vanek
jvanek: review?
Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0816 normal SHIPPED_LIVE java-1.8.0-openjdk bug fix and enhancement update 2016-05-10 22:39:37 UTC

Description Bryan Totty 2015-04-29 17:28:11 UTC
Description of problem:

In java-1.6.0-openjdk and java-1.7.0-openjdk the installation directory is "NAME-VERSION".

	/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.34.x86_64
	/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75.x86_64

However, in java-1.8.0-openjdk the installation directory is "NAME-VERSION-RELEASE".

	/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64



Additionally, the "alternatives" configuration is inconsistent.  To update alternatives for OpenJDK 1.6 or 1.7 you say:

	alternatives --set java /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java

or:

	alternatives --set java /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java


But for OpenJDK 1.8 you say:

	alternatives --set java /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64/jre/bin/java

	(using /usr/lib/jvm/jre-1.8.0-openjdk.x86_64/bin/java does NOT work)



Version-Release number of selected component (if applicable):

openjdk-1.8.0.31

How reproducible:
Always

Steps to Reproduce:
1. Install OpenJDK 1.8

Actual results:

The installation at-

	/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64

doesn't line up with say what you might expect:

	/usr/lib/jvm/java-1.8.0-openjdk.x86_64


Expected results:

	/usr/lib/jvm/java-1.8.0-openjdk.x86_64


Additional info:

This can adversely affect existing applications that expect a consistent Java naming scheme. 

This inconsistency is an automation annoyance and confusing for users in general.

Comment 1 jiri vanek 2015-05-04 11:42:46 UTC
hi!

Since rhel-7  this naming is affecting *all* jdks. (6/7/8 x oepnjdk/oracle/ibm).
As jdk8 was designed for rhel7 and later backported to rhel6 it is keeping its name convention.

The reason is, that you can have more same jdks installed in parallel. And even "minor" release ++ can have an crucial patch.


> This can adversely affect existing applications that expect a consistent Java naming scheme. 

It should not. You should use the links pointing to those dirs. And those links are still kept.

Comment 4 Bryan Totty 2015-05-13 15:40:32 UTC
Here's the definition for the links for java-1.6.0-openjdk.spec

# Standard JPackage naming and versioning defines.
%define origin          openjdk
%define priority        16000
%define javaver         1.6.0
%define buildver        0

# Standard JPackage directories and symbolic links.
# Make 64-bit JDKs just another alternative on 64-bit architectures.
%ifarch %{multilib_arches}
%define sdklnk          java-%{javaver}-%{origin}.%{_arch}
%define jrelnk          jre-%{javaver}-%{origin}.%{_arch}
%define sdkdir          %{name}-%{version}.%{_arch}
%else
%define sdklnk          java-%{javaver}-%{origin}
%define jrelnk          jre-%{javaver}-%{origin}
%define sdkdir          %{name}-%{version}
%endif
%define jredir          %{sdkdir}/jre
%define sdkbindir       %{_jvmdir}/%{sdklnk}/bin
%define jrebindir       %{_jvmdir}/%{jrelnk}/bin
%ifarch %{multilib_arches}
%define jvmjardir       %{_jvmjardir}/%{name}-%{version}.%{_arch}
%else
%define jvmjardir       %{_jvmjardir}/%{name}-%{version}
%endif


and the diffs between java-1.6.0-openjdk.spec java-1.7.0-openjdk.spec

140,142c140,142         
< %define sdklnk          java-%{javaver}-%{origin}.%{_arch}
< %define jrelnk          jre-%{javaver}-%{origin}.%{_arch}
< %define sdkdir          %{name}-%{version}.%{_arch}
---
> %global sdklnk          java-%{javaver}-%{origin}.%{_arch}
> %global jrelnk          jre-%{javaver}-%{origin}.%{_arch}
> %global sdkdir          %{name}-%{version}.%{_arch}
144,150c144,150
< %define sdklnk          java-%{javaver}-%{origin}
< %define jrelnk          jre-%{javaver}-%{origin}
< %define sdkdir          %{name}-%{version}
< %endif
< %define jredir          %{sdkdir}/jre
< %define sdkbindir       %{_jvmdir}/%{sdklnk}/bin
< %define jrebindir       %{_jvmdir}/%{jrelnk}/bin
---
> %global sdklnk          java-%{javaver}-%{origin}
> %global jrelnk          jre-%{javaver}-%{origin}
> %global sdkdir          %{name}-%{version}
> %endif
> %global jredir          %{sdkdir}/jre
> %global sdkbindir       %{_jvmdir}/%{sdklnk}/bin
> %global jrebindir       %{_jvmdir}/%{jrelnk}/bin
152c152
< %define jvmjardir       %{_jvmjardir}/%{name}-%{version}.%{_arch}
---
> %global jvmjardir       %{_jvmjardir}/%{name}-%{version}.%{_arch}
154c154
< %define jvmjardir       %{_jvmjardir}/%{name}-%{version}
---
> %global jvmjardir       %{_jvmjardir}/%{name}-%{version}
156a157,160


It's basically trivial.

Here's the diffs between java-1.7.0-openjdk.spec and java-1.8.0-openjdk.spec

Note that jrelnk wsa redefined from:

< %global jrelnk          jre-%{javaver}-%{origin}.%{_arch}

to

> %global jrelnk          jre-%{javaver}-%{origin}-%{version}-%{release}.%{_arch}


Which is inconsistent with previous releases.

Either this needs to be fixed, OR something needs to be put into the release notes that documents this change.

138,155c104,105
< # Make 64-bit JDKs just another alternative on 64-bit architectures.
< %ifarch %{multilib_arches}
< %global sdklnk          java-%{javaver}-%{origin}.%{_arch}
< %global jrelnk          jre-%{javaver}-%{origin}.%{_arch} ### <---- NOTE
< %global sdkdir          %{name}-%{version}.%{_arch}
< %else
< %global sdklnk          java-%{javaver}-%{origin}
< %global jrelnk          jre-%{javaver}-%{origin}
< %global sdkdir          %{name}-%{version}
< %endif
< %global jredir          %{sdkdir}/jre
< %global sdkbindir       %{_jvmdir}/%{sdklnk}/bin
< %global jrebindir       %{_jvmdir}/%{jrelnk}/bin
< %ifarch %{multilib_arches}
< %global jvmjardir       %{_jvmjardir}/%{name}-%{version}.%{_arch}
< %else
< %global jvmjardir       %{_jvmjardir}/%{name}-%{version}
< %endif
---
> %global sdkdir          %{uniquesuffix}
> %global jrelnk          jre-%{javaver}-%{origin}-%{version}-%{release}.%{_arch}  ### <---- NOTE
157,159c107,116
< # The suffix for file names when we have to make them unique (from
< # other Java packages).
< %global uniquesuffix          %{name}
---
> %global jredir          %{sdkdir}/jre
> %global sdkbindir       %{_jvmdir}/%{sdkdir}/bin
> %global jrebindir       %{_jvmdir}/%{jredir}/bin
> %global jvmjardir       %{_jvmjardir}/%{uniquesuffix}
> 
> %global fullversion     %{name}-%{version}-%{release}
> 
> %global uniquesuffix          %{fullversion}.%{_arch}
> #we can copy the javadoc to not arched dir, or made it not noarch
> %global uniquejavadocdir       %{fullversion}

Comment 9 Jason Bradley Nance 2015-05-19 16:38:24 UTC
Per suggestion from GSS I'm pulling in the comments from the support case that spawned this BZ.  Sorry for any duplicate info.

My understanding thus far is that the change was made to allow for multiple, minor versions of Java to be installed concurrently.  However, this is not possible in the RHEL 6 OpenJDK 1.8 packages:

$ rpm -q java-1.8.0-openjdk
java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64
$ sudo yum list java-1.8.0-openjdk --showduplicates
Loaded plugins: downloadonly, rhnplugin, security
This system is receiving updates from RHN Classic or RHN Satellite.
Installed Packages
java-1.8.0-openjdk.x86_64 1:1.8.0.31-1.b13.el6_6   @preprod-rhel-x86_64-server-6
Available Packages
java-1.8.0-openjdk.x86_64 1.8.0.20-3.b26.el6       preprod-rhel-x86_64-server-6
java-1.8.0-openjdk.x86_64 1.8.0.25-1.b17.el6       preprod-rhel-x86_64-server-6
java-1.8.0-openjdk.x86_64 1.8.0.25-3.b17.el6_6     preprod-rhel-x86_64-server-6
java-1.8.0-openjdk.x86_64 1:1.8.0.31-1.b13.el6_6   preprod-rhel-x86_64-server-6
java-1.8.0-openjdk.x86_64 1:1.8.0.45-28.b13.el6_6  preprod-rhel-x86_64-server-6
$ sudo yum install java-1.8.0-openjdk-1.8.0.20-3.b26.el6.x86_64
Loaded plugins: downloadonly, rhnplugin, security
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Install Process
Package matching java-1.8.0-openjdk-1.8.0.20-3.b26.el6.x86_64 already installed. Checking for update.
Nothing to do


Additionally, this requires that you know the precise version number (including release) in order to use the alternatives system to select your Java, which is very much non-desirable in the world of automation.  For example:

1.6/1.7, consistent, stays the same across patching:

alternatives --set java /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
alternatives --set java /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java

1.8, inconsistent from other Javas, changes every time there is a patch if I want to stay current:

alternatives --set java /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64/jre/bin/java

There needs to be a /usr/lib/jvm/jre-1.8.0-openjdk.x86_64/bin/java registered with alternatives that always points to the latest installed OpenJDK 1.8.

Thinking about it in terms of automation, the 1.6.0 or 1.7.0 can be replaced with a variable, but 1.8.0 throws a wrench in things.

Comment 35 jiri vanek 2015-07-30 16:25:03 UTC
Created attachment 1057738 [details]
suggested patch v01

So here is the patch with hardcoded symlinks.
packages for playing are here: http://download.eng.brq.redhat.com/scratch/jvanek/1217177/v01/

One confession: as we are speaking here about appearence in alternatives, I have used for those symlinks (jre-1.8.0-openjdk and java-1.8.0-openjd)  targets of _jvmdir/NVRA/jre/bin and _jvmdir/NVRA/bin

It is not same as 7 and 6, where they 
_jvmdir/N/jre/ and _jvmdir/N/ is used
I did so bause I have already existing macras for bin, but not for seconds. Ican fix it too if needed.

I have not attempted to install those packages on scratch, but breef looking inside says that thay have intended changes inside.

Comment 39 jiri vanek 2015-07-31 11:53:01 UTC
Created attachment 1058034 [details]
patch 3

update:

http://download.eng.brq.redhat.com/scratch/jvanek/1217177/v02/

now everything (exceppt priority) should be ok.
The packages have broken link of jre-1.8.0-openjdk -> /usr/lib/jvm-exports/java-1.8.0-openjdk-1.8.0.51-3.b16.el6.x86_64-debug ( I did not declare the new lins macros exapndable...)
and forgot arch:-/

The patchshould have it fixed (but the build is just running

Comment 40 jiri vanek 2015-07-31 11:56:26 UTC
Created attachment 1058035 [details]
patch4

missing } in patch3

Comment 41 jiri vanek 2015-08-04 15:05:05 UTC
http://download.eng.brq.redhat.com/scratch/jvanek/1217177/v04/

and related builds. Again, not yet tested, but worthy to try 9especially for Lukas)

Comment 44 jiri vanek 2015-08-13 14:18:02 UTC
Created attachment 1062613 [details]
patch5

builds avaiable in http://download.eng.brq.redhat.com/scratch/jvanek/1217177/v05/

Yup. Now I have error during erase too:
/usr/lib/jvm/java-1.8.0-openjdk.x86_64/javac has not been configured as an alternative for javac
DEBUG util.py:377:  /usr/lib/jvm/jre-1.8.0-openjdk.x86_64/java has not been configured as an alternative for java
DEBUG util.py:377:  warning: %postun(java-1.8.0-openjdk-headless-1:1.8.0.51-3.b16.el6.x86_64) scriptlet failed, exit status 2
DEBUG util.py:377:  Non-fatal POSTUN scriptlet failure in rpm package 1:java-1.8.0-openjdk-headless-1.8.0.51-3.b16.el6.x86_64

and yes, alternatives really are not removed.

(/me work in progress)

Comment 45 jiri vanek 2015-08-13 14:22:25 UTC
it is clearly typo :(

  --install %{_bindir}/java java %{jre_versionless_lnk %%1}/bin/java %{priority} \\
  --install %{_bindir}/javac javac %{sdk_versionless_lnk %%1}/bin/javac %{priority} \\

versus

alternatives --remove javac %{sdk_versionless_lnk %%1}/javac
alternatives --remove java %{jre_versionless_lnk %%1}/java

shouldbe of course 

alternatives --remove javac %{sdk_versionless_lnk %%1}/bin/javac
alternatives --remove java %{jre_versionless_lnk %%1}/bin/java

Comment 46 jiri vanek 2015-08-14 09:01:56 UTC
Created attachment 1062937 [details]
patchg6

All should be ok now.
http://download.eng.brq.redhat.com/scratch/jvanek/1217177/v06/

Btw - change from NVRA to versionless N only fixed indirectly also  the  https://bugzilla.redhat.com/show_bug.cgi?id=1251560. But it does not mean that 1251560 stopped to be bug.

Comment 47 jiri vanek 2015-08-14 09:24:13 UTC
Ok.. there is one more issue.... I knew why I was so afraid of this change:

-update-alternatives --install %{_jvmdir}/jre-%{javaver}-%{origin} jre_%{javaver}_%{origin} %{_jvmdir}/%{jrelnk %%1} %{priority} \\
---slave %{_jvmjardir}/jre-%{javaver}       jre_%{javaver}_%{origin}_exports      %{jvmjardir %%1}
+#update-alternatives --install %{_jvmdir}/jre-%{javaver}-%{origin} jre_%{javaver}_%{origin} %{_jvmdir}/%{jrelnk %%1} %{priority} \\
+#--slave %{_jvmjardir}/jre-%{javaver}-%{origin}       jre_%{javaver}_%{origin}_exports      %{jvmjardir %%1}
+#removed in favor of hardcoded link rhbnz#1217177

and

-update-alternatives --install %{_jvmdir}/java-%{javaver}-%{origin} java_sdk_%{javaver}_%{origin} %{_jvmdir}/%{sdkdir %%1} %{priority} \\
---slave %{_jvmjardir}/java-%{javaver}-%{origin}       java_sdk_%{javaver}_%{origin}_exports      %{_jvmjardir}/%{sdkdir %%1}
+#update-alternatives --install %{_jvmdir}/java-%{javaver}-%{origin} java_sdk_%{javaver}_%{origin} %{_jvmdir}/%{sdkdir %%1} %{priority} \\
+#--slave %{_jvmjardir}/java-%{javaver}-%{origin}       java_sdk_%{javaver}_%{origin}_exports      %{_jvmjardir}/%{sdkdir %%1}
+#removed in favor of hardcoded link rhbnz#1217177


but  still doing
alternatives --remove jre_%{javaver}_%{origin} %{_jvmdir}/%{jrelnk %%1}
and
alternatives --remove java_sdk_%{javaver}_%{origin} %{_jvmdir}/%{sdkdir %%1}

I guess removal  is ok.. running another build

Comment 48 jiri vanek 2015-08-14 12:05:19 UTC
Created attachment 1062996 [details]
patch7

http://download.eng.brq.redhat.com/scratch/jvanek/1217177/v07/

no warnings.. looks finally ok...

Comment 49 jiri vanek 2015-08-17 12:07:25 UTC
Fixed like it:
http://pkgs.devel.redhat.com/cgit/rpms/java-1.8.0-openjdk/commit/?id=2cec25c812ba879ceb434925562bb3df7718f851 
and built:
https://brewweb.devel.redhat.com/buildinfo?buildID=452468

for rhel 6.8

I'm recommending to suggest this bugfix as Z stream update for 6.7

Comment 51 jiri vanek 2015-09-04 10:42:04 UTC
Hello.

There have been small change due to https://bugzilla.redhat.com/show_bug.cgi?id=1259241

I had to add arch also to 32 links.

SO now it is:
64b system:
 + 1           /usr/lib/jvm/{jre,java}-1.7.0-openjdk.x86_64/bin/java
   2           /usr/lib/jvm/{jre,java}-1.8.0-openjdk.x86_64/java

but 32 systems:

 + 1           /usr/lib/jvm/{jre,java}-1.7.0-openjdk/bin/java
   2           /usr/lib/jvm/{jre,java}-1.8.0-openjdk.i386/java


Is it still ok with everybody?

Comment 52 Jason Bradley Nance 2015-09-08 14:23:31 UTC
Is it just a typo that the "bin" is missing from the path for the 1.8.0 versions?

Comment 53 Lukáš Zachar 2015-09-08 16:01:22 UTC
Missing /bin/ is typo. However the additional .i386 is real and necessary.

On 32 bit:
*+ 1           /usr/lib/jvm/java-1.7.0-openjdk/bin/javac
   2           /usr/lib/jvm/java-1.6.0-openjdk/bin/javac
   3           /usr/lib/jvm/java-1.8.0-openjdk.i386/bin/javac
-----------------------------------------------
*+ 1           /usr/lib/jvm/jre-1.7.0-openjdk/bin/java
   2           /usr/lib/jvm/jre-1.6.0-openjdk/bin/java
   3           /usr/lib/jvm/jre-1.8.0-openjdk.i386/bin/java


On 64 bit:
   1           /usr/lib/jvm/java-1.8.0-openjdk.x86_64/bin/javac
   2           /usr/lib/jvm/java-1.6.0-openjdk.x86_64/bin/javac
*+ 3           /usr/lib/jvm/java-1.7.0-openjdk.x86_64/bin/javac
-----------------------------------------------
   1           /usr/lib/jvm/jre-1.8.0-openjdk.x86_64/bin/java
   2           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
*+ 3           /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java

Comment 54 Jason Bradley Nance 2015-09-08 21:24:19 UTC
My needs are only for 64-bit, so for me this is just academic, but why doesn't the 32-bit have .i386 for OpenJDK 6 and 7 when the 64-bit has .x86_64?  I guess this is akin to a "lib vs lib64" argument.

I don't have permission to see 1259241 so I can't comment further on the relationship there.

Comment 55 jiri vanek 2015-09-09 08:58:31 UTC
(In reply to Jason Bradley Nance from comment #52)
> Is it just a typo that the "bin" is missing from the path for the 1.8.0
> versions?

YEs it is. Luaks, ty for full print out.

(In reply to Jason Bradley Nance from comment #54)
> My needs are only for 64-bit, so for me this is just academic, but why
> doesn't the 32-bit have .i386 for OpenJDK 6 and 7 when the 64-bit has
> .x86_64?  I guess this is akin to a "lib vs lib64" argument.
> 
> I don't have permission to see 1259241 so I can't comment further on the
> relationship there.

I made it accessible.

Generally speaking, the aggressive postu scripts are removing all java-1.8.0-openjdk and jre-1.8.0-openjdk links.

So after update we were facing missing java/javac on 32b - because on 64b the link (now newly hardcoded link) was java-1.8.0-openjk.x86_64

Another solution would be recreating those links in posttrans, but it is somehtng I would like to avoid at all cost.


The fix to provide rhel-6 like names was only  for this bugzilla, so I hoped 32b inconsistency will be "academic only".  Also removal ov various ifarchs in favour of arch substitution really made package better. 

So unless somebody wil be strictly affected, I would like to keep this way.

Comment 66 errata-xmlrpc 2016-05-10 21:03:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0816.html


Note You need to log in before you can comment on or make changes to this bug.