Mailing-List: contact bcel-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "BCEL Users List" <bcel-user@jakarta.apache.org>
Subject: Re: Modification of java.lang.Object
From: Daniel Schregenberger <npfdd@gmx.net>
To: BCEL Users List <bcel-user@jakarta.apache.org>
In-Reply-To: <200405120144.31758.asinus@heavy-metal.de>
References: <1084305680.7572.29.camel@localhost>
	 <200405120144.31758.asinus@heavy-metal.de>
Content-Type: text/plain
Message-Id: <1084402096.7508.16.camel@localhost>
Mime-Version: 1.0
Date: Thu, 13 May 2004 00:54:41 +0200
Content-Transfer-Encoding: 7bit

Hello

> afaik java.lang.Object is something like another primitive type. I.e. in the 
> jvm there are value types and there is one reference type which is 
> java.lang.Object. As all other classes are derived from this one, variables 
> having a type of class xyz are also treated as references. That's the only 
> thing I do know which might create a need to bind this class tightly to the 
> jvm and cause trouble if you add references into java.lang.Object itself.

I noticed that the GNU classpath project had a note about this. ie: when
you use GNU classpath for your own VM, you have to implement some stuff
in your VM.
But our goal is (was?) to use a standard VM.

> BTW: Why the hell should anybody have to modify this class? Would be very 
> interesting to know. 

I'm implementing dynamic Type checking for the Universe Type System.
This is a way of making sure object structures don't leak and nobody
outside can modify anything inside and break invariants. Here's a link
to a paper if you're interested:

http://sct.inf.ethz.ch/publications/papers/MuellerPoetzsch-Heffter01a.pdf

> There might also be some ways to solve your problem...

Yeah, it looks as if I have to think of one :)

-- Daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org