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.
I certainly agree that this is a much more minimal change to the classfiles than the obfuscation process. After looking at the spec for the class file structure, there are only two (very) minor concerns that I see with marking a classfile not abstract after compiling it as abstract:
- we should be careful to *just* clear the bit ACC_ABSTRACT, in case other bits in that byte are used for other purposes in the future.
- any classfile modified in this way probably should not be subclassed, to avoid possible problems compiling or verifying classes in past or future JVMs. This could be achieved in the source by clearly documenting classes to be modified this way, and in the binary by setting ACC_FINAL at the same time that we unset ACC_ABSTRACT.
Or maybe even simpler, just write a explicit program that only modifies that byte at the correct offset in the file, in place.
Well, we can't just change a particular offset in the classfile, since a classfile's constant pool structure comes before the class' access flags. I suppose it would be fairly straightforward to write a program that accounts for that as well, but I believe you said you already had this working using Derby's classfile utilities, yes? :-)
On Mar 5, 2005, at 8:46 AM, Daniel John Debrunner wrote:
2) GUMP - It seems Derby has to be part of Gump, but Gump's philosphy is
very different to Derby's, it basically says the product build rules are
wrong and it must build using gump rules. Maybe I'm wrong on this?
I think that we should definitely make an effort to build in the Gump environment. Since other projects could (hopefully, will :-) ) be added to Gump that require Derby as a dependency and want to build as a part of the Gump nightly process, we should make an effort to build properly there for the sake of being part of the community. But. I'm sure we'll be forgiven for occasional Gump breakage due to major changes happening here.
Also, I wouldn't say that Gump's build process implies that each product's build rules are wrong. Gump just overrides the compilation classpath as an expediency to cross-product integration. Instead of having to know how each project expects to find its dependencies, it puts the latest version of each dependency on the compilation classpath and expects the compiler to take care of the rest.
In fact, I think Derby is the first project built by Gump to require more than one version of the Java runtime libraries at a time, which accounts somewhat for the contortions that were necessary to fit our build into the current Gump build model.
andrew
