Re: Why doesn’t jdk.internal.loader.Loader implement AutoCloseable?

[Christian Stein]

On Sun, May 26, 2019 at 10:31 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 26/05/2019 06:45, Christian Stein wrote:
> > Hi,
> >
> > following the documentation of ModulLayer [1] to create a
> > temporary layer for testing, results in a FileSystemException
> > when trying to delete the modular jar file after tests are finished.
> Can you create a WeakReference to the module layer and do the cleanup
> when the reference is queued? When a module layer is GC'ed then you
> should find the JAR files containing modules will be closed and you can
> delete them. As this is testing then maybe the test finish can null out
> the reference to the module layer (and the class loaders if you have
> references to those), call System.gc, and wait for the weak reference to
> be cleaned.
>

Only tried to null out the loader, yet.

So I added the layer and the reference to a class loaded by
the layers' loader to the "to be nulled out ensemble" [1]:

  layer = null;
  loader = null;
  mainClass = null;

  System.gc();
  Thread.sleep(2000);

...et voilà, the jar file is unlocked a can be deleted.
Many thanks for the hint.


> That said, it might be time to change the Windows sharing mode that
> JarFile/ZipFile uses to open JAR files. I'll create an issue for that.
>

Sounds great! Still early enough for JDK 13? ;-)

[1]
https://github.com/sormuras/sormuras.github.io/blob/master/demo/test/jdk/JarLock.java#L69