[kaffe] Re: dotnet platform support / gnu config.sub (long)
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'
Re: [kaffe] Re: dotnet platform support / gnu config.sub (long)
[EMAIL PROTECTED] said: Sun has a lot of lawyers, and they've been pretty aggressive than most about staking their claims on the linguistic turf (so they can sell it off). That's a rather twisted interpretation of Sun's use of trademarks, IMO. Another way of interpreting this is that Sun is trying to ensure that third-party Java vendors don't destroy Java's reputation for platform independence by shipping incompatible implementations. This is a good thing for everyone ... apart from unscrupulous vendors like Microsoft. Because they claim Java Compatible(tm) as a trademark, it makes it hard to use a normal noun+verb sentence to say that we're compatible with Java -- we are, by most dictionary definitions, but we're not Java Compatible(tm), under Trademark law. Maybe we can say that we're interoperable? :-) A dictionary definition of compatible is useless to users of our software because it is too vague. We cannot plausibly claim our software to be compatible in all respects with Sun's Java. So any claim of compatibility must be qualified in some way to be meaningful. By trademarking Java Compatible, and restricting its use to implementations that pass the JCK tests, Sun is doing users of Java a big favor. It prevents shonky vendors from tricking end users with misleading claims of Java compatibility. IMO, the only point against Sun is their unwillingness to make the JCKs available under conditions that don't exclude typical Open Source java projects. -- Steve ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: dotnet platform support / gnu config.sub (long)
Stephen Crawley writes: [EMAIL PROTECTED] said: Sun has a lot of lawyers, and they've been pretty aggressive than most about staking their claims on the linguistic turf (so they can sell it off). That's a rather twisted interpretation of Sun's use of trademarks, IMO. Another way of interpreting this is that Sun is trying to ensure that third-party Java vendors don't destroy Java's reputation for platform independence by shipping incompatible implementations. It doesn't matter what their motivation is. What we do know is that we can't call our system Java. Instead we have to call it something like The GNU Compiler for the Java[tm] Programming Language. As long as we stick to that, we're OK. It's useful for us to know that JVM is a trademark so we may not use it for our own work. This is a good thing for everyone ... apart from unscrupulous vendors like Microsoft. Because they claim Java Compatible(tm) as a trademark, it makes it hard to use a normal noun+verb sentence to say that we're compatible with Java -- we are, by most dictionary definitions, but we're not Java Compatible(tm), under Trademark law. Maybe we can say that we're interoperable? :-) A dictionary definition of compatible is useless to users of our software because it is too vague. We cannot plausibly claim our software to be compatible in all respects with Sun's Java. So any claim of compatibility must be qualified in some way to be meaningful. Yes. By trademarking Java Compatible, and restricting its use to implementations that pass the JCK tests, Sun is doing users of Java a big favor. It prevents shonky vendors from tricking end users with misleading claims of Java compatibility. All that we have to know is what we may and may not do. And that seems to be quite well-defined. Andrew. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: dotnet platform support / gnu config.sub (long)
Dalibor Topic wrote: Guido Draheim wrote: 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. AFAIK sun has quite strict rules about claiming compatibility with any of their Java products. Basically, you can't do it, unless you shell out big bucks for a license to their code. But I may misunderstand what you want to say. Exactly that - there is no product here. It's a different thing whether addon software wants to be compilable for java licenced only or even java lookalikes. The difference is often not important during compiling (of source), it may only be interesting during advertising of a product (the binary). 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. It's just that all those java'ish runtimes are all somehow different in my experience, so trying to put some kind of 'it's all mutually compatible java' cover on it doesn't really fit. A 'abstract machine'-'runtime' mapping only works as long as there are only a few runtimes available. In java's case, those days are long gone, and the number of options is quite huge, so fitting all of them under the same cap is quite complicated, if not impossible. I assume that in few years, c# will have the similar problem ;) *LOL* there are so many i*86 compatibles, and we still put them under the same umbrella for autoconf'iguring software. You know, here we speak about addon software that wants to configure itself to the _specifics_ of a _platform_. It is not important how many derivatives are there, or even lookalikes, - however for the task of getting at the specifics, and well, we _need_ a general guideline of the platform family in which we want to test for specifics. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: dotnet platform support / gnu config.sub (long)
On Wed, 24 Sep 2003 23:38:38 +0200 Dalibor Topic [EMAIL PROTECTED] wrote: 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. AFAIK sun has quite strict rules about claiming compatibility with any of their Java products. Basically, you can't do it, unless you shell out big bucks for a license to their code. But I may misunderstand what you want to say. Sun has a lot of lawyers, and they've been pretty aggressive than most about staking their claims on the linguistic turf (so they can sell it off). Because they claim Java Compatible(tm) as a trademark, it makes it hard to use a normal noun+verb sentence to say that we're compatible with Java -- we are, by most dictionary definitions, but we're not Java Compatible(tm), under Trademark law. Maybe we can say that we're interoperable? :-) Anyways, the config.sub name is just going to be used to define a target - so it makes sense to call the target Java, since it's only going to be used by tools generating Java byte code, which will run on Sun's JVM. Of course it will still run on other virtual machines that can't use the Java trademark, but that shouldn't be of any concern to the tools generating the code, IMHO. Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
