Error-prone: InvalidPathException on Windows

Created on 15 Jul 2016 · 6Comments · Source: google/error-prone

I get an exception when compiling my project with error prone 2.0.10. I do not get this exception with 2.0.9.

I'm guessing this issue is Windows-specific. It looks like it's trying to make a java.nio.file.Path starting with /C:/ and blowing up because of the : character.

Here's the error and stack trace I see when running mvn clean package (which fails because of this error):

C:\Development\projectname\projectname-util\src\main\java\com\companyname\projectname\util\math\package-info.java:8: error: An unhandled exception was thrown by the Error Prone static analysis plugin.
@CheckReturnValue
^
     Please report this at https://github.com/google/error-prone/issues/new and include the following:

     error-prone version: 2.0.10
     Stack Trace:
     java.nio.file.InvalidPathException: Illegal char <:> at index 2: /C:/Development/projectname/projectname-util/src/main/java/com/companyname/projectname/util/math/package-info.java
        at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
        at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
        at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
        at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
        at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
        at java.nio.file.Paths.get(Paths.java:84)
        at com.google.errorprone.bugpatterns.PackageLocation.getFilePath(PackageLocation.java:88)
        at com.google.errorprone.bugpatterns.PackageLocation.matchCompilationUnit(PackageLocation.java:69)
        at com.google.errorprone.scanner.ErrorProneScanner.visitCompilationUnit(ErrorProneScanner.java:646)
        at com.google.errorprone.scanner.ErrorProneScanner.visitCompilationUnit(ErrorProneScanner.java:146)
        at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:561)
        at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:53)
        at com.google.errorprone.scanner.Scanner.scan(Scanner.java:70)
        at com.google.errorprone.scanner.ErrorProneScannerTransformer.apply(ErrorProneScannerTransformer.java:45)
        at com.google.errorprone.ErrorProneAnalyzer.finished(ErrorProneAnalyzer.java:121)
        at com.sun.tools.javac.api.MultiTaskListener.finished(MultiTaskListener.java:113)
        at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1303)
        at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1247)
        at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:858)
        at com.sun.tools.javac.main.Main.compile(Main.java:253)
        at com.google.errorprone.BaseErrorProneCompiler.run(BaseErrorProneCompiler.java:190)
        at com.google.errorprone.BaseErrorProneCompiler.run(BaseErrorProneCompiler.java:101)
        at com.google.errorprone.ErrorProneCompiler.run(ErrorProneCompiler.java:131)
        at com.google.errorprone.ErrorProneCompiler.compile(ErrorProneCompiler.java:73)
        at org.codehaus.plexus.compiler.javac.errorprone.JavacCompilerWithErrorProne$CompilerInvoker.compile(JavacCompilerWithErrorProne.java:219)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.plexus.compiler.javac.errorprone.JavacCompilerWithErrorProne.performCompile(JavacCompilerWithErrorProne.java:91)
        at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:825)
        at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
        at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

Source

michaelhixson

Most helpful comment

I just pushed Error Prone 2.0.11 to Maven. It includes the fix for this bug.

eaftan on 18 Jul 2016

👍3

All 6 comments

I wonder if the fix is as simple as changing this line:

return Paths.get(uri.getPath());

to this:

return Paths.get(uri);

Making that change locally in the 2.0.11-SNAPSHOT code makes the error go away for me.

michaelhixson on 16 Jul 2016

@michaelhixson that's basically it, but if I do that I break our tests. We're using Path#endsWith, which returns false if the filesystem providers are different. If you construct the path directly from the uri, then they are different and the check breaks.

Can you try out the PR I just attached to this issue and see if it fixes your problem? It would also be helpful if you could confirm that the error message looks sane on Windows -- I tried to retain the platform specific line separator in the message.

eaftan on 16 Jul 2016

@eaftan Your revision fixes the problem for me.

I couldn't figure out how to trigger the package error message except by switching its severity from WARNING to ERROR, and when I did that I got it to print this:

[INFO] Compiling 14 source files to C:\Development\projectname\projectname-util\target\classes
C:\Development\projectname\projectname-util\src\main\java\com\companyname\projectname\util\math\package-info.java:10: error: [PackageLocation] Expected package com.companyname.projectname.util.ffff to be declared in a directory ending with com\companyname\projectname\util\ffff, instead found C:\Development\projectname\projectname-util\src\main\java\com\companyname\projectname\util\math
package com.companyname.projectname.util.ffff;
                                   ^
    (see http://errorprone.info/bugpattern/PackageLocation)
1 error

Looks good I think?

michaelhixson on 16 Jul 2016

It would be good to have a release with the bugfix for this issue soon. It makes error prone on windows unusable.