Dalibor Topic wrote:
Guido Draheim wrote:
For the java machine, the term `jvm` is used universally. I do not remember there were any dependency on pointer lengths, it runs in managed mode always.
JVM, JDK, Java, etc. are all trade marks with associated conditions of use. http://www.sun.com/suntrademarks/#J . Are you sure you want/need to use them?
Yes. Actually, if the target is a java'ish machine then they will have to take care of any of that legalese themselves. The config.sub thing is not a java'ish thing itself here. - Furthermore, the use context is obviously talking about compatiblity with a certain vm type and not identity, as expressed in a lot of corners and we know that config.sub simply trying to get a "canonic" variant of certain arguments given. jvm, java and similar names _are_ the canonic variant of anything quite like it but not the product (trademark!) itself.
That however points out a mistake in my attemps - it should not call for "sun" as a default vendor vor any of the java lookalike targets. Still we need to have some "canonic" name that software type, simply that it can be used to autoconf'igure addon software.
Since ilvm64 may be run on a 32bit system, we do set the two cpu/vm types of "ilvm" and "ilvm32" for the dotnet binaries and libraries. Alongside we use "jvm" for jar binaries
A virtual machine capable of executing programs written in java programing language usually executes only classes stored in class files. Some virtual machines also have the capability of executing programs stored in zip archives, or jar archives. So 'jvm' is a misleading term here.
The "jvm" is in the place of the "processor", the packaging format would be indicated in the last part around the OS-KERNEL type. That's established use for other OS/EXE variants as well. My previous mail was trying to indicate that strongly and differentiate between an executable segment (jvm) and packaging exe format (jar) that can be started by an interpreter (java). Sorry if it was not _that_ clear.
Therefore, for jvm we do usually paste 'java' as interpreter and 'jdk' as basic service series. Likewise the dotnet binaries are given as 'ilrun' for the interpreter and 'mono' for the service series (or something alike).
Not all java interpreters are called 'java'. there is gij, sablevm, kaffe, wonka, and a ton of others, that don't necessarily fit into this naming scheme. While some of them provide java-named wrapper scripts, I'm not sure if all of them do.
Correct. There may be no `java` (lowercased) wrapper script. However, I expect that an autoconf script will detect a shellvar $JAVA to point to it with the help of an ac_check_tool test. That test may include other java wrapper names as tools to test for - probably testing for a `java` wrapper first. That's why the canonic name is `java`, note that the config.sub canonic name is always lowercase, unlike the common form of a shellvar to point to a wrapper script.
jvm-sun-java-jdk jvm-sun-java-j2me jvm-sun-java-j2se jvm-sun-java-j2ee
uh, what's that sun doing there? ;) what's the difference between jvm-sun-java-jdk and jvm-sun-java-j2se supposed to be? and so on ...
I believe it would be better if you got in touch with kaffe, gcj, sablevm, classpath, debian-java etc. developers before you try to push something as big as this through as some kind of a GNU convention. I don't know much about .net yet, and being a kaffe developer, I'm more focussed on the java side of things. AFAIK, similar definitions have been tried before on debian-java, and failed.
On the other hand, if the virtual machine implementors of varios GNU projects have already been consulted, and this is the concensual proposal, I'd like to have the reference to the mailing list threads ;) If that's not happended, then let's discuss this first, as it's a good idea, but it needs to be discussed in a broader, more realted audience, than the libtool mailing list, which, sincerely, doesn't seem like a good pick to debate the finer details of naming vm systems. ;)
No, I've been trying to get a decent cc list for dotnet targets as it is a platform target that can have C/C++ source code as input - IOW a target that can be different than the primary target of that software. That's not the same for java. - I was including java (and python) in the description in an attempt to establish guidelines for (any) other VM-type target platforms.
Note that dotgnu has a compiler that can output an ilrun binary with a jvm executable segment. They call the target -mjvm. The gcc has references to java as well, lot's of them really. Surely one can have F/U/D about the usage of java/jvm trademark stuff but I expect them invalid in this context where we speak about a "canonic" name for a family of platforms, not any product specifically. Creating a java compatible product however would need to care about the trademark stuff, but here we do not have this case.
I'll update that patch and to erase the reference to 'sun' which is simply incorrect. It may even give the wrong result associating the vendor to a sub-platform that is not tied to this vendor. Thanks a lot for having a look into the matter, Dalibor. :-)
more comments? -- guido http://google.de/search?q=guidod GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
