[lsb-discuss] Java

[Robert Schweikert]

Theodore Tso wrote:
<snip>
>  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.
>   
I believe the answer to this question is yes.
> 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.
>   
For this use case we need to further explore the "plugin certification 
model" we have kicked around. Basically the vendors makes the statement 
that says "Certified with any LSB compliant JRE". How we will test this 
type of app needs to be determined, not sure whether or not Jeff had a 
proposal for this.
> 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.)
>   
In this case the ISV can put pressure on the JRE provider to get the JRE 
certified. On the other hand the only requirement an app (or JRE 
implementation) not built with the lsb tool chain will not meet w.r.t. 
LSB spec is the dynamic loader, and we have discussed in the past 
whether requiring a special loader is still the best approach.

Further on this, although of topic w.r.t. our Java discussion, we should 
consider if it is feasible to allow people to build without lsbcc and 
provide a recipe on how to get an LSB compliant application that way.
> 3) A large enterprise application ships with a JRE which is LSB
> certified.
>
> 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. 
But in this case the JRE provider will also get pressure from the ISV, 
that should accelerate the process. Ideally we'll get the providers 
certified close to the same time LSB 4.0 goes out the door. (I know I'm 
dreaming, but ....)
>  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.
>   
Well if we can get the interfaces into the LSB and have an outreach 
program the JRE providers could potentially start working with the 
preview release in July. There's a good use other than publicity for 
such a beast. If we can pull that off we might get certified JREs in Q1 
of 09 which would lag the LSB 4.0 push by only 3-4 month.
> 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. 
Yes, if we come up with a plugin certification model, see above.
>  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.
>   
That depends on us. I think this problem can be solved without an LSB 
java. I am not opposed to creating an LSB Java, I am concerned, as are 
other people on the list that this approach is full of rat holes we 
don't want to fall into.
> 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 sounds like good idea, the question is then will distro vendors go 
along with that approach?

Robert
> 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.
>
>       	    		    	    	    - Ted
>   

-- 
Robert Schweikert                       MAY THE SOURCE BE WITH YOU
(robert.schweikert at mathworks.com)                 LINUX
The MathWorks Inc.
Phone : 508-647-2042