Re: Is it possible to create a "all-in-it-package" ?

> Yes, it works very fine.
> The biggest problems have the KaffeVM, which can run some AWT-programs, but
> have with Swing problems.

I once had a look a kaffe's sources, and tried to use it. I feel it is very 
feature-rich, but severely structurally broken and essentially 
unmaintainable.

> So I using mostly CacaoVM and SableVM.
>
> To use both is necessary to see, if existing bugs are in the VM or in GNU
> Classpath.
>
> At the moment I have mostly tested AWT and Swing-programs. But in this
> case, there are not so much differences between the VMs.

Cacao has a JIT-compiler, while SableVM is interpreting. So CacaoVM should be 
as fast as native code, with an overhead for JIT compilation, but testing not 
computing intensive (GUI) applications you cannot notice the difference on 
modern machines, just as you experienced.

> They looks both fast. The menu in Swing have nearly the same speed in
> SableVM and CacaoVM.
> Only if I move the Window the an other position, then the left top corner,
> then the menu makes Errors. But thats a problem of GNU Classpath
>
> But the on the cacaojvm mentioned game "foxhunt" seems to be on CacaoVM a
> significant faster.
> Trying to hold the left mouse button down and open a line of fields or so
> is on Cacao faster. So it is possible, that the EventHandler or so in Cacao
> are faster.
> An other point are, that in Swing (AWT I haven't tried for this) shows
> german umlauts wrong. CacaoVM on the other side, show it correct.
> For example in menus "Öffnen" or "Einfüfen" the "Ö" and "ü"
> Here a list of all german umlaut: Ä Ö Ü ä ö ü ß

Please note that GNU Classpath has a clearly defined and very limited 
interface to the VM (in CP's directory under vm/reference/). It does a lot of 
other stuff native as well, but this does not differ for VMs.
At a first glance at the source some Unicode conversion is really done in the 
VM interface, so (java.lang.StringCreator) so there might be a bug in 
SableVM. Then, SableVM for whatever reason still holds a local copy of CP, so 
it might be using a different version the CacaoVM.

>
> An additional point is, that CacaoVM and SableVM seems mystical.
> Sometimes they don't want to run a Swing-program and aborts with an error.
> But if I try it after that again, the Swing program runs without problems.
> Because CacaoVM and SableVM have the same problem, I think, its a problem
> of Classpath.
>
> Later I have tried to use GNU Classpath 0.17 instead of the installed 0.16
> in CacaoVM and SableVM.
> But after the update, both aborting with and MemoryAccessError by trying to
> run Java-programs.
>
>
> What I mostly like on SableVM over the other VMs (especially CacaoVM) is
> the license: LGPL instead of GPL. :-)
>
> But who have all worked on it? Is it possible that you put it additionaly
> under the APL, so that the Apache-people can use it for Harmony?
> http://incubator.apache.org/harmony/

I think all copyright is held by the team at uqam, at least I have agreed with 
copyright transfer when I contributed a patch.

>
>
> But nice work, what you have done.
> I will test it later more - when I am back at home.
>
> Greatings
> theuserbl
>
>
>
> _______________________________________________
> SableVM-user mailing list
> [email protected]
> http://sablevm.org/lists/control/listinfo/sablevm-user