Illustrating JVM bindings
On Thu, 2005-13-01 at 17:24 -0500, Raul Miller wrote:
> On Thu, Jan 13, 2005 at 04:35:50PM -0500, Grzegorz B. Prokopski wrote:
> > > But was Kaffe _extended_ to provide such bindings for Eclipse 3.0?
> >
> > This FAQ entry discusses 2 cases. One is when we have an interpreter,
> > that basically goes over the pseudo-code and purely "interprets" it
> > (an old BASIC interpreter would fit here). No Java VM/interpreter
> > _ever_ fits in this first, simple casse.
>
> The FAQ discusses far more than 2 cases.
>
> I imagine you're concerned about this part:
>
> If a programming language interpreter is released under the GPL,
> does that mean programs written to be interpreted by it must be under
> GPL-compatible licenses?
> When the interpreter just interprets a language, the answer is
> no. The interpreted program, to the interpreter, is just data;
> a free software license like the GPL, based on copyright law,
> cannot limit what data you use the interpreter on. You can run it
> on any data (interpreted program), any way you like, and there are
> no requirements about licensing that data to anyone.
>
> However, when the interpreter is extended to provide "bindings"
> to other facilities (often, but not necessarily, libraries), the
> interpreted program is effectively linked to the facilities it uses
> through these bindings. So if these facilities are released under
> the GPL, the interpreted program that uses them must be released in
> a GPL-compatible way. The JNI or Java Native Interface is an example
> of such a binding mechanism; libraries that are accessed in this way
> are linked dynamically with the Java programs that call them. These
> libraries are also linked with the interpreter. If the interpreter
> is linked statically with these libraries, or if it is designed to
> link dynamically with these specific libraries, then it too needs
> to be released in a GPL-compatible way.
>
> > Second case is where the code being interpreted may request to access
> > bindings provided by the JVM. In Java these are done thru JNI calls,
> > so usually JVM itself is a JNI library that provides these bindings.
> >
> > So an interpreter has to be "extended" to provide these "bindings" to
> > other facilities. In such case, as the FAQ states "the interpreted
> > program is effectively linked to the facilities it uses through these
> > bindings."
>
> Is this relevant to Eclipse? I was under the impression that Eclipse
> was pure java -- that it did not use JNI at all.
>
> If Eclipse does use JNI, would still a question about whether or not
> Kaffe's JNI implementation constitute some kind of extension designed
> to work around the GPL or whether they are some kind of implementation
> of some Java standard.
I fail to see anything in the FAQ you cited above about extensions
designed to _work around GPL_. Please refrain from creating meanings.
This is about the way Java works. You cannot merely interpret
bytecode. The program you're interpreting has to be able to call back
into the JVM (or if you wish into a JNI library that is bound to a VM)
to be able to run at all.
> > > Or is Eclipse 3.0 using only the facilities which Kaffe provides for
> > > arbitrary byte code?
> >
> > There is nothing in the FAQ that would suggest that these "facilities"
> > have to be provided for a specific program.
>
> There is nothing in the FAQ to suggest that a GPLed JNI implementation has
> to be a problem for arbitrary code, though of course it does point out JNI
> as a issue that can be a problem. But for problem resolution, the FAQ is
> saying that certain things need to be released in a GPL-compatible way,
> not that no release can happen.
It says "if these facilities are released under the GPL, the interpreted
program that uses them must be released in a GPL-compatible way".
The IPL/APL are not GPL-compatible, that is, they cannot be released in
a GPL-compatible way. These "facilities" of a java interpreter are
(usually) available via JNI, which is basically a library call interface
(no magic here). These library calls have to be used by any program
that runs on a JVM. That library is usually part of JVM, and in the
case we're discussing, is whole GPLed.
According to the above citation, it imposes that you must be able to
release a program (the one you're running on a JVM, the one that uses
these bindings) in a GPL-compatible way. You cannot do it for a program
that is GPL-incompatible.
> > On the contrary. A Java Virtual Machine (Java interpreter) inevitably
> > has to provide such bindings to support Java specification. In other
> > words the interpreter itself has to be extended with a library that
> > provides these bindings to support Java specs. There's plenty of these
> > bindings required to exist in core java.lang.* classes.
> >
> > Hope this clarifies the issue,
>
> You seem to be claiming that a JVM has to provide non-standard JNI
> capabilities or it isn't a standard implementation of the JVM.
I am sorry, but where do you see the "non-standard" is wrriten?
The only part that would suggest somethign like that is "when the
interpreter is extended to provide "bindings" to other facilities".
Is that the part you're referring to?
I am trying to explain, since the very beginning, that it is not
possible for a Java interpreter not to provide these facilities that
are being called by the program being interpreted. Therefore *every*
JVM has to consists of an interpreter (be it JIT or ahead of time)
extended with these "callback" functions.
Actualy please ask me about it as long as you need. Last time when
we were discussing this issue I did not know much about how all these
"Java interpreter" vs. "Java library" vs. "JVM interface
callbacks/language bindings" work together.
In short it turns out that the java library, vm library of bindings,
and the program can and do call each other.
> I'm not sure what that is supposed to clarify. I'm rather doubtful that
> it's correct.
This is the way Java works. Please ask. I'll try to explain the best
I can.
We do NOT have something like (that would be the first case described
in the FAQ):
+--------------------------------------------------------------------+
| a p l i c a t i o n : native app libs |
+-----------------------------------------------+--------------------+
| p u r e j a v a l i b r a r y : native java libs |
+-----------------------------------------------|--------------------+
| b y t e c o d e i n t e r p r e t e r : native interp libs|
+-----------------------------------------------+--------------------+
But we have something like:
+-------------------------------------------------------------------+
| a p l i c a t i o n : native app libs |
+-----------------------------------------------+-------------------+
| p u r e j a v a l i b r a r y : native java libs |
+----------------------+ - - - - - - |-------------------+
| VM JNI bindings lib : VM java bindings | \
+ - - - +----------+------------------------+ | => JVM
| | bytecode i n t e r p r e t e r | /
+-----------+-----------------------------------+
Where the bytecode interpreter interprets pure java parts of aplication
and library, but these parts inevitably make implicit use of the library
of bindings (JNI or not) that accompany the interpreter. The VM JNI
bindings might manipulate what you'd otherwise call "interpreter" part
of the VM and are thus closely bound together.
These facilities include class loading, class instantiation,
synchronization, garbage collection (ie. you can trigger GC from within
your program), reflection (ie. you can ask VM "what are methods that
this class have?").
It is not possible to have a JVM w/o these facilities.
Now, the FAQ says:
"However, when the interpreter is extended to provide "bindings" to
other facilities (often, but not necessarily, libraries), the
interpreted program is effectively linked to the facilities it uses
through these bindings. So if these facilities are released under the
GPL, the interpreted program that uses them must be released in a
GPL-compatible way."
Cheers,
Grzegorz B. Prokopski
--
Grzegorz B. Prokopski <gadek@sablevm.org>
SableVM - Free, LGPL'ed Java VM http://sablevm.org
Why SableVM ?!? http://sablevm.org/wiki/Features
Debian GNU/Linux - the Free OS http://www.debian.org
Reply to: