jakarta-bcel-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Breuer <asi...@heavy-metal.de>
Subject Re: Modification of java.lang.Object
Date Thu, 13 May 2004 00:25:31 GMT

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

On Thursday 13 May 2004 00:54, Daniel Schregenberger wrote:
> 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.

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:

> > 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 :)

OK :-)  - anything I know about access control to instances (maybe you already 
know this stuff):
In J2EE and in JSDK implementations access control to instances of "modules" 
(i.e. anything running in the same Servlet Context) is restricted by the use 
of specific class loaders for each modules. So, there is a global class 
loader which loads the types for all Servlet Contexts and a special one for 
each Servlet Context. Each Servlet may just access Types which are loaded by 
its own class loader or by a superordinated class loader. Modules in J2EE 
work the same way. So, you may restrict the access to certain Types by 
creating a class loader for each module. Whenever somebody from outside tries 
to access a instance of this module, a ClassNotFoundException is thrown.
Some other more sophisticated possibilities are offered by the 
SecurityManager. You may define restriction policies based on java packages. 
But I dont know how that exactly works and what it can do.
So you might create a class for each universe where an instance of a type will 
occur and let the universe run in it's own class loader and the interface 
type to this univers in the superordinated class loader. The result would be 
that you will lose a lot of memory because the same code might appear in lot 
of class files. On the other hand it is not possible to implement the 
difference between a RW and a RO access to an object, so this approach doesnt 
fit the needs.

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. 

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 
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.

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



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

View raw message