filemanager option handling and -Xlint:path

[Liam Miller-Cushon]

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> 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/971c76be/attachment-0001.html>