On 8/3/07, billf5293 <[EMAIL 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 believe). Hope this helps. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
