>>>>> "Rick" == Rick Lutowski <[EMAIL PROTECTED]> writes:
[long sequence of valid comments about JCK elided]
Rick> In the meantime, efforts such as this packaging policy would
Rick> do well to keep the definitions straight. To say things
Rick> like "native code != Java" and then base long-term packaging
Rick> policies on such false notions will only lead to trouble
Rick> later when JCK becomes available to free projects, and the
Rick> fallacy of such thinking becomes more obvious.
The flaw in your argument is that while passing the JCK may qualify a
project as "Java", nowhere in the JCK (outside of the byte-code
verification tests) is there anything that requires said "Java"
environment to work with any other "Java" environment. Specifically,
environments that do more at compile time than .java->.class
conversion will *not* play well with those that don't.
Debian's role is to ensure that some reasonable LCD is established so
that our users can have some certainty about interoperability, even if
that means environments that provide enhanced intermediate/end forms
(and in this case using gcj to produce .so files could reasonably be
described as enhanced) are also required to produce less enhanced
forms. If J Random Java user sees three different class libraries in
Debian that sound appealing, they should be able to install them on
their system and hanve them Just Work, as long as they adhere to
whatever APIs the class libraries provide. They should not have to
perform unnatural coding acts, subvert their class loader or do
anything else out of the ordinary.
If a package complies with the above paragraph, you're right it
doesn't mater what combination of pure Java/JNI/something else it's
comprised of. Where a package cannot comply with the paragraph above,
it shouldn't mention java anywhere in it's name. It can still be in
Debian; it's just not Java.
--
Stephen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
