Hi, 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: 3-930673-73-8 > > > 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 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 :-). Cya, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
