Stomp

Known Restrictions

 

The following is a list of the current known restrictions in Stomp.  Many of these will be removed transparently as Stomp matures, but a few may not.  See the prognosis for each for more details.  Of course, if any of these bugs is mission critical for your application, you may be able to fix it yourself.  Email me (ericl@hcmny.com) for more detailed information about how to attack these.  You can also drop me a line to try to convince me to get on some of these, but I can’t promise anything J.

 

Things in black are current issues. 

Things in orange are old issues that have been fixed.  They are included to give you an idea of where Stomp has been, where it might be headed, and how accurate the original prognosis was…

 

The (probably) permanent problems:

-         Static blocks get evaluated during enhancement.

o       Description: Enhanced classes are loaded during enhancement in order to get at their bytecode and modify it.  This can result in side-effects that make sense at runtime but not at enhancement time.

o       Prognosis: Bad.  This will likely be a problem for a long time.  If you wanted to remove this restriction, you’d have to re-implement several features of the Serp bytecode toolkit so that it could do all its work without ever using a Class.forName. I believe this is possible, but realistically not going to happen any time soon.

o       Work-around: Fortunately, it’s almost always possible to move problem code out of static blocks.  Try instantiating variables lazily, having a startup function that gets called when you start up the application, etc.

-         Private methods are made protected during enhancement

o       Description: Like the name says.  This could be a problem if you are using the private keyword as a runtime security measure, and not just a tag to inform other developers that you don’t mean for them to call the method directly (note that the private keyword will still be around at compile time, so it still accomplishes this last goal).

o       Prognosis: Bad.  This may always be a problem.  Since Serp breaks up one logical entity into two classes, a proxy and a delegate.  The proxy needs to be able to invoke the private method in the delegate and vice versa.  I am not aware of a Java mechanism that would allow only a single class access rights to a method.

o       Work-around: Use some other means to secure your runtime application.

 

Known issues that should be resolved in time:

-        (Solved 2002.10.7) Line numbers are not available in stack traces for enhanced objects.

o      Description: The line number table is not correctly setup for the delegate in the proxy-delegate pair.  Stack traces say something like (Unknown Source) where a line number would normally be found.

o      Prognosis: Good.  I’m not sure why it doesn’t work right now.  It should just be a matter of hunting down the bug in transferring the line number table to the new class file.  The line number table itself should not require any modifications, apart from keeping the targets setup correctly.

o      Work-around: Not available.

-         Have to enhance entire object hierarchy.

o       Description: Unlike JDO, which allows different parts of the inheritance tree to be enhanced independently, stomped classes have to have the entire tree enhanced.  In particular, this means that persistent classes cannot extend any objects in the standard java libraries.

o       Prognosis:  Unclear.  I haven’t spent too much time thinking about how to get around this, since I can’t imagine using this feature myself.  More research is needed.

o       Work-around: Use a “contains” relationship to parent classes that you might have preferred to extend.

-         No support for direct access to non-static member variables in enhanced classes.

o       Description: If you declare a member variable in an enhanced class public or protected, and access it directly from a non-enhanced class, method calls made on the object will not be enhanced.

o       Prognosis: Very good.  The only reason this isn’t already in there is that you really should never do this anyways, and it might be better not to turn on this ‘feature’ at all.

o       Work-around: Don’t access member variables directly from other classes.  Use getters and setters.

-         No support for altering contents of a Collection outside persistent class.

o       Description:  A persistent object returns a Collection that represents persistent data to some other object.  This other object modifies the collection.  This results in a JDOException, since no Transaction is started.

o       Prognosis:  Good.  It is theoretically possible to intercept these calls and start transactions (and other method-level services) as appropriate.  It just hasn’t been implemented yet.

o       Work-around:    The truth is, you shouldn’t do this anyways.  Keep your data private, and provide mutator methods that do the work inside the persistent object.

-         (Solved 2004.11.17)‘This’ pointer not fully supported transparently.  Can’t enhance non-static inner classes.

o       Description:  Stomp breaks a single class into a proxy-delegate pair.  The problem is that when a developer uses the ‘this’ pointer, sometimes this logically refers to the delegate, and sometimes this logically refers to the proxy.  Currently, ‘this’ is often left to mean the delegate.  This can cause problem in which an object obtains a handle to a delegate, when it really should have a handle to a proxy, as in the following cases: when ‘this’ is returned from a method, passing ‘this’ as an argument in a method call, non-static inner-class constructors.

o       Prognosis:  Good.  Analyzing the bytecode to find these cases is complicated, but progress has already been made with the StackAnalyzer. 

o       Work-around: Use WrapperFactory.singleton ().wrap (this) whenever you would otherwise have returned ‘this’ from a method or passed ‘this’ as an argument to a method.  Use static inner-classes, but pass an argument to the enclosing object in the constructor call (using WrapperFactory.wrap (this) of course…).

-         (Solved – 2002.9.3) Can’t use ‘switch’ statements in enhanced objects.  

o       Description: Limitation of the StackAnalyzer prevents use of switch statements.

o       Prognosis: Very good.  This should not be difficult once there is time to get it done.

o       Work-around: Replace switch statements with if/else blocks.

-         (Solved 2004.11.15) Can’t use ‘this’ pointer in ‘catch’ blocks.

o       Description: A combination of poor support for ‘jump’ statements in the StackAnalyzer, and complexities surrounding the ‘this’ pointer, make it the case that using the ‘this’ pointer (even implicitly, like calling a non-static method of ‘this’) in catch blocks is forbidden.  The result is invalid bytecode.

o       Prognosis: Very good.  As with support for switch statements and transparently handling ‘this’, this bug simply involves making the StackAnalyzer more robust.

o       Work-around: Case-by-case.

-         Private / protected / static methods are not serviced.

o       Description: Only public, non-static methods receive the benefits of the Stomp service layer.  In particular, if you have a protected method that changes persistent fields, you’ll run into JDOExceptions because no transaction will have been started.

o       Prognosis: OK.  There is no theoretical reason why these methods can’t be serviced; it just doesn’t fit naturally into the current design.  The proxy will have to become more intelligent about how it delegates these method calls.

o       Work-around:  Use singleton patterns in place of static classes.  Make protected mutator methods public (ouch), or handle the transaction management yourself inside this method (calling JDOFactory.getTransactionalPersistenceManager (), etc).

-         Can’t use the ‘declareImports’ feature of JDO queries

o       Description: Stomp needs to convert variable and parameters defined in queries to use the name of the generated delegate, not the proxy.  Currently this works from a simple String lookup, which requires the fully qualified name of the class.

o       Prognosis: OK.  There is no reason this couldn’t be done, the information is certainly available, and any JDO1.0 compliant implementation must have code that basically does this already implemented.  The only reason it may not come immediately is that I don’t have that code, and this feature doesn’t seem worth the time right now (see list of other restrictions above).  Maybe some kind JDO vendor will implement this for us…

o       Work-around: Remove calls to query.declareImports, and instead use fully qualified names in your filter, parameter, and variable declarations.