clojure-dev

Issues: https://clojure.atlassian.net/browse/CLJ | Guide: https://insideclojure.org/2015/05/01/contributing-clojure/
dominicm 2019-02-21T12:11:36.022200Z

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, https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L444-L447 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?

dominicm 2019-02-21T12:26:09.022900Z

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

alexmiller 2019-02-21T13:15:49.025Z

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?

dominicm 2019-02-21T13:17:42.026200Z

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

alexmiller 2019-02-21T13:19:47.027600Z

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

alexmiller 2019-02-21T13:21:22.028200Z

0 is not fixed imo

dominicm 2019-02-21T13:27:52.028900Z

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

dominicm 2019-02-21T13:31:53.030600Z

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

dominicm 2019-02-21T13:32:08.031100Z

I could do some hacking on onejar perhaps.

alexmiller 2019-02-21T13:41:08.032300Z

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

dominicm 2019-02-21T15:09:46.033400Z

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

dominicm 2019-02-21T15:35:40.033700Z

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

dominicm 2019-02-21T15:36:01.034500Z

Anyway, it's perfectly normal for a URLConnection to return 0: https://docs.oracle.com/javase/7/docs/api/java/net/URLConnection.html#getLastModified() It's a special case defined.

alexmiller 2019-02-21T16:31:58.035200Z

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

alexmiller 2019-02-21T16:32:38.035600Z

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

alexmiller 2019-02-21T16:32:48.035900Z

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

dominicm 2019-02-21T17:47:52.036300Z

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

seancorfield 2019-02-21T17:54:45.038100Z

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.

dominicm 2019-02-21T18:06:33.039100Z

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.

dominicm 2019-02-21T18:07:06.039900Z

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