[lsb-discuss] LSB conf call notes for 2008-07-30
Dalibor Topic
Dalibor.Topic at Sun.COM
Fri Aug 8 16:57:30 PDT 2008
On 08/07/08 21:30, Jeff Licquia wrote:
> Right, but since JNI is a C interface, its manifestation on a Linux
> platform will be different than, say, Windows. That's the part I was
> thinking might need to be documented: things like the library's name,
> the interfaces it exports, etc.
The exported interface looks the same on all Java implementations on all
operating systems - it's a part of the platform specification.
The general idea of JNI is that you can write your native code, compile
it, use it from Java code on Windows, and provided it's portable,
recompile it, and use it from Java code on Linux or anywhere else. It's
not very pleasant to hack in, but it does the job.
I don't think that it would be useful to ISVs if the LSB had to
re-specify technologies in JCP's domain -
a specification for JNI already exists, is maintained through the Java
Community Process and all Java SE 6 implementations follow it.
Basically, the LSB spec should simply delegate what's part of the Java
platform to the JCP - that's what the JCP is for.
That being said, there is no lack of things LSB could specify in its
domain that may be useful to Linux ISVs specifically, like java-gnome,
or Qt Jambi, if it wants to. In my mind there is a pretty clear
separation of concerns between Java, the platform (specified at the JCP)
and exposing some portion of API specified by LSB to ISVs writing
applications destined for Linux exclusively in Java as their programming
language of choice (specified here, I assume).
The missing link between the two would be an (optional for now) LSB
module that specifies just the bare minimum (compatible implementation
sits at location /usr/bin/java, here are some command line options), and
leaves the rest to distributions, OpenJDK, and other Linux JVM suppliers
to make happen.
I'm deliberately saying 'other Linux JVM suppliers' and 'optional' since
so far among typical JVM vendors, so far only Sun has contributed their
crown jewels to the Free Software community, so therefore OpenJDK
currently only includes a readily certifiable as compatible,
high-performance implementation on architectures supported by Sun, which
is a subset of the architectures defined by the LSB.
It would be, in my opinion, impractical for ISVs and distributions alike
for LSB to mandate Java support as long as it can not extend across all
LSB architectures, and isn't available as a readily certifiable as
compatible, high-performance open source implementation on all of them,
just like it would be impractical for the LSB to limit Java support to
just open source implementations, or architectures supported by them,
when non-free Java implementations are available (for other
architectures) for those distributors who like such things and enjoy
distributing them, for some reason or another.
cheers,
dalibor topic
--
*******************************************************************
Dalibor Topic Tel: (+49 40) 23 646 738
Java F/OSS Ambassador AIM: robiladonaim
Sun Microsystems GmbH Mobile: (+49 177) 2664 192
Nagelsweg 55 http://openjdk.java.net
D-20097 Hamburg mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring
More information about the lsb-discuss
mailing list