jakarta-bcel-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Schregenberger <np...@gmx.net>
Subject Re: Modification of java.lang.Object
Date Thu, 13 May 2004 19:03:38 GMT

> just took a short look at the document. Very interesting approach.

Yes. I think after reading the first two chapters you know the concept,
the rest are proofs and deeper toughts about it.

> > > 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.
> I got that from a very good book about jvm internals:
> Java Virtual Machine by Matthias Kalle Dalheimer
> Published by O'Reilly in 97. ISBN of the German Print:
> 3-930673-73-8

Thanks for the hint. I'll try to find a copy of this book and see if it
provides me with some information that might help.

> > > 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 :)
> A way I do use to fool about references in a persistency/network access api is 
> to replace the original class f.e. Address with an own class which does 
> implement all interfaces of the original and offer all operations of it. The 
> original class is relocated to f.e. AddressSubject or another package. So a 
> "new Address()" creates in fact an instance of the replaced class which will 
> also cause the creation the original (if needed, i.e. when it is accessed the 
> first time). All calls to the instance are routed (maybe over the network) to 
> the original class or do end up in modifications of database table fields. 
> Like this you do have the possibility to step in between. I do use bcel for 
> these modifications but a precompiler could do the same. 

Modifying java.lang.Object would be easier I think.
I think I would have to wrap all JDK classes and the bootstrap problem
would be present again. (see below why I need all JDK classes to have
that attribute)

> I assume that you do need a (pre)compiler for your extensions because you also 
> did extend the java syntax. A simple way to implement instance access control 

There is a compiler, yes. It's not yet published as there's still much
work to do.

> would be that the precompiler adds "this" as first parameter to all calls. So 
> it could transfer "Address myAddress = new Address()" to "Address myAddress = 
> new Addres(this)" and "myAddress.setStreet(...)" to 
> "myAddress.setStreet(this, ....)". Your replacement of Address would now have 
> a hook to set the owner of an instance or to check if the caller is allowed 
> to perform the operation he wants to perform.

The information I need is a field containing the owner of the universe
the object is in.
To be fully usable, we need this info on every object, also the ones in
the JDK. If I got your idea right, this will not work for me.
I think I will use a hashtable that can be accessed over a static
function or something like that.

> Hope that you will find a solution as this looks _very_ useful to hackers like 
> me :-).

Yeah, I hope so too :)

-- Daniel

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

View raw message