Use "tarball" or "archive bundle" throughout the guide

[ncbaratta]

QE by @judovana

1.2. Installing the Java Development Kit with the archive bundle on Red Hat Enterprise Linux

Download the JDK ZIP bundle of OpenJDK 11 for Windows.

• why should customer download windows binary zip for RHEL? They should be able to use normal JDK tarballs we provide…. (I am unable to access that binary via the portal, but I assume the link is correct). By the way, are you sure about the zips? As far as I know, we provide tarballs, not zips for RHEL.

Step 4:

This does not work as you expect. If you append your links at the end of path variable, you are risking, your “javac -version” command to return the default jdk instead of the tarball installed jdk, if you use it like this, because you are appending it in the path input (entering it at the end). If there is a java installed (any java), the output will be taken from the system java (or any other link you put there in the meantime).

Customers should be aware, what the path command does and that they are messing with system settings they need to know how to reverse.

Step 5.
This will pick up whatever jdk is default, which could be 11, but also could be ojdk8.

Step 6.
In order to persist the PATH variable setting use these instructions: <add-link-to-RHEL-bashrc-path-link>
Missing link I assume?

Step 8.
Why are you unpacking the JDK in home and then assign the variable from the /opt/? Won’t the directory be empty? Or shouldn’t you unpack it in opt if you want to link it from opt?

In general, this setting of JAVA_HOME variable applies also to our packages, they do not export this variable either afaik

[jerboaa]

1.2. Installing the Java Development Kit with the archive bundle on Red Hat Enterprise Linux

Download the JDK ZIP bundle of OpenJDK 11 for Windows.

* why should customer download windows binary zip for RHEL? They should be able to use normal JDK tarballs we provide…. (I am unable to access that binary via the portal, but I assume the link is correct). By the way, are you sure about the zips? As far as I know, we provide tarballs, not zips for RHEL.

@ncbaratta These are issues to do with attributes definitions, which define {archive} as ZIP and {comp} as OpenJDK 11 for Windows.

Step 4:

This does not work as you expect. If you append your links at the end of path variable, you are risking, your “javac -version” command to return the default jdk instead of the tarball installed jdk, if you use it like this, because you are appending it in the path input (entering it at the end). If there is a java installed (any java), the output will be taken from the system java (or any other link you put there in the meantime).

Good point. We need to figure out what we actually want to recommend in docs first.

Customers should be aware, what the path command does and that they are messing with system settings they need to know how to reverse.

Step 5.
This will pick up whatever jdk is default, which could be 11, but also could be ojdk8.

Step 6.
In order to persist the PATH variable setting use these instructions: <add-link-to-RHEL-bashrc-path-link>
Missing link I assume?

Yes, missing link. Not sure whether or not such a doc exists.

Step 8.
Why are you unpacking the JDK in home and then assign the variable from the /opt/? Won’t the directory be empty? Or shouldn’t you unpack it in opt if you want to link it from opt?

We need to standardize on a path so that this will work (it's actually included from a snippet). Once we know which path we want to recommend, it should be easy to fix.

In general, this setting of JAVA_HOME variable applies also to our packages, they do not export this variable either afaik

Clarification: our packages == RPM packages. Yes, true. Do you suggest to remove the recommendation of setting JAVA_HOME everywhere? Add it to instructions of installing the RPM packages, instead?

[ncbaratta]

@robin-owen any ideas on how to address the attributes issues?

[jerboaa]

@ncbaratta Wouldn't this be solved by separating the 4 books ({8,11} x RHEL,WINDOWS} with different attributes each. Am I missing something?

For example:
JDK 8 RHEL: archive => tar
JDK 11 Windows: archive => zip
etc.

[ncbaratta]

It would but then we have 4 attributes files to maintain. I think it makes more sense to use branches and have one for OpenJDK 11 and one for OpenJDK 8 and then 2 books per branch. I want to think of all the possibilities and make sure we choose the best one.

[jerboaa]

Makes sense.

[kowen-rh]

It would but then we have 4 attributes files to maintain. I think it makes more sense to use branches and have one for OpenJDK 11 and one for OpenJDK 8 and then 2 books per branch. I want to think of all the possibilities and make sure we choose the best one.

This is what makes the most sense to me, as well, and would be my suggestion. As much as possible, I'd like to reduce the overhead of maintaining multiple attribute files.

[jerboaa]

Changed assignee as this is now a consistency issue.