> You know what I am thinking?
> where is the Open Source VM when you need it?
> where are the 'overwritten' native types
> implementations you can just "drop in"... here is a
> new definition of java.lang.String with AOP
> instrumentation. Have a good day sir.
> I can hear the security cries from here and the
> lawyers from there...
> Eli, gives us numbers as to whether automated
> analysis would cover us and whether it covers all
I don't really care if it covers all cases. If it doesn't, we define a contract just the same way EJB does, CORBA does. We define the semantics on how to use the framework along with our limitations.
I think our limitations for system classes are going to be system classes that allocate other system classes.
> If not we are about this close to going with get/set
> access to the state. It is about as cumbersome as
> requiring custom wrappers for all native types but
> there it is. bleh.
get/set, so what, you still have the same problem.
private HashMap blah
Of course we're going to implement some AOP services! The first will be Transaction demarcation (trans-attribute), security (method/role shit), and transaction locking since these are the easiest to implement and port quite nicely from our current EJB interceptors.
Next will be caching and distributed caching. Next will be the AOP persistence framework. Check out the forums on both!