6

I changed a couple of classes in my Grails project and built a war file. I then compared the .class files from the new war to the ones in the war which was built before my changes (on a different machine, if that matters) and it turns out that many (if not all) .class files are different. Looking at the decompiled classes it seems that the differences are because of a timestamp in a variable such as this:

public static long __timeStamp__239_neverHappen1360886953029;

Does anyone know what this variable is?

zoran119
  • 10,657
  • 12
  • 46
  • 88

2 Answers2

3

It comes from groovy class generation.

See some discussion here http://groovy.329449.n5.nabble.com/Timestamp-in-class-files-leads-to-huge-patches-td365696.html

For the sake of completeness , quoted here:-

For Groovy's own recompilation mechanism. Sources are not always in file form, so we can't "just" check the file timestamp, so we had to store that timestamp somewhere... and where better than in the class itself since that's all we have?

On Tue, Mar 3, 2009 at 10:39, Jason Dillon <[hidden email]> wrote:

Why does groovyc capture the compile timestamp? What good is that for?

Jayan
  • 18,003
  • 15
  • 89
  • 143
1

This changed in Groovy 2.4, the .class files no longer contain a timestamp field.

https://github.com/groovy/groovy-core/commit/bcdb89e

Emmanuel Bourg
  • 9,601
  • 3
  • 48
  • 76