what makes you say that this is filewatcher related?

the stack trace suggested it

and it happened with shadow-cljs watch

are you on macos?

yes

GraalVM 21 working fine

macos uses the directory-watcher lib, otherwise the default built-in JVM thing is used

https://github.com/thheller/shadow-cljs/blob/8a93b43b43f4242b6f5f0406171155f575648860/src/main/shadow/util/FileWatcher.java#L32-L46

so I'd investigate that maybe?

I see: io.methvin.watchservice.MacOSXListeningWatchService;

yep, thats the one

ok, I'll look into it

I'm having the same issue

for me it's related to https://github.com/nextjournal/markdown/pull/24

@U5H74UNSF I'm going to take a look at this as part of nextjournal/beholder

@U0524T275 Ah that is a slightly different GraalVM 22 issue though - EDIT - it's related to the same removal of sun.misc.Unsafe

I wonder it the JVM built-in watcher works better for macOS these days? people used to complain that it was too slow. basically never checked this again since java8?

No idea

well interestingly with asdf I installed adoptjdk

and it works with 11 or 17

with the previous temurin it didn't work for any version for me

weirdly enough I can't reproduce this anymore with graalvm-jdk-22.0.1+8.1

I can reproduce with nextjournal.markdown though, not with nextjournal.beholder nor with shadow

no. normally #inst does not return a java.time.Instant? do you have data_readers.clj that overwrites the default?

this is a clean (I think) repo with only shadow

shadow.user=> (type #inst "2022-02-02")
java.util.Date

what do you get? npx shadow-cljs clj-repl?

same

https://github.com/handerpeder/shadow-cache-issue

"2.25.4"why is that no using the latest shadow-cljs? I don't really care investigating things that might be fixed?

shadow-cljs - watching build :app
[:app] Configuring build.
[:app] Compiling ...
[:app] Build completed. (119 files, 118 compiled, 0 warnings, 5.79s)

works fine for me?

do you maybe start via cider-jack-in or something along those line? injecting extra dependencies from the command line maybe?

oh sorry, I was looking back to when it was introduced, updated the repo

I ran npx shadow-cljs watch app and get warnings or so?

I'm seeing this

$  npx shadow-cljs release :app
shadow-cljs - config: /Users/peder/scratch/shadow-cache-issue/shadow-cljs.edn
shadow-cljs - updating dependencies
shadow-cljs - dependencies updated
[:app] Compiling ...
Failed writing cache for test: java.lang.Exception: Not supported: class java.time.Instant
[:app] Build completed. (45 files, 2 compiled, 0 warnings, 5.22s)

anything outside the repo that could be causing this?

we're seeing it in ci as well

ha, ok getting it for release as well. watch is fine. weird.

FWIW I would strongly caution against using custom reader literals in code

for existing types or in general?

but regardless, no sure what that might be. will look into it later. its not a critical error, just won't have cache for that file

we pull in stuff like this: https://github.com/henryw374/time-literals you recommend against that?

yes, 100%. I'd never consider using that.

I'd ask why, but I imagine you've explained your stance several times 😄

precisely due to issues such as this one. reader literals create objects that the compiler then has to deal with. in CLJ that has very much the same issues when it comes to AOT compilation.

I'm unsure how something turns from a Date to an Instant, so thats weird. especially given that release and watch use the same caching code, so why does watch not trigger it

yeah, I dunno. It happened somewhere between 2.25.3 and 2.25.4. not sure if there are more changes then the changelog lets on

well, you correctly identified the cause. it was that change, since that adds the form to the analyzer data. what I'm unsure is how it becomes a java.time.Instant when it should be a java.util.Date

what is even weirder is that I can't reproduce this in the shadow-cljs project directly

should be fixed in 2.28.9

thanks! did you figure out why it happened?

no, but the issue is more general than just #inst since it would basically happen for any literal. so removed that case entirely.