Fork me on GitHub

(and further tracked it down to only happening in a depstar-produced JAR, rather than a full boot-produced JAR... so absolutely nothing to worry about it in this channel!)


(which points to similar issues with gradle-clojure and timestamps in JAR files!)


I think I recall that the file timestamps can matter if there are .class files older/newer than a similarly named .clj file for the same namespace. Are there other known cases where timestamps in JAR files matter?


Yep. That happened to me with Maven shade plugin before


It sets all time stamps to the same, so clj and class files become the same time, which causes the clj to be JIT compiled over again instead of using classfile


In Maven I had to just use exec plugin to script it to open the shaded jar, and bump all clj files timestamp to some time in past


Or you can remove all clj files if all class files are there.


But I don’t know specifically the problem here. Just saying I’ve had timestamp drama before with aot


I fixed (my fork of) depstar to preserve timestamps in JAR files and that fixed the issue. It doesn't (yet) preserve timestamps for locally included files but it probably should. Also for directories, to be really paranoid.


The whole thing does seem to make AOT very fragile when source files are still in scope (as if AOT isn't already known to be a giant can of worms!).


yikes. good find! I was bitten by this in bootstrapped katamari tonight. will be eyeballing your patch in the morning.


I agree on it being fragile. Definitely have to careful on those timestamps. Hah


as best as I can tell, direct linking only optimizes function calls, is that correct? in particular, it doesn't optimize uses of a var that aren't in the call position, whether the var contains a value or it's a function used in HOF style this makes more sense when I say it out loud; I guess for values I could imagine it being equivalent to ^:const