How do I install 2 different versions of java on the same machine from EPEL
Solution 1:
You don't. Upgrade to the later package, which has fixes.
java-latest-openjdk 14.0.2.12-1 replaces 14.0.1.7-2. EPEL mirrors won't carry the old version, as is their usual policy.
The upstream release notes say the security patched version of 14 is 14.0.2+12. Note the usual time zone data and x509 cert changes, plus bug fixes. Think about whether you really need to pin this version. The documentation indicates this to be a minor maintenance release you are intended to take.
If you identify a need to keep the previous version, two problems to resolve: getting the package and installing it. The old version is no longer on the mirrors, consider setting up your own private mirror or caching proxy to archive old versions. And, these two versions cannot be installed in parallel. Investigate a way to have two parallel environments, whether containers, virtual machines, or runtime manager utilities which specifically allow you to select a Java runtime.
Solution 2:
Short answer: Use a java runtime manager such as SDKMAN! or jEnv
Long answer: By default, package managers are trying to help keep up to date with the latest version of the packages in your system. This is why it is common to find alternative package managers like the above for different languages (pyenv or conda for python, nvm for node/js, etc).
You mention this is for EPEL which might mean you are restricted on the internet access. This might be an issue. In general though these alt package managers are installed in the user session and the environment variables controlled affect only the current user. This might be an advantage or disadvantage depending on what exactly you are working on.
Without more information I think using the existing tools mentioned above (btw there might be newer ones) might be a good place to start. Feel free to add more info if needed and good luck!
Solution 3:
This is one of the primary use-cases for Docker, in which a container can contain differing supporting libraries and/or differing application versions in their own isolated environments without the overhead and complexity of virtualization.
In the simplest Dockerfile, once could source a CentOS or RHEL base image, add repositories, and install the packages you want.
It matters what the use-case is here, and if the goal can be expressed via containers. In most cases, it can be. Here's an example dockerfile:
FROM centos
RUN yum update -y
RUN yum install -y epel-release
RUN yum install -y java-14-openjdk-14.0.1.7-2.rolling.el7.x86_64
ENV JAVA_HOME /etc/alternatives/jre
WORKDIR /app
EXPOSE 8080
CMD [run.sh]
That last block is almost entirely made up, but is valid. If you can express your application as a microservice, this docker-based solution can make a lot of sense.
Otherwise, you can accomplish similar results with an LXD container, with the exception that you can expose an entire IP (much like a VM). You could also use a VM. Both are more complex than a docker based solution that exposes a single IP/port combination per application.