InMemoryJavaFileManager has different behavior than standard java file manager.

[jasonnn]

The InMemoryJavaFileManager allows locations other than those specified in StandardLocation, whereas the standard manager will throw a null pointer exception if a non standard location is used.
Please look at a simple unit test i made which illustrates this

While it now seems kind of obvious to me that the "standard" manager would only support "standard" locations, it would be nice if compile-testing checked that it's backing file manager was actually able to create a FileObject for the specified location.

[gk5885]

Sadly, between javac and eclipse and whatever else, these tools just tend to be somewhat broken in their implementations. Given its contract, the JavaFileManager that comes with javac should have thrown an IllegalArgumentException. So, even if we wanted to mimic the locations supported by that implementation, throwing NullPointerException would just be reproducing their bug.

Out of curiosity, how did this even come up? Filer does the right thing with these locations, so I wouldn't have expected this to be an issue.

[jasonnn]

In my processor, the code which triggered the exception was:

 FileObject of = env.getFiler().createResource(NON_STANDARD_LOCATION, "", "test");

and here is the relevant stack trace...

java.lang.NullPointerException
at com.sun.tools.javac.file.JavacFileManager.getFileForOutput(JavacFileManager.java:785)
at com.sun.tools.javac.file.JavacFileManager.getFileForOutput(JavacFileManager.java:761)
at com.sun.tools.javac.processing.JavacFiler.createResource(JavacFiler.java:428)
...

It looks like javac's filer mostly just delegates to the file manager, so the issue still exists.