Nicolas Mailhot wrote:
The point is that for years fedora has had a scheme of package
requirements and no standard-compliant JVM that provided them. And it
has a strange symlinked path scheme that needs to be fixed when
installing a standard JVM.
ROTFL SUN couldn't even keep a stable JVM naming, let alone a standard
path, or agree with the other proprietary guys on common conventions, so
don't invoque a "standard-compliant JVM" when this thing never existed.
You are confusing 2 issues. By standard-compliant, I mean the language
spec which does exist and as far as I know, nothing fedora has ever
shipped, meets.
An archive of all the SUN, IBM and BEA jvm releases is a baroque history
of inconsistent paths and name changes no sane third-party package could
ever depend on (and BTW paths that contradicted existing standards like
the FHS). What ISVs depend on is a fixed version that uses SUN's
conventions-of-the-day, which are anything but standard.
I can't argue with that, but the point is that you aren't likely to find
anything more bizarre or undocumented than fedora's alternatives scheme
and when you combine the two, it's not something any sysadmin should
have to deal with when a simple rpm can fix it all.
Why do you think Java has little life outside J2EE
servers?
I don't think that at all. In fact, I think the projects I've already
mentioned (opennms, alfresco, openfire, spark) are extremely useful and
moderately popular, and there's probably a lot more, plus an assortment
of applets for vnc, ssh, xmpp etc., that everyone should have available
on their servers.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
