F22 System Wide Change: Legacy implementations of the Java platform in Fedora

[Jiri Vanek]

On 02/24/2015 08:36 PM, Sumit Bhardwaj wrote:
> Hi All,
>
> I have been reading this mail chain for some time and there is something I wanted to say. It's kind
> of a long mail, I apologize for taking so much of your time but request you to please bear with me.
> I work as a technical consultant on IBM WebSphere, IBM BPM, Java/J2EE and Python technology stacks,
> who has to code on Java/J2EEquite often as well and I use Fedora 21 Workstation as my primary OS. My
> field of work is such that I need to use JDK versions 1.4, 5, 6, 7 and 8, all from time to time.
> This is because as time passed, solutions delivered to customers were built using incremental
> versions of Java/J2EE specifications and were not frequently upgraded. In my role, the changes/fixes
> I do to these enterprise apps are usually small and require only a certain jar file to be
> recompiled, or in some cases only one class. In such cases, maintaining binary compatibility is a
> must and for that I need to recompile that one jar/class with the original version of JDK that was
> used to compile the rest of the project in the first place.
>
> I use Oracle java in most cases due to corporate policies (for personal use, I use the latest
> version of OpenJDK). Now as per Oracle's policy, which I am sure is similar for OpenJDK as well, a
> particular version of JDK/JRE is updated till and even some time after the next major version is
> released, and then at a certain Update level, Oracle stops supporting it. That update version
> becomes the final update for that particular major release, and is sent into archives, while updates
> keep on getting released for the current version.
>
> With Oracle JDK, there are two installation approaches available for RPM based systems. They provide
> an RPM package which installs java in /usr/java, i.e. in system area and the latest installed java
> version become default. However, they also provides tarballs of JDKs, that contain certain standard
> directory structure of JDK  intact inside one folder. These tarballs can be extracted and placed in
> any place on file system and once JAVA_HOME is pointed towards these+PATH is locally updated to
> include it, user can basically use this JDK without any issues. What version of Java is installed in
> system as default, in system area (/usr/java) become irrelevant.
>
> With IDEs like Eclipse and NetBeans the process is even simpler, as you can define these individual
> folders as JDKs for particular API versions in IDE configuration permanently and while creating a
> project can choose to use any of these "defined JDKs". This is the approach that I take. I have the
> last updated versions of all the JDKs from 1.4 to 8 in my /opt folder. I have these configured in
> Eclipse and NetBeans for each API version and I use them all as required by the project.
>
> So I guess if OpenJDK can follow the same approach and can give an option to download tarballs of
> older versions and use them in place, without requiring any installation, as a definite directory
> structure, then the problem is solved. There is no need to maintain old version per se in
> repositories, as these are not updated anymore and the user will be able to use multiple versions
> without conflict of any kind. As for the default JDK, it can be kept how it is now i.e. The latest
> available JDK can be maintained in Fedora repos as they are being maintained now and updates can be
> provided for the defined lifetime of that JDK.
>
> Let me know what you guys think about this approach.
>

This is lying on  openjdk table for long time to have  at least source tarballs... As you can see, 
nothing,.  However  once you are able to build jdk on your own,  nothing prevents you form mercurial 
clone of *any* version. So this is the way you should go.

If you wont binary images to be supported by openjdk itself, its completely different and more 
complex story.


J.