CDS fails on consecutive runs

[maxandersen]

in #2269 I noticed tests around CDS fails and I couldn't (initially) reproduce locally.

I've now found out that the generated .jsa and original jar keeps some state about the timestamp; thus even its the exact same jar/content the jdk will fail with:

[0.007s][warning][cds] /Users/max/.jbang/cache/jars/echo.java.a6296caf234b242c107e4962dc39e6f64f7a1a18de0a3d031292729ab56c40f6/echo.jar timestamp has changed.
Unable to use shared archive. The top archive failed to load: /Users/max/.jbang/cache/jars/echo.java.a6296caf234b242c107e4962dc39e6f64f7a1a18de0a3d031292729ab56c40f6/echo.jsa

I'm going to disable that specific test (CDSIT.java) for now in#2269 as not sure what the proper fix is and a jbang cache clear "fixes" it as long as you build/run with the same jdk - so its not fully broken - its our caching that doesn't "regenerates" the right jsa when needed.k

[quintesse]

Aha, so possibly we simply need to delete any .jsa files whenever we rebuild the jar, right?

[maxandersen]

Seems like a solution yes.