Re: Checksum with no creation date
Roedy Green wrote:
The advantage of embedding the compiled date in the class file is that
you can tell for example if the a class file were compiled with the
old or new version of JavaC [sic]. Normally it does not matter, but if there
As Jukka said, that is not true.
were a bug in Javac or a new optimisation, it might.
Further, it is necessary to do a clean compile to propagate new values
of public of package static finals. You want a way to make sure
EVERYTHING got recompiled.
That's only true if they're compile-time constants, but not generally.
I wrote a program called JarCheck which does a similar check to make
sure every module was compiled with the proper JDK level target. It
There's a standard way to do that, and it has nothing to do with dates. Dates
wouldn't work, as Jukka explained. The class version, OTOH, is reliable and
is in there for just that very purpose.
is amazing how often it gets out of whack. see
You might cannibalise some of the logic in it for your program.
It sounds like you would need a checksum program than understood the
class file format, and optionally skipped that embedded date. There
What embedded date? There's no embedded date in the classfile format! As
this thread had already established.
are also embedded timestamps in the zip/jar format not embedded in the
class file members. See
The game may not be worth the candle. Are you using ANT? Builds are
is so much quicker than doing it with bat files. It loads JavaC only
once. Many years ago Jonathan Revusky invented a primitive sort of
ANT. It speeded things up 100 fold over the Linux make we were using.
Honi soit qui mal y pense.