Re: Re (3): testing before a release

[Chris Gray]

address@hidden wrote:

> address@hidden writes:
>
>
> > As the AWT doesn't really work at the moment so I don't think this
> > license should bother you because you wouldn't use that code anyway.
>
> The fact it doesn't work yet is no excuse. It will work someday. And applets
> use the AWT. Writing a VM that doesn't support applets makes no sense.
>

That's not really true - there's more to Java than running webtoys.  In fact
running web applets involves supporting a whole load of deprecated junk
you'd rather not have to put in, because applets are basically stuck in a
Java 1.1.4 time-warp.. Companies like Aicas seem to be able to find customers
without having an AWT, and I daresay that Cygnus/RH also have customers
who don't need one.  That being said ...

>
> The VM loads the applets, and must (dynamically) link itself to those
> classes and start their execution, so the VM has to use the applet class.

Well, it has to *run* the java.awt.Applet class.  But it's not the VM that is
*using* that class - it's the Spec benchmarks that do that.  The VM is just
chewing through the bytecodes.  Some of those bytecodes may tell it to
execute a native method, and then you could say that the VM is using
that native code the way it uses a library (although the VM might claim
it was only following orders).

Assuming your VM is written not in Java but in some other language such
as Haskell or Forth, it can't really "use" a class file the way it would use
its usual libraries: all it can do is *process* the class file.

>
> Etienne also had a good point about the Spec JVM benchmark. I had a quick
> look at it:
> * _202_jess imports the awt
> * the whole suite must be run as an applet
>
> So, if I'm not able to run the spec benchmarks using classpath, I cannot
> publish any serious reseach done using it, as I cannot compare it with the
> other VM implementations.
>

I don't see that java.awt is any different to java.util or any other core class 
-
it should be possible to run GPL'd classes on a non-GPL'd VM in the same
way thet Linux can be run on a non-GPL'd CPU.  But there are other aspects
of Java which are more troublesome: suppose that as a result of executing
some opcode such as `new' or `invoke_static' your VM has to initialise a class.
That leads to constants getting resolved, and as a side-effect you need to
load another class.  To do that you need to use the class loader which loaded
the class you are busy resolving, and now it really seems that your VM is
*using* that classloader in order to perform its work.   If some of that code
came from Classpath (e.g. the class loader inherited the loadClass() method
from java.lang.Classloader) then there seems to be an issue.


>
> Is RMS perhaps trying to shoot classpath in the foot?

Does he know which foot he's aiming at?

Chris Gray
VM Architect, ACUNIA