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

Tue Feb 24 19:36:01 UTC 2015

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.

-- 
Regards,
Sumit Bhardwaj 

On Tue, 2015-02-24 at 18:22 +0100, Mikolaj Izdebski wrote:

> On 02/24/2015 05:21 PM, Mario Torre wrote:
> > On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote:
> >> On 02/24/2015 02:15 PM, Jiri Vanek wrote:
> >>> On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote:
> >>>> I am against official guidelines or policy for legacy JDK packages. I
> >>>> don't think that any such policy is needed and it would only encourage
> >>>> adoption of old packages for which there might be no security updates.
> >>>
> >>> Well thats the point - people are calling for them. And wont to maintain
> >>> them with this risk.
> >>
> >> I thought that the point of this change proposal was "enabling community
> >> to maintain legacy JDKs", not encouraging people to package them without
> >> good reason or without involvement to truly maintaining them. Packaging
> >> older JDKs is *already* possible, so IMHO this change accomplishes
> >> nothing but showing people how they can dump old, unmaintained software
> >> into Fedora.
> > 
> > Well, in this case it would not be un-maintained, the Fedora package
> > would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we
> > are still actively contributing to the upstream software in its various
> > versions. While you as a packager cannot specifically count on that,
> > there's still a level of confidence that the base software won't be
> > abandoned any time soon. And even when we will stop supporting those
> > older versions, the community will take over if there is a need for
> > that, exactly like we have done ourselves before.
> > 
> > Indeed, there's an overhead for the downstream maintainers, we may need
> > to drop specific version of OpenJDK, or skip a release, or do other
> > funny things and the Fedora maintainers will have to adapt, but this is
> > no different than usual I believe. Realistically, we are so conservative
> > with older JDKs that I doubt this will ever really be an issue.
> 
> Correct me if I am wrong, but in my understanding maintaining JDK
> package requires a lot of ongoing work (including obtaining and applying
> patches, running TCK, pushing updates in timely manner and so on). JDK
> maintainers should know this and I'm assuming that the amount of
> required work is the main reason for them not wanting to maintain older
> JDKs.
> 
> The work required to add old JDK package to Fedora is relatively small
> compared to ongoing maintenance work. Someone willing to truly maintain
> JDK in Fedora should have knowledge about JDK packaging and they
> shouldn't have problem finding time to come up with a working solution,
> proposing and discussing it.
> 
> If you make the process of adding legacy JDKs to Fedora too easy then
> someone without enough time and required knowledge will surely do that
> and we may easily end with unmaintained package. I'd rather not have old
> JDK than have unmaintained JDK with security holes.
> 
> >> Package that doesn't pass review shouldn't be part of Fedora.
> > 
> > Well, if your goal is to reduce the user base of Fedora, I'm sure we can
> > talk about removing the JDK :)
> 
> We can't sacrifice our basic principles (such as passing review) for the
> sake of increasing user base.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150225/7154043b/attachment.html>