You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EXPECTED:
This method works for any Location object.
ACTUAL:
This breaks when using modules.
When the JavacTask runs validate() on the arguments in JavacTaskImpl.prepareCompiler(), if a module has been found, the CLASS_OUTPUT location will be determined by asking the JavaFileManager for the location for that module
This will lead to Locations.OutputLocationHandler.getLocationForModule(moduleName) being called, which returns a Location of type Locations.ModuleLocationHandler with the name set to location.getName() + "[" + name + "]" eg. "CLASS_OUTPUT[foo]" if the module name is "foo".
@Override
Location getLocationForModule(String name) {
if (moduleTable == null) {
moduleTable = new ModuleTable();
}
ModuleLocationHandler l = moduleTable.get(name);
if (l == null) {
Path out = outputDir.resolve(name);
l = new ModuleLocationHandler(this, location.getName() + "[" + name + "]",
name, Collections.singletonList(out), true);
moduleTable.add(l);
}
return l;
}
The validate() method will then call getJavaFileForInput() using this location, which calls the InMemoryJavaFileManager.uriForJavaFileObject() method.
Due to location.getName returning "CLASS_OUTPUT[foo]", URL.create will throw the following exception:
java.lang.IllegalArgumentException: Illegal character in path
It gives index 19, which is the square opening bracket [ in mem:///CLASS_OUTPUT[test]/....
This makes it not possible to directly use location.getName() in the uriForJavaFileObject() method for any given Location object, without encoding this name in some form, before passing it along to URL.create()
SOLUTION:
Encode the location name in some way, so that illegal URI characters won't be passed along to the URL.create() method.
VERSIONS USED:
compile-testing: 0.19
JDK: AZUL-17 version 17.0.4.1
The text was updated successfully, but these errors were encountered:
I also had a hard time configuring the modules directly through methods, so I supplied them as javac execution options. These options seem to work if used on the command line with javac directly (though it throws an exception during execution of the annotation processor, as it isn't fully implemented yet).
So expected behavior in that test: throws java.lang.IndexOutOfBoundsException: Index: 0, Size: 0,
Actual behavior: throws java.lang.RuntimeException: java.lang.IllegalArgumentException: Illegal character in path at index 19: mem:///CLASS_OUTPUT[test]/module-info.class
It seems modules support in compile-testing is just completely non-existent at the moment. I don't think it makes sense to fix this particular issue until we decide to add support for compiling modules.
In
InMemoryJavaFileManager
the methoduriForJavaFileObject()
is defined as such:EXPECTED:
This method works for any
Location
object.ACTUAL:
This breaks when using modules.
When the
JavacTask
runsvalidate()
on the arguments inJavacTaskImpl.prepareCompiler()
, if a module has been found, the CLASS_OUTPUT location will be determined by asking theJavaFileManager
for the location for that moduleThis will lead to
Locations.OutputLocationHandler.getLocationForModule(moduleName)
being called, which returns aLocation
of typeLocations.ModuleLocationHandler
with the name set tolocation.getName() + "[" + name + "]"
eg."CLASS_OUTPUT[foo]"
if the module name is "foo".The
validate()
method will then callgetJavaFileForInput()
using this location, which calls theInMemoryJavaFileManager.uriForJavaFileObject()
method.Due to location.getName returning
"CLASS_OUTPUT[foo]"
, URL.create will throw the following exception:It gives index 19, which is the square opening bracket
[
inmem:///CLASS_OUTPUT[test]/...
.This makes it not possible to directly use
location.getName()
in theuriForJavaFileObject()
method for any givenLocation
object, without encoding this name in some form, before passing it along toURL.create()
SOLUTION:
Encode the location name in some way, so that illegal URI characters won't be passed along to the
URL.create()
method.VERSIONS USED:
compile-testing: 0.19
JDK: AZUL-17 version 17.0.4.1
The text was updated successfully, but these errors were encountered: