filemanager option handling and -Xlint:path

[Jonathan Gibbons]

Yes, the disparity is annoying when the API is used to just build a 
different front end to javac, as compared to a deeply embedded component.

There are two (general) problems here.

1. Options that are (or may be) accepted by both javac and a file 
manager, which may or may not be JavacFileManager, or a wrapper around 
it. Having an API method on StandardJavaFileManager to enable warnings 
would be a good way to fix this. (And yes, that comes with some amount 
of compatibility design issues.)  One aspect of this problem is the 
backdoor path into the file manager via Context and Options. Generally, 
I've been trying to reduce the amount of info past this way. 
-Xlint:paths is the remaining most annoying use, but there are some 
hidden backdoor options which are also passed in this way.  Ideally, 
JavacFileManager should be a standalone component, and not use 
Context/Options at all.

2. Order of options.  Historically, command line javac lazily evaluated 
search paths (even before OpenJDK, file managers, JSR 199, etc), which 
meant that -Xlint:path could appear after a search path on the command 
line and still have an effect. You can see (or have seen) the code in 
command-line javac to retain that behavior. That is harder to do in the 
context of the (Standard)JavaFileManager API, where you want to throw 
IllegalArgumentException for really bad arguments, but maybe lazily give 
warnings for missing paths in the cases where -Xlint:path might 
eventually be specified.  Here, the complication is that the file 
manager might not be JavacFileManager, and we mustn't presume too much 
behavior there.  There are already too many "instanceof 
JavacFilemanager" in the code ;-)

-- Jon


On 10/24/16 11:00 AM, Liam Miller-Cushon wrote:
> Thanks for confirming. P4 sounds about right to me, and we're 
> generally using the API methods over handleOption.
>
> The only reason I asked is that the difference in behaviour between 
> build systems depending on whether they use the CLI or JSR 199 was 
> surprising: 
> https://github.com/google/error-prone/issues/466#issuecomment-255791591
>
> On Mon, Oct 24, 2016 at 10:15 AM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     I consider this a minor P4-level bug.  We're (still) teasing apart
>     the use of the JavacFileManager as a standalone file manager from
>     the mainline javac option decoding.   I'm (slightly) surprised at
>     your example: I was expecting an example in which -Xlint:path
>     comes *after* the -classpath option, for which there is definitely
>     no attempt to handle it.
>
>     In general, I think API clients should be using API methods in
>     preference to handleOption, and I think API clients have greater
>     opportunity to check paths for validity before using setLocation.
>     If anything, I'd prefer to either add API to enable warnings, or
>     at least ensure that fm.handleOption("-Xlint:path") works on paths
>     set via setLocation.
>
>     As for user file managers, it is currently up to them what options
>     they support.  We have work in progress to at least define what
>     options the file manager are provided by the default JDK
>     ToolProvider's getSystemJavaCompiler.getStandardFileManager. The
>     main problem is what package/class to define this on. One likely
>     possibility coming up is the javadoc on the jdk.compiler module
>     itself.
>
>     -- Jon
>
>
>
>     On 10/24/16 9:12 AM, Liam Miller-Cushon wrote:
>
>         -Xlint:path doesn't work when javac is invoked using JSR 199.
>
>         The CLI breaks a circular dependency between option handling
>         and filemanager initialization, but JSR 199 eagerly
>         initializes the filemanager before xlint options have been
>         processed.
>
>         Do you consider this to be a bug? I'm not sure what should
>         happen for user-supplied filemanagers, but the example below
>         seems fixable:
>
>         === JavacToolDemo.java ===
>         import javax.tools.JavaCompiler;
>         import javax.tools.StandardJavaFileManager;
>         import javax.tools.ToolProvider;
>         import java.util.Arrays;
>
>         public class JavacToolDemo {
>           public static void main(String[] args) {
>             JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
>             StandardJavaFileManager fileManager =
>         compiler.getStandardFileManager(null, null, null);
>             JavaCompiler.CompilationTask task =
>               compiler.getTask(
>                   null,
>                   null,
>                   null,
>                   Arrays.asList("-verbose", "-Xlint:path,unchecked",
>         "-cp", "lib.jar"),
>                   null,
>                   fileManager.getJavaFileObjects("Hello.java"));
>             System.exit(task.call() ? 0 : 1);
>           }
>         }
>         ===
>
>         The javac CLI handles -Xlint correctly:
>
>         $ echo "class Hello { java.util.List xs; }" > Hello.java
>         $ echo "Class-Path: NoSuch.jar" > Manifest.txt
>         $ jar cfm lib.jar Manifest.txt
>         $ javac -verbose -Xlint:all -cp lib.jar Hello.java
>         ...
>         [search path for class files: ... NoSuch.jar]
>         ...
>         warning: [path] bad path element "NoSuch.jar": no such file or
>         directory
>         Hello.java:1: warning: [rawtypes] found raw type: List
>
>         The API does not:
>
>         $ javac JavacToolDemo.java
>         $ java JavacToolDemo
>         ...
>         [search path for class files: ... NoSuch.jar]
>         ...
>         Hello.java:1: warning: [rawtypes] found raw type: List
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161024/d052d8c0/attachment.html>