JDK-8191608 : Java RPMs should allow for side-by-side installation of JDK and JRE, 32 and 64 bit, and only one update for each major version
  • Type: Bug
  • Component: install
  • Affected Version: 7u161,8u151
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-11-20
  • Updated: 2022-06-17
  • Resolved: 2017-12-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u161Fixed 8u152Fixed
Related Reports
Blocks :  
Blocks :  
Relates :  
Relates :  
Sub Tasks
JDK-8201823 :  
JDK-8203331 :  
Description
There is a property in the RPM package, lets call it “name”, that determines whether, when you apply a new patch, the patch overwrites an existing package or wether it installs “side-by-side”:

Before 8uSomething all Java RPM packages were called “Java SE” (Or “JDK" or something like that.. the important thing is that ALL had the same name).

So:

    JRE 7u80 32 bit -> “Java SE”
    JDK 8u101 64 bit -> “Java SE”
    JRE 7u95 64 bit -> “Java SE”


So if you tried to use “yum update” you could only have 1 flavor.  If you needed say “the latest 7 AND the latest 8” you couldn’t use “yum update” for one since it would overwrite all others.   You could always use the tar.gz and do whatever you wanted but you couldn’t use yum.

With 8uSomething, requested that we allow “side by side”.

We changed then to have the packages include the version number so:

JRE 8u101 -> “Java SE 8u101”
JRE 8u131 -> “Java SE 8u131”

Not sure if the change also went to 7 and 6 but that was done for 8 at least.

Now you could have “side by side” of 7 and 8.. but also if you “updated” from 8u101 with 8u131 you would not “overwrite” 8u101 but keep 8u101 AND 8u131.

We also used “Java SE <version>” for both JDK and JRE, 32 and 64 bit so you can’t use “YUM install” for 8u131 32 bit AND 8u131 64 bit as they would overwrite each other. 

  Allow “side-by-side” of different packages (JDK vs JRE), different bitness (32 vs 64) and different major/feature versions (e.g. 7, 8, and 9) but within a “major/feature - package - bitness” combination one should overwrite.

E.g.
Have the “names” be “<JDK|JRE> <Major> <Bitness>”

In our previous examples: 

JRE 7u80 32 bit -> “JRE 7 32 bit”
JDK 8u101 64 bit -> “JDK 8 64 bit
JRE 7u95 64 bit -> “JRE 7 64 bit”

They can all live together side by side happily.

If you go and get  JDK 8u141 64 bit it would also be “JDK 8 64 bit” so it would overwrite JDK 8u101 64 bit but leave the other ones alone.

That was the primary request.  JDK-8189805  completed this, for 9,8,7, and 6 


Secondary request: 

Since you might have JRE 7, 8, and 9 in the same machine use the “alternative” mechanism (I dont’ understand this completely but seems like you can create some symlinks to assign the “default” version) for choosing which version you use if you don’t call out exactly one.

That request WAS NOT completed by JDK-8189805 .   This was a “good to have” so its not a deal breaker.

Comments
Verified by 8u171 b01 promoted bundle http://aurora.us.oracle.com/functional/faces/RunDetails.xhtml?names=2436798.ManualSubmit-1
15-01-2018

If this one is being targeted for the April CPU, the 18_01-critical-watch label can be removed I believe. Victor, could we do that?
18-12-2017

CPU18_04-critical-request - Justification : This is critical for Cerner customer - Risk Analysis : Low. This change modifies name of jre/jdk installation directory. No functional impact. - Review : https://java.se.oracle.com/code/cru/CR-79 - Testing (done/to-be-done) : to be done by SQE - Back ports (done/to-be-done) : done to jdk7cpu - FX Impact : NA - Fix For Release : 8u, 7u
16-12-2017