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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
