I tried to use clojure from fedora (1:1.11.2-2.fc41) and got an ugly java exception instead of a more friendly error message. Some searching online [1] suggested that the reason may be that the aot compiled class files in the clojure jars are considered "out of date" if they have the same timestamp as the clojure source files. I also experienced a significant delay for clojure --help on a less powerful machine which would support this theory. I unpacked clojure.jar and all of the files had the same timestamp: Modify: 2024-07-17 00:00:00.000000000. [1] https://www.mail-archive.com/clojure@googlegroups.com/msg99928.html Reproducible: Always Steps to Reproduce: 1. clojure thisfiledoesnotexist Actual Results: An ugly java exception: Exception in thread "main" java.lang.ClassCastException: class clojure.pprint.proxy$java.io.Writer$IDeref$PrettyFlush$4923d848 cannot be cast to class clojure.pprint.PrettyFlush (clojure.pprint.proxy$java.io.Writer$IDeref$PrettyFlush$4923d848 is in unnamed module of loader 'app'; clojure.pprint.PrettyFlush is in unnamed module of loader clojure.lang.DynamicClassLoader @5b55c3d6) at clojure.pprint$pretty_writer$fn__7210.invoke(pretty_writer.clj:392) at clojure.pprint.proxy$java.io.Writer$IDeref$PrettyFlush$4923d848.flush(Unknown Source) at clojure.core$flush.invokeStatic(core.clj:3713) at clojure.core$flush.invoke(core.clj:3707) at clojure.core$prn.invokeStatic(core.clj:3724) at clojure.core$prn.doInvoke(core.clj:3716) at clojure.lang.RestFn.invoke(RestFn.java:397) at clojure.pprint$pprint.invokeStatic(pprint_base.clj:252) at clojure.pprint$pprint.invoke(pprint_base.clj:241) at clojure.pprint$pprint.invokeStatic(pprint_base.clj:245) at clojure.pprint$pprint.invoke(pprint_base.clj:241) at clojure.lang.Var.invoke(Var.java:384) at clojure.main$report_error$fn__6649$fn__6650.invoke(main.clj:603) at clojure.main$report_error$fn__6649.invoke(main.clj:602) at clojure.main$report_error.invokeStatic(main.clj:601) at clojure.main$report_error.doInvoke(main.clj:584) at clojure.lang.RestFn.invoke(RestFn.java:439) at clojure.main$main.invokeStatic(main.clj:666) at clojure.main$main.doInvoke(main.clj:616) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.lang.Var.applyTo(Var.java:705) at clojure.main.main(main.java:40) Expected Results: Execution error (FileNotFoundException) at java.io.FileInputStream/open0 (FileInputStream.java:-2). thisfiledoesnotexist (No such file or directory I adjusted the timestamp of the class files manually and reassmbled the jars: cd /tmp/clojure jar xf /usr/share/java/clojure/clojure.jar find . -name "*.class" -exec touch {} \; find . -exec zip -X clojure.jar META-INF/MANIFEST.MF {} + and also for /usr/share/java/clojure-spec-alpha/spec.alpha.jar and /usr/share/java/clojure-core-specs-alpha/core.specs.alpha.jar and things started working again. Additonally affected packages: clojure-core-specs-alpha, clojure-spec-alpha and potentially more.
Hi, thanks for the bug report! I was able to reproduce it. As per the link to the mailing list discussion, it a result of the maven build. The clojure in Maven central ( https://mvnrepository.com/artifact/org.clojure/clojure/1.12.0 ) seems to have same timestamps for clj and class files as well.
(In reply to Markku Korkeala from comment #1) > Hi, thanks for the bug report! I was able to reproduce it. As per the link > to the mailing list discussion, it a result of the maven build. The clojure > in Maven central ( > https://mvnrepository.com/artifact/org.clojure/clojure/1.12.0 ) seems to > have same timestamps for clj and class files as well. For me they seem to be different. Some random files i checked from the maven jar: TZ=UTC stat clojure/core.clj Modify: 2024-09-05 17:03:32.000000000 +0000 TZ=UTC stat clojure/core\$add_classpath.class Modify: 2024-09-05 17:03:42.000000000 +0000 TZ=UTC stat clojure/math.clj Modify: 2024-09-05 17:03:32.000000000 +0000 TZ=UTC stat clojure/math\$random.class Modify: 2024-09-05 17:03:46.000000000 +0000 the exact second difference looks like to me this is someting that the process that built the jar takes care. The timestamp in the fedora jar seems to correspond to SOURCE_DATE_EPOCH envvar that is set by rpm during the build. My guess is that something is causing the timestamps of the class files (or rather all files) to be reset back to SOURCE_DATE_EPOCH from whatever the jar build process set it to and i am unsure how to figure who/what is responsible for this. I couldnt find any reference to SOURCE_DATE_EPOCH in https://github.com/fedora-java/javapackages version 6.2.0 I checked the debian/ubuntu libclojure-java package (which I presume also use SOURCE_DATE_EPOCH to control timestamps in artifacts) and didnt encounter the problem there but i couldnt figure out if this is something that is manually adjusted. originally i encountered this trying to use a separate tool that expected the "normal" clojure-cli interface and as someone new to clojure it was not obvious to me that this is different thing than the clojure command from the fedora package, i.e. clojure.main from the clojure.jar, especially if all I had was a cryptic exception.
(In reply to dariqq from comment #2) Another solution would be to patch clojure to relax the timestamp check to include the equal case as well. After a bit of grepping around i think the relevant part might be here https://github.com/clojure/clojure/blob/clojure-1.12.0/src/jvm/clojure/lang/RT.java#L462 however there might be other tools that rely on the current behaviour which such a change would break.
I found the thing that is responsible for resetting the timestamps: The add-determinism executable (https://github.com/keszybz/add-determinism) that runs as part of %__os_install_post. From their documentation jar Accepts *.jar. This rewrites the zip file using the zip crate. The modification times of archive entries are clamped to $SOURCE_DATE_EPOCH. Extra metadata, i.e. primarily timestamps in UNIX format and DOS permissions, is stripped (also because the crate does not support them).
This message is a reminder that Fedora Linux 41 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '41'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 41 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This is still an issue on Fedora 43. I think the best way to resolve this if Fedora insists on clamping timestamps in jars is to patch clojure to not consider a compiled file in the jar with excatly equal mtime as out of date. If this is just going to get closed after no response after 8 months I am questioning why I created an issue at all if I can just easily fix the package for myself.
Sorry I haven't had time to work on this. The cause for timestamp modification in jars is due to making builds reproducible, see more https://reproducible-builds.org/ and https://docs.fedoraproject.org/en-US/reproducible-builds/ . Thank you for gathering all the information. I was able to fix the issue by removing determinism from clojure and it's deps (clojure-spec-alpha, clojure-core-specs-alpha) with option %define add_determinism_options --handler=-jar : $ clojure asdfasdfadsf Execution error (FileNotFoundException) at java.io.FileInputStream/open0 (FileInputStream.java:-2). asdfasdfadsf (No such file or directory) Full report at: /tmp/clojure-3767769310059727090.edn This could be the fix for now. If the determinism is required for the builds for reproducibility, then we might look for some other option.
Hi, I found the same bug in debian also mentioning the loss in performance: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877418 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877418 has 2 proposed solutions: a) change the ">" to a ">=" where clojure checks if a .class is out of date. b) Clamp clj files in jars to SOURCE_DATE_EPOCH - 1 (or similar) to appease clojure. This would still be reproducible. Debian went with the option b by adding an exception to their strip-nondeterninism https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/commit/7691e2980274c1b041b8730bae5a8f5374cbcbf1 Maybe something similar be done with the 'add-determinism' on fedora? If the point is determinism a fixed offset would still be deterministic. I apologise for being a bit frustrated but the incredibly slow performance caused by recompiling clj files over and over again on my slower machine was not a great experience.
No worries, I can understand the frustration. I submitted a fix with: %define add_determinism_options --handler=-jar . It should land soon in F43 testing if you want to test it: https://bodhi.fedoraproject.org/updates/FEDORA-2025-bafa3ebf74
Thank you very much. Should this be forwarded to 'add-determinism' that it does not work well for jars containing clojure files? I don't think there are currently other clojure packages in fedora but if there are some in the future they will probably have the same problem.
FEDORA-2026-04c69b17fd (rust-add-determinism-0.7.3-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-04c69b17fd
FEDORA-2026-04c69b17fd (rust-add-determinism-0.7.3-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
I included the bug number in the update for add-determinism so this got closed automatically. But that update by itself doesn't actually have an effect, clojure would need to be rebuilt. OTOH, the clojure update that disables add-determinism also went stable a long while ago, so the issue is actually fixed and this bug should have been closed. So I'll leave it like that. Anyway, add-determinism that should resolve the issue on next clojure build in in rawhide and f44-updates-testing. I think it'd be nice to disable the workaround in clojure when there's a next rebuild. (For f44 it might be necessary to use a side-tag or a build override if the update hasn't gone stable yet.)