Daniel John Debrunner wrote:
The trick I then use is to modify the class file sometime after compilation to mark it concrete by modifying the byte code in the .class file (using Derby's class file utilities). This does not cause any problems with the JVM (though there are some issues with the current version of jikes that Derby uses).
Jeremy Boynes wrote:
This really really worries me and I am very uncomfortable with it.
Can you expand on your concerns?
Having grown up patching object code on mainframes, any form of manipulation of the binary concerns me. Yes, this is a fairly simple modification but nevertheless it is the principle that is troublesome.
The obvious issue is that the object will no longer match the source - if I examine the class I see that it is concrete, if I examine the source then it is abstract. All the doco in the world is just a band-aid over that difference.
There is considerable reluctance in enterprise environments about any form of byte code manipulation. Enterprise users do not like obfuscation as it makes support and diagnostics harder and has no benefit to them. They have serious concerns about frameworks that manipulate bytecode directly, for example the enhancers in JDO or the instrumentation done by AOP frameworks.
In this case all is doing is allowing us to support JDK1.3 and JDK1.4 (or specifically JSR169, JDBC2.0 and JDBC3.0) in one jar. Most users, embedded, ISV or enterprise, are running in a configuration where the JVM version is known and can be matched to a suitable database JAR.
Having one JAR for the database is nice, but not if the price is post-compilation bytecode hacks.
-- Jeremy
