The cache initialized can perform side-effectful Class/forNames

[vemv]

https://clojurians.slack.com/archives/C0617A8PQ/p1705167808132879

Although

cider-nrepl/src/cider/nrepl.clj

Lines 45 to 47 in c80f47c

	(Class/forName (str class-sym)
	false ;; Don't initialize this class, avoiding side-effects
	(.getContextClassLoader (Thread/currentThread)))

aims to avoid static initializers, perhaps there are similar calls nearby.

[vemv]

False alarm - the user's java code was based on final static fields, not static initializers.

We cannot work around those. It's a pretty extreme edge case and there's an easy refactoring path (static fields -> static initializers).

[hugoduncan]

Is there anything to be done to avoid someone in this situation going down the path of trying to debug what is going on?

[hugoduncan]

Unfortunately the call to orchard.info/info in warmup-orchard-caches! is initialising the java class.

info calls orchard.meta/resolve-var which calls ns-resolve.

[vemv]

Is there anything to be done to avoid someone in this situation going down the path of trying to debug what is going on?

Considering that as of today we offer support practically 7 days a week (my pleasure 🙂) I'm not immediately concerned by this meta-problem.

Perhaps we can add an integration test ensuring that no requires are performed, for the supported use cases:

• Vanilla clojure code
• Java classes with requires performed in the static class initializer

info calls orchard.meta/resolve-var which calls ns-resolve.

Good catch! I see, unfortunately the Java class/record type symbol clause is not the first one in the or: https://github.com/clojure-emacs/orchard/blob/951fdbe26cf5146ef070b905a99508e6ef9997e1/src/orchard/info.clj#L72-L81

However there's an easy fix - change info for info-java

[vemv]

https://github.com/clojure-emacs/cider/releases/tag/v1.13.0
https://github.com/clojure-emacs/cider-nrepl/blob/master/CHANGELOG.md#0450-2024-01-14