[lsb-discuss] Java

Theodore Tso tytso at MIT.EDU
Fri Feb 1 10:54:59 PST 2008


On Fri, Feb 01, 2008 at 12:02:50PM -0500, Robert Schweikert wrote:
> 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.

Yeah... I'm a little concerned about this.  The devil will be in the
details.  It's certain the we will need to be very careful about what
we allow to be specified in this way to avoid abuse.  Otherwise people
could start saying things like "Certified with any LSB compliant
<FOO>", where FOO could be anything from "Microsoft .Net runtime", or
"Infocomm Z-code interpreter" to "Oracle Database".  

I assume here that we would get to decide what sort of "Certified with
any LSB compliant <FOO>" could be used, and we would get to set the
rules; but there still is the unfortunate situation where it
effectively means that there is an asterisk on the certification, and
so someone who purchases a software package might not get something
that works out of the box.  The confusion is not too different from
what happens if we start having profiles, which is another issue that
we will need to figure out.

> In this case the ISV can put pressure on the JRE provider to get the JRE 
> certified.

They could, but that presumes the ISV cares enough, and that the ISV
can put enough pressure on a JRE provider that the JRE provider would
pay attention to the ISV.

>> 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?
>

Well, all of the enterprise distro's are shipping with some JRE these
days.  And if there is a full open source JRE which can be certified,
then that should be sufficient for the community distro's like Debian.

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

That's somewhat of a separable question.  It's an important one, to be
sure, in that it would become easier for ISV's to generate LSB
compliant applications if they didn't need to use a special build
environment.  (Although the build environment is also useful for
flagging in advance if ISV uses a flag bit to some syscall or symbol
that's not defined in the LSB.)

But it does serve an interesting and useful purpose in case a
distribution's native libraries export an LSB incompatible ABI.  There
might be other ways of accomplishing the same goal, though, so maybe
that's something we could think about revisiting for LSB 4.0.  (For
example, we could require that LSB applications have a magic ELF
section that indicates it is an LSB application, and that way, if
necessary, we could replace a distribution's ld-linux.so with one
which checks for the presence of the ELF section --- and the magic ELF
section could be easily added via the objcopy command.)

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

Well, if we do an LSB Java, I'd want to avoid the rat holes by keeping
things as simple as possible, such as what I described above.  :-)

       	  	    	      	      	   - Ted



More information about the lsb-discuss mailing list