db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Single JDK14 compile model?
Date Sat, 05 Mar 2005 16:54:54 GMT

> 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?

And Andrew McIntyre added:

> I'd rather put the time in myself to keeping our
> build running in Gump than deal with problems caused by modifying the
> classfiles at build time (I'm thinking of all the fun I've had with
> obfuscation).

Marking an existing class file as not abstract is a zero risk operation
to the structure of an existing classfile. The operation is simply
changing one bit in the access_flags field in the header of the class.
The old Cloudscape obfuscation tool did a huge amount of manipulation of
the class file, including modifying the byte code stream. Because of
that experience I intentionally made sure this process was zero risk and
didn't require huge changes in the class file.

For an existing class file the on-disk structure (the class file format)
is deterministic, thus a double check could be added to the "mark as
concrete" process to ensure every byte of the class file matches the old
version with the exception of the access_flags. Or maybe even simpler,
just write a explicit program that only modifies that byte at the
correct offset in the file, in place.


View raw message