could it be "another" kind of reflection warning? i.e. caused by newer JDK intricacies, not by a lack of type hints would help if you post the output here

Prefer clojure.data.xml instead of clojure.xml

user=> (clojure.data.xml/parse (slurp ( "file.xml")))
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by clojure.lang.InjectedInvoker/0x0000000800232040 (file:/Users/christian/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar) to method com.sun.xml.internal.stream.XMLInputFactoryImpl.createXMLStreamReader(.Reader)
WARNING: Please consider reporting this to the maintainers of clojure.lang.InjectedInvoker/0x0000000800232040
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Execution error (IllegalArgumentException) at clojure.data.xml/source-seq (xml.clj:337).
No matching method createXMLStreamReader found taking 1 args for class com.sun.xml.internal.stream.XMLInputFactoryImpl

same

yeah, this is more of a JDK issue. I remember this being discussed here like a month ago. Maybe it's archived in Clojurians Zulip?

Running the JVM with --illegal-access=deny will make the warning go away

Though not an optimal solution in my opinion

As of Clojure 1.10, turn off illegal access with --illegal-access=deny. The Java reflection system will then provide the necessary feedback to Clojure to detect that calling through the inaccessible class is not an option. Clojure will find the public invocation path instead and no warning will be issued. https://clojure.org/guides/faq

hmm, ok. thanks

No problem. Thanks for a good blog!

Thank you 🙂

what use-case do you have where deterministic classfiles is important?

Classfiles is a part of my container, and I would like my containers to be 100% reproducible, down to the sha256 of the container. A further use-case would be to put library classfiles in a separate layer, and this layer would only change when you change dependencies. The common case for changing only your own source code would likely lead to a tiny layer change at the top. This would reduce disk space usage.

I suppose clojure.lang.RT/id is one cause of the non-determinism. Via https://github.com/EwenG/badigeon/issues/17#issuecomment-559095104 Do you know of other causes? And do you think it is reasonable to expect deterministic classfiles?

Not necessarily across Clojure versions, but for the same Clojure version and for the same input.

More specifically my use-case is that I'm putting together use of EwenG/badigeon (Clojure compiler wrapper) and GoogleContainerTools/jib-core https://github.com/GoogleContainerTools/jib/tree/master/jib-core But so far I'm not able to reproduce a "complex" container due to the fact that classfiles are changing for the same input.

Here is my work so far...: https://github.com/ivarref/pikkpakk

Oh, that makes perfect sense then, thanks.