[DGD] Java or LPC (DGD)?

[Albert Deinbeck]

Hi Felix...
----- Original Message -----
From: "Felix A. Croes" <felix at dworkin.nl>
To: <dgd at list.imaginary.com>
Sent: Saturday, August 16, 2003 9:20 PM
Subject: Re: [DGD] Java or LPC (DGD)?


> "Albert Deinbeck" <albert-deinbeck at albert-deinbeck.de> wrote:
>
> >[...]
> foo = loader.defineClass("foo", s1.getBytes(null), 0, s1.length());
> foo = null;
> // the following will fail
> foo = loader.defineClass("foo", s2.getBytes(null), 0, s2.length());
>     }
> }
>
> ---end of test.java---
>
> This ClassLoader loads the class foo, unreferences it, and attempts to
> reload a different version of it, resulting in the following error:
>
> Exception in thread "main" java.lang.LinkageError: duplicate class
definition: foo
>         at java.lang.ClassLoader.defineClass0(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:431)
> at test.main(test.java:55)
>
> Going through the forName() method changes nothing when you still wind up
> in the same ClassLoader instance.

After rereading the Java VW Spec I must sheepishly admit that you are
perfectly right.
This means of course that what you said about different classloaders and the
namespace problem is also true.
So each object has it's own namespace and communication has to take some
external way in order to simulate a common
namespace.
In this regard there is a question I couldn't answer yet. Classloaders
follow a delegation model the primordial CL being the root.
If classes from custom CLs access the static member of a class loaded by the
root CL, do they access the same or copies?


> >[...]
> > Interfaces should not and cannot be as mutable, as they are what others
rely
> > on.
>
> I think you are confusing the general intended use of interfaces, and
> the particular use that you yourself advocate here.  True, Java-style
> interfaces are not supposed to be changed, and that is exactly why no
> interfaces should be used in this case.  You are suggesting the use of
> an interface for <every reloadable class>, not just for those that have
> to interact with the classes of others.
>
> I suggest the following as an exercise: write a medium-sized program in
> Java by first creating interfaces for <every> class without writing any
> of the class code itself; when this is done, you are allowed to write
> the class code, but without making any changes to the interface or
> adding any methods which are not in the interface.
>
> Surely you will see that this is unworkable.  All you have done is set
> your design mistakes in stone.  And that is just for a medium-sized
> program that does not even have to be persistent.

Apart from the fact that in the light of the above direct method calls
aren't feasible...
It seems the only way is to use reflection for method calls.
I thought about using the Proxy class to connect to an actual class
instance,
but that brings the requirement of an interface for the class.
I do not think interfaces should be set in stone, but they should change
less frequently to
allow for distinct names and files for them.
Interfaces are mere logical constructs required by the compiler. The VM does
not know them.
So it's easy to replace an interface as long as you make sure all classes
using it are recompiled.
You could put all classes implementing the command interface in one package
and compile them all
once CommandInterface has changed, for instance...

I would also think that java classes and world objects would not be equal,
but that there is a bunch of java
instances representing one world object. These would be serialized together
and live in the same namespace...


Regards,
Albert


_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd