FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

 customer  7.1
i386

ADDITIONAL OPERATING SYSTEMS :
The error is in the RPM, not the OS


A DESCRIPTION OF THE PROBLEM :
Java is not being installed according to the Linux Standards
Base. No effort is made to designate files in the RPM as
documentation or configuration. Shareable files(docs,
examples, manpages, are not separated from unshareable
files(binaries) but instead dumped in a big directory
containing all java1.4 related files. no effort is made to
include java in the standard path. The manpages are copied
into a manpage location, a hard or softlink would suffice.
Solution would be to read the Linux Standards Base, esp the
Standard Filesystem Hierachy, and install the software
accordingly. The way it is now is considered bad practice
and uses none of the benefits the RPM system offers.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.rpm -ql j2sdk-1.4.0-fcs
2.rpm -ql --scripts j2sdk-1.4.0-fcs
3.rpm -ql -c j2sdk-1.4.0-fcs
4.rpm -ql -d j2sdk-1.4.0-fcs

EXPECTED VERSUS ACTUAL BEHAVIOR :
read description, LSB etc.
everything is now in one directory, should be in separate
directories (shared/not-shared, variable/static). For
example look at the output of " rpm -ql kaffe-1.0.6-3" (that
is, if kaffe is installed, which would probably not be the
case at sun) J2sdk en J2jre should replace kaffe, and
earlier versions  of itself.

This bug can be reproduced always.

CUSTOMER WORKAROUND :
make links to correct locations after install. This thwarts
RPM, but it is not used effectively now anyway.
(Review ID: 146060) 
======================================================================
Posted Date : 2006-03-14 21:32:13.0

N/A

This is an excellent suggestion and will be considered for one of our upcoming
releases.
  xxxxx@xxxxx   2003-01-20

Defer to future releases.

  xxxxx@xxxxx   2004-11-23 20:53:58 GMT

A substantial fraction of the developer concerns mentioned
in the JDC comments will be addressed by a different J2SE 6.0 feature,
#6211006 (Default Java on Linux).  That will at least solve the "how do I find java" problem, i.e., after installing a JRE rpm you'll get a /usr/bin/java that
points to something reasonable.

The remaining issue of purity-according-to-the-LSB can be split into a
couple of pieces.  There's the desire to make /usr be read-only, which is
a fine goal, and would merely require us to push mutable state off into
/var/lib/java or some such.  That doesn't seem like it needs to be a
priority for Mustang, but we should think about it for the longer term.

There's also the desire to nuke /usr/java because it's not officially
blessed but, as others have noted, due to binary compatibility
constraints we're highly unlikely ever to support that.  If the LSB can
bless /usr/X11R6 then they should be able to bless /usr/java.

  xxxxx@xxxxx   2005-03-23 09:46:31 GMT

This note is totally on the ball. The RPM shipped by Sun is
very poor indeed, and might as well be a tar ball. 

The sad thing is that someone else
(http://jpackage.sourceforge.net) has already done all the
hard work, but Sun's licensing conditions make getting hold
of these hard. 

This really needs to be sorted out badly. Because of Sun's
poor RPM, java applications and libraries are generally a
pain to install, and I've wasted a lot of time doing this. 

I can only say I totally agree with what's just been said.
.
And the problem is not limited to the jvm. Lots unavoidable
java parts from Sun (jaf, javamail) are lacking proper Linux
packaging and somehow people that care outside of Sun
(jpackage) are prevented from distributing proper java
packages because of Sun licensing.
.
While I understand Sun wanting to keep some sort of control,
it would help java advocacy a lot if Sun distributed useable
forms of the software it wants to keep control of.

I do agree with that
I would like to see a better designed rpm 

For packaging ideas/examples, see http://www.jpackage.org/

I hope to see a better rpm soon.

Actually the JPackage.org project has made all the work for
you. All you have to do is collaborate with them.

In response to the Evaluators comment and numerous user
comments. JPackage has really got the ball rolling in terms
of RPM packaging of Java tools. LSB and FHS are "Critical"
for more simplified managment and installation of Java
packages on Linux. This is turning out to be a "neccessity"
for developers, deployers and administrators. We really need
this sort of invation ASAP to stay competative. 
Now, this packaging is quite independent of the actual java
development, this sort of inovation shouldn't be dependent
upon j2sdk version release schedules. JPackage has already
provided the base, all that remains now is adoptation by
vendors to provide stable and standardized installation of
JVM's. An rpm for 1.4.2 could even be provided today by Sun
simply by rpm building JPackages nosrc rpm for the sun j2sdk
and releasing it as an alternative download option.

Personally, I have no qualms about clicking a web page
license agreement prior to installing an RPM. Its when
standard "rpms" are "wrapped" in non-standard installation
scripts that I find problematic and unvaluble. Not burying
an rpm under such scripts is neccessary for proper
dependency resolution to be supported by rpm  and utility
wrappers like apt, urpmi and yum.

Please work with jpackage at make it simple for everybody! 

This is a huge huge pain. The jpackage stuff makes life so
much easier, but in the mean time I still have to install
jpackage, grab the linux .bin file, and use a srpm from
jpackage to sort things out -- such a waste of time! Please fix.

Please have this fixed ASAP. It isn't much effort. The
current affair of things
is pretty sad: people will complain that Java and Java
programs are a royal
pain to install - and rightly so. Why make things more
complicated than they
need to be? This only gives ammunition to those who want to
quickly
dismiss Java as garbage.

May I suggest you you to take a look at jpackage java rpm 
layout ? This project works hard to provide qn impressive list 
of java stuff in rpm format which make life easier for 
developpers and admins on RH/MDK/Suse.
They also make great works in packaging SDK in a FHS 
compliant way. A definitive project for Java and RPM based 
systems

Please vote for this bug if you're using Java on Linux... ;)

Correcting the rpm would not only help Java users, but would
bolster the drive for LSB compliance, benefitting Linux
users in general.

It would be great if sun could release a fsb compliant rpm.
Next it would be good, if it would follow the rpm packaging 
standards (http://www.jpackage.org) or change the license
enabling jpackage to redistribute a rpm package without 
fearing layers (GPL, LGPL, BSD (?), Apache.....)

Inclusion of a LSB JDK or JRE in Fedora Core is a must have
for the near future. 

(Against my will) I shall begin to consider a serious turn
towards .NET technologies to develope web applications if
this issue stays unresolved much longer. People at the
Apache Foundation  are doing a great job with the JAKARTA
Project, but it becomes seriously handicapped because of all
the unnecessary awkwardness to install and mantain them
properly on unix platforms. 

So does my keen proselytism of Java+Linux. My clients do
want it fast & easy, and look unconfident towards Linux.
"Well, It's Java, we can always run it on Windows". And they
end up porting ALL their projects to Windows for the sake of
consistency. 

...you didn't make JAVA to run 'only' on Windows, did you?

Please, do something !!!

Will this be updated for the Tiger linux RPM?  

Has anyone from Sun looked at JPackage?

Please do more than consider this request: please implement it!

Sincerely,
A Linux user

Hm, I'm wondering about Sun's ability to fix bugs. The
initial bug report is dated May, 2002. 2002!  It's 2004 now.
 And it's quite easy to fix it. All preliminary work has
been done by jpackage.org under GPL. Could have been adopted
by Sun.

A widely accepted installation standard will definitely
support the acceptance of Java as a programming language and
the acceptance of Java programs.

I (also) hope that Sun would co-operate with jpackage
project to support more maintainable java systems.

I also encourage Sun to co-operate with JPackage
project in order to support more maintainable java systems.

I was _very_ dissapointed when I found out  how much work
(still ongoing) it took to get  a working tomcat5 from
Jpackage, Sun's licencing policy nullifies very efficiently
the advantage of  dependency-solving package-managers such
as yum and apt. I greatly  appreciate the work done by the
people behind Jpackage, but give a big F- to Sun for their
inability to understand the consequences of their choice. It
may have been normal to build a production server by
downloading manually  dozens of source-packages and then
compile them, but we are not living in the stoneage anymore.

This was an excellent idea a year ago, so how long 
must we wait?  I can personally vouch for digging 
through SUN's site on five different occasions to 
download an odd half-dozen or more products only for 
repackaging with JPackage.  

Please be kind to your developers / deployers.  
Consider the burden of lost man hours (and greater 
expense) placed on JAVA's supporters by not 
embracing this resource.

See http://www.jpackage.org/ for good ideas.

sun shoul do a lot more to help the open source 
movement

A better synopsis for this bug would be ``Sun's RPM
packaging of Java is not compliant with LSB's filesystem
hierarchy standard''.

This problem affects more than, as is suggested by its
description, Red Hat 7.1.  It affects all RPM-based
GNU/Linux distributions.

Also, though it is common to informally refer to RPM
packages as ``RPMs'', RPM is the RPM Package Manager, not a
package, so referring to files within Sun's RPM packages as
``files in the RPM'' is technically incorrect.

Note that the Filesystem Hierarchy Standard (FHS;
<http://www.pathname.com/fhs/>) is now part of Linux
Standard Base (LSB; <http://www.linuxbase.org/>).

Yes, this would simplify dramatically using java in Linux.
Jpackage has done a lot of work, it is just missing this 
last step.
I hope this will be done soon.

Best regards.

This should not be marked an enhancement, but a bug.

If I fail to use standard weights and measures in my design
diagrams, it's hardly an enhancement to correct them.  Sun
should be following the established standards for package
layout on the platforms they target for deployment.

This cripples JAVA on the Linux platform.  It reduces the
maintainability of the JRE / SDK to that of near tarball
management.  It complicates the launching of the JVM, and
requires manual PATH editing (mangling) and environmental
variable work arounds to find the appropriate executables
and libraries.

Please raise the priority of this BUG.

I would submit that it is high time for this BUG to be corrected, as numerous others have done.

If the evaluator is not willing to consider the comments on this bug, at least consider the consequenses for Sun's own paying customers.  Is not Sun Java Desktop Sytem and RPM-based Linux OS featuring Java, which ought to be striving for LSB compliance?  Well then, make the j2sdk compliant, and not only will your grass-roots supporters be happy, but your customers will too, when they want to upgrade to java 1.5...

It's only a technical change, no licensing involved, and no need to consider stupid "open source" entreties from Eric Raymond and the like...

Come on guys - this bug has been open for over two years and as other commenters have pointed out, jpackage have done the work and want to contribute the solution back to Sun.  This is the very reason that Java developers are calling for Java to be open sourced - Sun seem to be unable to apply even easy fixes for bugs and enhancements in an acceptable time frame (days is acceptable, years is not).

Sun says they won't open source java because they are afraid that might break compatibility between versions. The reason behind LSB and FHS was exactly to keep compatibility between linux versions. If you are really concerned about compatibility then you should at least make sure java itself are compliant with the standards that exist.

On Windows, the Sun packages for Java follow the Windows conventions for installation.  On Solaris, the Sun packages for Java follow the Solaris conventions.  On Linux, the Sun packages for Java ... follow no accepted convention.  While Sun does provide an RPM package for Java, the package does not follow the Linux Standard Base, which is *the* standard for packaging applications for Linux, and works on *all* major Linux distributions.

Take a hint from JPackage -- they've already done the work for you.  Just download their RPM .spec file and use that.  They've only been begging Sun to use their work for how many years?

It would be nice if java was as easy to install as other apt-get:able software. 

Please act on this bug.  Please!

I'm installing Tomcat on a Linux server right now
and the j2sdk part was a pain in the neck.

Please fix your RPMs or allow the jpackage
people to distribute RPM binaries.

Please fix this. It's been opened for too long.

In fact, why not let people like jpackage redistribute JDK freely? What's the harm?

3 YEARS!!!!! Come on people.  You always claim java is not slow, but your BUG FIXES sure are.  Get off your high horse and release a jpackage compatible RPM already.

Fix this please.

We're approaching *three years* on this one, and Sun is saying ``we should think about it for the longer term''?  Give me a break.

Regarding the evaluation comment, ``If the LSB can bless /usr/X11R6 then they should be able to bless /usr/java.'':  That is ridiculous.  X11 has been a part of GNU/Linux from (essentially) the beginning.  Java does not have similar status.

If ``binary compatibility'' was really of any concern to Sun, this issue would have been resolved years ago.

This really need to be fixed!

Forget official blessings, you're telling us that since the standard isn't what you picked, then the standard should change to fit your tastes.  In that case, SUN still needs to coordinate with the linux standard base and implement a distrobution of JAVA that is manageable.

Repackaging of JAVA (jpackage) makes it more manageable, but creates ethical / legal dilemmas that everyone wants to avoid.  If i repackage and then distribute internally to my production environment, am I at fault?  Only expensive layers know for sure, but putting extra manpower to repackage each time on each production machine is obviously legally ok.  This is silly as it implies that it's fine with SUN if I download thier JAVA (authorizing each download individually) but questionable if I download once, repackage and distribute internally.  Even if this is not the actual case, it is implied in the lack of authorization of Jpackage's ability to distribute lsb compliant versions of the SUN JVM.

Please stop this slight of the linux community, and don't wait till JAVA verison 1.8 or 2.5 to do it.  This simple reorganizing of the location of the files should be much, much easier than the noteable additions to the language itself (autoboxing, et. al.).

With the hurry that Sun seems to resolve this very simple issue, they are actually encouraging the development of a better alternative: gnu-gcj. WIth the pace this project is improving, it'll soon be the best alternative... technically, legally and ethically. :D

Well done! Keep up the no-job!

Pedro Bezunartea.

At 2005-08-23 and nothing done!!! Maybe you must to donate J2SDK to the open source community to do a best work!

There should be a /etc/sysconfig/java script that includes "JDK=..." and "JRE=..." lines to specify where applications get a default JVM.  It would also be wise to include the "JDK14=", "JDK50=", "JDK60=", "JRE14=" kinds of variations as well.

I do this for my applications so that there is a single place to make these changes.

Today is 2005-11-04 nothing has changed :(

Fix this please. Fix this on java 5 too.

Fix this, please.

This has been a problem for how many years now?  This really, really needs to be fixed; or at least let someone else do so...

Ease of Development? ok , but what about Ease of Deployment ?
Please take the matter seriously, growing SMBs are farewelling  to Java...

AUTOPACKAGE

Linux builds should not be provided via a redhat only distribution mechanism.  Autopackage aims to provide a consistent wizard-like cross-distribution installer for third party applications.  

So basically, 
Autopackage = third party apps
rpm/apt/... = distro specific public domain apps

The nice thing is that there will be an add/remove utility for third party autopackage apps in most distributions soon similar to Windows' add/remove utility.  See ubuntu's implementation.

See http://autopackage.org/ for details 

Though I feel that SDK installation is not as bad as people
state, I think it would help if LSB requirements were followed.

Can this change now that Sun's jre distribution licensing will be loosened?

4 years and counting ... this is sick considering there's already a solution which could be used as a starting point.

This gets my vote, at least once for every year it's been waiting:  what's up?  Why are we  still in the land of "Write once, configure everywhere!"

I have no words to express how much time I've wasted trying to get java installed on a red hat machine.  This should be simple but instead is a giant pain in the behind.

Plain short simple english - Maybe Sun'll understand..

- Please fix Java to Linux LSB specification - or -
- Allow jpackage to distribute the binaries instead

Maulvi Deunan

Come-on already, make it right

Please make it easier for users to install java on linux.

Help us Sun!  Java should not be this difficult to install,

So, why the BIG SUN, fails against a so little problem?
 Are you joking?

Please add my vote in favor of an all-free Java.