On Thu, 2015-02-26 at 09:00 +0100, Jiri Vanek wrote:
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.
Indeed, and for that you need to go to an OS that supports long term
stability, like RHEL or Centos (playing in house, but you have other
choices). Fedora is not really good for that, since it promotes bleeding
edge code over long term stability.
Cheers,
Mario