> 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. Dan.
