tytso at MIT.EDU
Fri Feb 1 08:34:05 PST 2008
On Fri, Feb 01, 2008 at 08:24:25AM -0500, Robert Schweikert wrote:
> From all the responses it appears that option 2 of my previous post is
> favored, i.e. assure that the LSB has all the necessary interfaces any
> given JRE needs. As a second step reach out to JRE/JDK implementers to get
> their version certified. Using this approach might satisfy all
> concerns/comments posted.
This is a good thing, for all of the reasons you specified... and I
think we should do this regardless. But one big question which we
have to answer is whether this by itself solves the underlying problem
we are trying to solve --- i.e., for an application that uses Java,
can it be LSB certified.
There are a couple of cases to this question
1) A smallish application where the ISV doesn't want to ship a JVM
with their product (because they want to use system JVM, and shipping
their own JRE might increase the size of their product distribution by
a factor of 100 or more). Maybe they also don't like the idea of a
single Linux system running 5, 10, 15, or 20 JVM's at the same time,
due to the increase disk and memory utilization.
2) A large enterprise application which ships with a JRE, but it is a
JRE which is not LSB certified. (The JRE could have been LSB
certified if it was built with the LSB build tools, but the JRE
provider chose not to LSB certify it, for whatever reason.)
3) A large enterprise application ships with a JRE which is LSB
The last case is the easy one and it's clear that an application
falling the class (3) could be certified.
The middle case is the super hard one, and there's really not much we
can do about this, other than to lobby JRE providers to LSB certify
ASAP. The reality though is that it's unlikely they will be able to
do this until LSB 4.0 ships, and then it will probably take them 3-6
months to go through their development, test, and release cycle, so
that means we wouldn't see any resolution on this front until Q3 or Q4
of 2009 at the very earliest.
The first case is one which would NOT be satisified if all we do is
try to add all of the interfaces needed by a JRE. Sure, it may be
that all of the distributions ship some kind of OSS Java which is LSB
complaint (or could be made LSB complaint) --- but an application
can't count on that JRE being available, so the application wouldn't
be LSB compliant and couldn't be LSB certified.
If Kay is right and there are a large number of application which fall
into class (1), then one way of addressiong this in LSB 4.0 would be
to add a requirement that a JRE which is certified by Sun to be Java 6
compliant must be made available at some pathname such as
/usr/lsb/jre6, or some such. We wouldn't say *which* JRE was there,
just that it must be certified by Sun as being Java complaint. We
wouldn't even need to supply any tests; just require that part of the
Distro certification process would involve submitting proof that the
JRE which was shipped was certified as Java compliant.
This wouldn't be good enough to solve the problem for enterprise
applications in class (2) which insist on shipping their own JRE. But
it might be good enoguh for the smaller applications, or for those
applications who only use Java because their company had standardized
on InstallShield implemented in Java. So this isn't an either/or
proposal, but a both/and. It's clear we need *do* need to make sure
that we have enough interfaces such that a JRE provider can certifiy
their JVM. The question is whether that is enough.
More information about the lsb-discuss