Ola Lundqvist wrote:
>
> Well I do not really understand this. Java code is supposed to be
> portable. If you compile it to machine binaries it is no longer a
> java program and should not be packaged as a such. Non java
> components should be extracted to a separate package IMHO.
I'm staying out of the main topic of this thread since I'm
not much into dselect or rpm packaging (prefer tarballs!).
However, I must point out that the above statement is totally
incorrect, and that compiling to native, of and by itself, does
not make a Java program "no longer a java program".
A Java program may indeed consist of totally native code. A
good example is a JavaME program compiled to native to fit in
a small appliance or smart card architecture. Such programs
are still Java programs in every sense of the word, even though
they are no longer in bytecode form, and no longer require a
standalone JVM to run (actually, the essential parts of the
JVM have been compiled in). Conversely, not all Java bytecode
files are Java programs, such as bytecode files produced by Ada
compilers (and yes that has been done). Those would still be
Ada programs, not Java programs. In short, bytecode != Java.
If (bytecode != Java), what does? I'll tell you what does --
conformance with the full suite of JCK tests. Sun grants their
stamp of approval, and ability to wear the Java logo, ONLY
when an implementation (JVM+tools+APIs) all pass the
respective JCK (Java Compatibility Kit) tests, of which there
were about 21,000 the last time I counted. Passing JCK
is what makes something "Java." Compiled-to-binary code can
pass JCK just as well as bytecode implementations. I know this
for a fact because I used to be a JCK tester for a major bytecode
to native compiler vendor. We were able to pass JCK in full
native mode, and Sun recognized this and granted the product
full Java certification.
The problem with all 'free' Java implementations to date is that
none of them have been able to pass JCK because of Sun's ill
considered legal hang up with free software licensing. Jakarta's
efforts at getting Sun to re-evalutate their position and say
at JavaOne that JCK will be made available to free projects is
of great significance -- for the first time, free implementations
will be able to tell if they are truly "Java" or not and, if
not, exactly why (i.e., which JCK tests they fail) and so know
what must be done to become fully Java compliant.
In the meantime, efforts such as this packaging policy would do
well to keep the definitions straight. To say things like
"native code != Java" and then base long-term packaging policies
on such false notions will only lead to trouble later when JCK
becomes available to free projects, and the fallacy of such
thinking becomes more obvious.
Rick
--
Rick
Lutowski
|[EMAIL PROTECTED]
\ oo \____ http://www.jreality.com/ _______
__\ ____________________________________________________________ /_
| _____/
`------------------------------------------------------'
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
