Java Mailing List Archive

Apache Ant Archive

» Ant Users List
» Ant Developers List
Problem with build after method signature change

Problem with build after method signature change

2007-08-03       - By Dominique Devienne
Reply:     1     2     3     4  

On 8/3/07, billf5293 <bfindeisen@(protected)> wrote:
> Thanks for the reply.
> The reason we are doing these incremental builds is because unfortunately we
> use very large applets containing a number of jars.  One of the biggest
> complaints we have about our product is the fact that downloading all these
> jars after an update is time consuming.  With these incremental builds only
> the jars that need updating are touched allowing the client to use cached
> jars for those jars that aren't updated.

Javac by default does not include any timestamp information, and if
you compile with debugging information off (which I'll assume, to
minimize download size), then the source file name for the classes is
also omitted.

Where I'm getting at with this is that a Jar rebuild after a clean
build *should* be binary equivalent if it didn't require any byte code
changes. UNLESS you include yourselve a build number or date in the
manifests of your jars that is ;-)

Of course I'm assuming that Javac is fully deterministic, which may be
incorrect, especially if it uses hash containers, yet I suspect the
hashed keys are symbol, so only different symbols would shuffle the
"order" of the container entries.

So it's one avenue to explore to minimize downloads, i.e. post-process
the new jars to see if they have trully changes in their bytecode.

Another avenue is to look into pack200, which can dramatically reduce
the size of jars (up to 10x smaller) but using a single constant pool
for all classes of a jar. Requires recent JDKs though (> 1.5 I

Hope this helps. --DD

To unsubscribe, e-mail: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)

©2008 - Jax Systems, LLC, U.S.A.