Fork me on GitHub

I'm seeing a case where clojure.core is loaded twice. I think it's because my class loader is reporting 0 for "getLastModified". Normally, is true, which goes down into loadClassForName which eventually checks whether the class is already loaded or not before actually loading it. Because my getLastModified is 0 though, I end up in if(!loaded && cljURL != null) { which has no conditional to it's loading, it just unconditionally loads it. Should that second path be looking at whether the class is already loaded before running? Or perhaps should loaded default to a check, rather than false?


alternatively, instead of lastModified > lastModified, you could do lastModified >= lastModified, but I don't actually know the repercussions of that.

Alex Miller (Clojure team)13:02:49

I think you should back up and consider that the classloader is telling you the wrong value for lastModified. Isn’t this exactly the onejar ticket you linked to?


The lastModified was null in the ticket I think, and it was fixed by changing to something which returns 0

Alex Miller (Clojure team)13:02:47

Why can’t onejar actually retain the real time stamps? The issue being that you want class time stamps newer than clj timestamps


Yeah, that's a good question, and not one I have an answer to.


I would guess that it is trying to avoid unzipping the jars maybe, or it is just naïve.


I could do some hacking on onejar perhaps.

Alex Miller (Clojure team)13:02:08

The info is in the inner jar, doesn’t seem like there’s any reason you couldn’t use it


I'm trying to figure out where this is going wrong. It is just delegating upwards, so I'm trying to figure out if I can override the method to check inside the jar, the internal interface isn't too clear


I think it's something to do with OneJar's use of a byte cache.


Anyway, it's perfectly normal for a URLConnection to return 0: It's a special case defined.

Alex Miller (Clojure team)16:02:58

clojure is a published artifact with different class and clj files in it and they have different timestamps, and that's important to Clojure

Alex Miller (Clojure team)16:02:38

so regardless whether 0 is a valid value for the method, it's yielding a different environment

Alex Miller (Clojure team)16:02:48

I'm still of the opinion that's on onejar, not on Clojure


I have a patch to the vendored onejar which is doing the trick to expose the last modified


One of the bugs I fixed in depstar was that it didn't preserve timestamps when creating the JAR file and that bit me quite badly until I figured out the problem. Hence, we use my fork of depstar at work.


Latest version of pack has a patch to onejar to override the getLastModified. For the most part, pack avoids the last modified problem inherently, as it doesn't explode any jars.


But onejar was caching bytes for classes, and creating ByteArrayOutputStreams, which when proxied through the URLConnection didn't have LastModified information attached.