JDK-8143270 : Path options for langtools tools should not side-effect the filemanager
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Priority: P3
  • Status: New
  • Resolution: Unresolved
  • Submitted: 2015-11-18
  • Updated: 2020-01-14
Related Reports
Duplicate :  
JDK-8163588 - Confusing error while compiling via JSR199 API using the same file manager
Description
When using the Java Compiler API, the user can provide a file manager, and can specify path-related options when creating a task. Currently, such options will have a side effect on setting the locations in the underlying file manager. This is unexpected.

It would be better if any path-related options were only in effect for the duration of the compilation.

This Issue is filed for javac, but applies equally to other tools that provide an API, such as javadoc. It applies to a lesser extent to javah and javap, but although those tools are internally structured to use a file manager and use a tool/getTask architecture, that API is not currently public. If we fix javac, we should fix the other tools at the same time, or else file separate follow-up tasks.
Comments
There are two possible strategies for a solution, each with advantages and disadvantages. 1. Update the provided file manager for the duration of the task, and reset it on completion Advantage: the user's file manager is the one used for the compilation. (Not strictly true: it may have been wrapped by ClientCodeWrapper) Disadvantage: it mutates the file manager, meaning the file manager could not be used by concurrent compilations using different options (such as sjavac?) 2. Wrap the provided file manager, so that options only affect the wrapper, and not the underlying file manager. The wrapper would delegate to the underlying file manager for any values that are not set. Advantage: the underlying file manager is not modified during the compilation Disadvantage: the user's file manager is not the one used for the compilation. (But it may not have been anyway: it may have been wrapped by ClientCodeWrapper) Overall, #2 seems a better solution.
18-11-2015