Re: Illustrating JVM 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.
On Thu, Jan 13, 2005 at 06:33:20PM -0500, Grzegorz B. Prokopski wrote:
> I fail to see anything in the FAQ you cited above about extensions
> designed to _work around GPL_. Please refrain from creating meanings.
I believe the GPL takes precedence over the FAQ.
And, no, I will not restrict my use of the english language words to
literal quotes taken from a FAQ.
If I've provided too much meaning for you to deal with, I feel some mild
regret at inflicting such agony on you, but not so much regret that I'll
start posting nonsense.
> This is about the way Java works. You cannot merely interpret
> bytecode.
Sure I can. I've done it.
Mind you, I'm not very fast when I interpret bytecode logically, but
that wasn't your claim.
> 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.
http://google.com/search?q=define:jni
When a java program uses JNI, you basically have to treat it as a non-java
program, because it can use non-java facilities.
However, a pure java program doesn't need to use JNI and the presence
of JNI facilities in the interpreter is moot at that point. This case
is typically simpler than the case of a non-java program, which is why
JNI gets special mention -- so that the two cases aren't confused.
> > > > 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".
Indeed. But I question whether the phrase "these facilities" is at all
relevant to this context.
Until I have some reason to believe that it is relevant, I don't find
discussion of the consequences of releasing "these facilities" to be
very interesting.
> > > 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?
I see it written two lines and five lines above this sentence.
[You asked.]
Now, if you'd have asked a relevant question I'd have made an effort to
provide a relevant answer.
But relevance has to do with concepts and ideas. A strong devotion to
literal quotes won't get you there if you've abandoned the meaning of
the material you're quoting.
> 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?
No. I'm talking about my understanding of the significance of various
aspects of computer programming technology within the scope of my
understanding of the GPL, as they relate to the context being discussed
in that part of the FAQ.
While I'm prepared to restate my ideas using different words, if my words
are a problem for you, I'm not prepared to pretend ignorance where it
doesn't exist. Likewise, I'm not really prepared to pretend that I know
about something I don't know about.
Finally, while I'm prepared to admit my mistakes, if they're pointed out
to me (and I do make mistakes, at times), I'm not going to pretend that
<<something other than literally quoting the FAQ>> is always a mistake.
> 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.
I know that's what you're trying to explain.
What I don't see is any convincing reason to believe that you are correct.
However, take heart -- I can be convinced. In fact, you're already
convincing me of something. You've almost convinced me that you don't
understand what JNI means.
> 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.
Ok, let me ask you: do you think that JNI has any significance when
discussing the status of a pure java program?
> 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 | /
Are you saying that Eclipse 3.0 is not pure java?
Because, if you're not saying that then you're not saying that the JNI
bindings are used by Eclipse.
> 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.
But an application doesn't need to use JNI for the JVM to have these
facilities.
--
Raul
Reply to: