> > 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
