jansi dll constantly extracted to temp

[VirtualTim]

The code here: https://github.com/fusesource/jansi/blob/00e15cb1fab9117790580a412f7d54f2c08d2f11/src/main/java/org/fusesource/jansi/internal/JansiLoader.java#L168-L169

Appends a randomUUID to the dll extracted from the jar.

This has two potential issues:

1. dll is extracted/deleted on every launch/exit.
2. If the application does not exit cleanly (ie: crash) the dll is not deleted.

The dll is already versioned, so my suggested change would be:

1. Remove the uuid
2. Add an arch identifier (ie: x86, aarch64, etc)
3. Don't delete on exit, and don't re-extract if the dll already exists.

This would improve startup/shutdown times, and stop cluttering temp when the application does not shutdown cleanly.

---

Obviously the is more a design choice than a bug, but I just thought I'd log an issue to see what people thought.

[sebthom]

I second this. alternatively a hashsum of the library instead of the random uuid could be appended to the file name.

[michael-o]

What about concurrency? How to solve this?

[mrsalt]

What is the concurrency need if the file isn't deleted?

[mrsalt]

I second this issue. I've been seeing IntelliJ hang recently, when I start a maven command. I attached a debugger to maven, and it's stuck here:

"main" #1 prio=5 os_prio=0 cpu=250.00ms elapsed=167.88s tid=0x0000023b2d9c8710 nid=0x3bc4 runnable  [0x000000505eafd000]
   java.lang.Thread.State: RUNNABLE
        at java.io.WinNTFileSystem.delete0(java.base@17.0.2/Native Method)
        at java.io.WinNTFileSystem.delete(java.base@17.0.2/WinNTFileSystem.java:580)
        at java.io.File.delete(java.base@17.0.2/File.java:1073)
        at org.fusesource.jansi.internal.JansiLoader.cleanup(JansiLoader.java:103)
        at org.fusesource.jansi.internal.JansiLoader.initialize(JansiLoader.java:59)
        - locked <0x0000000623416228> (a java.lang.Class for org.fusesource.jansi.internal.JansiLoader)
        at org.fusesource.jansi.internal.CLibrary.<clinit>(CLibrary.java:36)
        at org.fusesource.jansi.AnsiConsole.ansiStream(AnsiConsole.java:255)
        at org.fusesource.jansi.AnsiConsole.initStreams(AnsiConsole.java:559)
        - locked <0x0000000623be3f58> (a java.lang.Class for org.fusesource.jansi.AnsiConsole)
        at org.fusesource.jansi.AnsiConsole.systemInstall(AnsiConsole.java:513)
        - locked <0x0000000623be3f58> (a java.lang.Class for org.fusesource.jansi.AnsiConsole)
        at org.apache.maven.shared.utils.logging.MessageUtils.systemInstall(MessageUtils.java:67)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@17.0.2/Native Method)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@17.0.2/NativeMethodAccessorImpl.java:77)
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@17.0.2/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(java.base@17.0.2/Method.java:568)
...

So AnsiConsole.systemInstall wants to delete a file. Not what I would have expected. I checked and "System" has the file open. Even after closing all applications, the file is still locked, and I cannot delete it.

[gnodet]

@VirtualTim I won't get back to using a single file, this has cause many problems in the past (concurrent access, file permissions, etc...). Also, the files are now deleted, so you should not have tons of different files if you use a recent jansi version. I've raised another issue to improve the deletion process.

[gnodet]

Also note that jansi provides a way to use a pre-extracted library path by using library.jansi.path system property.