[lsb-discuss] Java

[Theodore Tso]

On Mon, Feb 04, 2008 at 09:54:57PM -0500, Jeff Licquia wrote:
> For some standards efforts, I think this would be OK.  I'm not sure how 
> well talk of "cheating a little" or "practical certification" would go over 
> at Sun.

Well, whether they like it not, it's happening today.  For example,
I'm running Lotus Notes on my Ubuntu system.  Said Notes package came
bundled with a JRE, and was originally packaged for RHEL4, possibly
RHEL5.  It was then converted into debs for installation under Ubuntu,
and the splash screen includes a claim that it was running contained a
certified Java implementation --- except, because it's running on an
Ubuntu system, the Java certification was broken.  Oops.

I've been running this way for multiple years, and to date no storm
troopers have show up at my doorstep for running an uncertified Java
distribution.  :-)

> It's also worth noting that no open-source JRE can pass the TCK today, 
> which means in practice that every distro-supplied JRE is proprietary. 
> That's a deal-breaker for us in terms of referring to Java in the LSB. 
> We're basing our new thinking on the idea that an open-source JRE will one 
> day pass the TCK.  But only binaries can pass the TCK.  It would be bad for 
> the LSB to forbid people from exercising their rights.

Basically, the question is which is more important --- the ability to
allow small ISV's that don't want to bundle JRE with each of their
applications (and that may actually cost them significant $$$,
depending on JVM provider), and still LSB compliant, versus allowing
Debian to be LSB compliant.  In practice that's what the tradeoff
would be, since most other distributions, including Ubuntu, don't
really have a problem with shipping binary components.

I don't really but the "forbid people from exercising their rights"
line, since as I mentioned, it's entirely too easy to break a Java
certification as it is.  Just recompiling the kernel will do it.  Does
that mean the Java certification "forbids me from exercising my rights
to rebuild my kernel?"  Nope.  It might break the actual certification
itself, and depending on how we word the requirements, it might
prevent Debian from being able to certify --- at least, not without
including a dependency on non-free.  

Put another way, suppose that a future version of Ubuntu ships with a
binary JRE which was certified, and said JRE was built from all open
source components.  Are the rights of the end-users affected?  Not
really; anyone could modify the Java sources, recompile the JRE and
install it.  It would break the certification on their local system,
true --- but so would recompiling the kernel or installing a security
fix.  So I don't think it's accurate to say that doing in this
scenario, the LSB or the Java certification are "forbidding people
from exercising their rights".  It's important to be accurate and
precise here, because while such a course definitely *does* have
disadvantages, it's part of tradeoffs that may very well be an issue
for various ISV's.

Now, if we gather data which says that all of our potential LSB's are
quite happy shipping a JRE which weighs in at 14 megs compressed (75
megs uncompressed) with their products, AND we are comfortable that we
can get at least one, and preferably many JVM providers to ship
LSB-certified JRE's, maybe this whole point is moot.  I'm just
concerned that neither of these conditions are likely to be the case.

> Sun doesn't have to buy into it.  We could word our spec so as to disclaim 
> specific Sun certification, while claiming that a common source heritage is 
> "good enough".  But I fear that our Java spec will become meaningless on 
> the one hand, or serve to fork Java certification on the other, depending 
> on how specific we get.

We wouldn't necessarily need to claim anything about Sun
certification.  One potential wording would be something along the
lines of "/usr/.../jre" must be a directory or symlink to a directory
which contains a binary which either (a) is a jre certified by the Sun
Java certification process, or (b) built from sources that produced a
jre certified by the Sun Java certificaiton process.  

> I suppose a lot of this is speculation.  Sun will have to deal with these 
> issues when the first open-source JRE gets certified, and the way they deal 
> with them will likely help us figure out a strategy.

Do we know how quickly this is likely to happen?

      	       	       	       	      	 - Ted