db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew McIntyre <mcintyr...@gmail.com>
Subject Re: Single JDK14 compile model?
Date Sun, 06 Mar 2005 06:51:18 GMT
On Mar 5, 2005, at 8:54 AM, Daniel John Debrunner wrote:
> 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 

- 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 

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.


View raw message