[lsb-discuss] Java

[Jeff Licquia]

Joseph Kowalski wrote:
> Jeff Licquia wrote:
>> I'm not sure this is correct.  Distro-provided JVMs may have good 
>> reason to break LSB application compatibility, as you note above.
> OK.  I was just trying to provide additional info (or should I say, 
> "opinion").  This really doesn't effect what we actually write down, right?

Nope.  Just being clear.

>> Of course, we want to eliminate gratuitous incompatibilities.  It 
>> would also be nice to enable conditional compilation, so you can build 
>> a JVM in "LSB mode", with a slow but standards-compliant 
>> implementation, or "native mode", with the volume turned up to 11.  
>> That would help with point 4:
> A very good *implementation* suggestion, for JVM providers.

Yup; again, not a standards issue.  But, seeing as how you're a 
representative of a JVM provider, may I emphasize the "very good" part? :-)

>> I think the plan is to assume that we can rely on Sun for most of the 
>> Java specs, testing, etc. via the published specs and a 
>> to-be-announced certification program for Linux distributions.
>>
>> As a fallback, in case Sun runs into more issues that delay the cert 
>> work, the Java specification can be released as a trial-use module.
> I think I'm missing something here...
> 
> I'm a bit uncomfortable with "to-be-announced certification program for 
> Linux distributions".
> 
> I think Sun is on the hook (so to speak) to make sure that a FOSS 
> community wishing to produce a JVM can assert they are compliant.  I 
> think this has been done (delta, advertising it better).

OK.  That means we're on the hook to do a thorough evaluation of what's 
out there and let you know if we're missing anything.

> I don't think Sun is in a position to certify distros.  We can only 
> provide them tools to make sure they conform to the specification.

Yeah, probably not clear.  The "to-be-announced certification program" 
wasn't meant to imply that Sun would be in the Linux certification 
business.  It's just that, in the future, "LSB" will also mean "Java", 
and Sun needs to be cool with that.  Whatever makes Sun cool with that 
is what I meant by the "to-be-announced certification program".

> I think its the LSB (Linux Foundation, whatever,...) job to provide any 
> such certification program for Linux distributions.  This should be just 
> like whatever the rules are for the rest of the LSB.  This test suite 
> will rely heavily on the JCK, but there are additions to be made (like 
> proper integration).   (Minor redistribution detail - see below.)

Sure, if that's what makes you happy. :-)

The question is: assuming we take care of the minor redistribution 
detail, is Sun OK with letting the LSB evaluate and certify JCK results, 
or does Sun want to do that themselves?

> I thought the goal was produce a specification (the LSB) to which Java 
> Application vendors (from above) and JVM providers (from below) could 
> rely upon.

Yup.

> Maybe I should just sketch out the sequence of steps I see them:
> 
>    0)   Agree with these "high level" requirements.  (Perhaps we are 
> done here?)

Maybe, depending on the answer to the "to-be-announced certification 
program" stuff.

>    1)   Formalize what is "Java". ie: what are the appropriate platform 
> specifications (jek3 - probably easy)
> 
>    2)   Formalize installation paths and cli specifications (jek3 - but 
> perhaps a little controversial   :-) )

This is probably more of a "documenting how things work now" issue.  If 
there's controversy, that's why the LSB exists; we should be able to get 
the right people together and hash it out.

>    3a)   Platform testing (JCK) - (Sun, only need a reference in the LSB 
> (appendix?))
> 
>    3b)   LSB/Java integration testing harness (lsb group)

These are the two parts, I think, that we're hashing out now: where's 
the dividing line, who does what, that sort of thing.  Maybe it's 
premature, but this seems like an important detail to me.

> Its only a schedule issue if as to if the "LSB Java specification" is a 
> trial-use module or not, right?

Basically.  There are always issues regarding completeness and the like; 
for example, if the tests are too weak, we might be nervous enough to go 
trial-use.  But I don't expect that to be a problem, given how strong 
demand is.

> Could you tell me more of what you think a "trial-use" module is?  Is it 
> "just paper" or something more?

Sure.  "Trial use" is a term of art in the LSB.  Basically, everyone is 
required to test against everything, but we grant blanket waivers for 
violations of some parts, so you can certify even if those parts are 
missing or wrong.

We decide what's trial use right before releasing a new version of the 
LSB.  A module might get "trial use" status if it's not quite stable 
yet, or the documentation isn't up to par, or the tests aren't good 
enough, or it hasn't quite made it into all of the distributions.

We only do trial use for new specs; once something is required, it 
doesn't go back.

We used to have "optional" modules, which were close to the same thing. 
  The difference is that "trial use" isn't optional from a test 
perspective; whatever tests we provide for trial use modules must be 
submitted along with everything else.  This gives us data about the 
quality of the spec and how well the distros are aligned with it.

But from an ISV's perspective, trial use == optional.  (We may do 
something about this for LSB 4.0.)