[BUG] java.nio.file.FileSystemNotFoundException: Provider "mem" not installed

[holly-cummins]

Describe the bug
If an extension processor calls toURI on a FileObject, a FileSystemNotFoundException is thrown.

To Reproduce

Code like the following, in an extension processor under test, will show the problem:

   final Filer filer = processingEnv.getFiler();
   final FileObject tempResource;
            tempResource = filer.createResource("some_location", Constants.EMPTY, "some.tmp");
   final URI uri = tempResource.toUri();

A java.nio.file.FileSystemNotFoundException: Provider "mem" not installed exception will be thrown.

I'm able to work around the problem by writing a custom file system, and a custom file system provider, and registering it with the service loader:

However, it's
(a) a lot of boilerplate just to write some annotation processor tests; it feels like the Elementary codebase would be a more logical place for this test infrastructure code.
(b) not actually connected to the in-memory files created by the Elementary Filer. So far, nothing broke because of that, but it would be better if the mem: scheme didn't have a split-brain.

[Pante]

Thanks for reporting this bug!

I tried replicating the issue, but it seems to be working fine on my machine (Java 17, Windows), https://github.com/Pante/elementary/blob/fix/issue/315/elementary/src/test/java/com/test/Issue315Test.java. I assume the code snippet you provided was part of an annotation processor under test using the JavacExtension.

Could you provide which Java version, Elementary version & OS you were using?

[Pante]

@holly-cummins bump!

[holly-cummins]

Thanks for the follow-up, @Pante.

I'm using Java 17, Elementary 2.0.1, and MacOS.

I've created a simple reproducer which shows the problem at https://github.com/holly-cummins/elementary-315-reproducer/commits/main/. The first commit reproduces the error. Checking it out and doing mvn clean install should give

[INFO] Results:
[INFO] 
[ERROR] Failures: 
[ERROR]   ExtensionAnnotationProcessorTest.shouldProcessClassWithBuildStepWithoutErrors:28->assertNoErrrors:32 Errors were: [error: Resource path URI is invalid: mem:///SOURCE_OUTPUT/ignore.tmp
  Root error is java.nio.file.FileSystemNotFoundException: Provider "mem" not installed] ==> expected: <0> but was: <1>
[INFO] 
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0

The second commit has a simple file provider to get the tests passing.

[Pante]

Thanks for taking the time & effort to provide a reproducer. I took a look it and it and I can replicate the issue across both my Windows and MacOS machines.

The problem now lies in how to fix it. I'm a little hesitant to continue down the in-memory file representation path as it seems like significant effort to get it working without subtle bugs, even libraries like https://github.com/google/jimfs and https://github.com/marschall/memoryfilesystem seem to contain a long list of caveats. I think this issue even existing is proof of that.

I've been thinking and perhaps it might make more sense to lean into temporary directories instead, maybe something similar to https://junit.org/junit5/docs/5.9.1/api/org.junit.jupiter.api/org/junit/jupiter/api/io/TempDir.html? It should be simpler to maintain and also has the upside of allowing people to debug the generated files.

[Pante]

@holly-cummins I've released Elementary 3 that generates files in temporary directories instead of in-memory. It should fix the split-brain and file system issues. Please do re-open this issue if the bug persists.

[holly-cummins]

Thanks @Pante, that's worked! I had to change my tests to read Results.generatedSources rather than Results.sources, but it's quite likely the test was doing it wrong and passing for the wrong reason when it was using Results.sources.

[Pante]

While moving Elementary away from in-memory files, I remember fixing an issue with Results.sources sometimes returning sources that it shouldn't have. It was an unintended side-effect of the in-memory representation. The changes you've observed is probably a result of that.