Hello! > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
