db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Single JDK14 compile model?
Date Sat, 05 Mar 2005 17:43:00 GMT
Daniel John Debrunner wrote:
>>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.


View raw message