Bug ID: JDK-6411073 JSR 199: questions not answered by the specification

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 6
6 b85Fixed

###@###.### writes:

I've tried to update [a product] to the current version of JSR 199 and
I need to update our JavaFileManagers to the new interface. I have the
following questions:
1) I've do not understand why the JavaFileManager.getFileForInput (...)
and getFileForOutput () take the URI as a relativeName. It is not very
common to use the non absolute URIs. Why the relativeName isn't simply
a String?
2) How the StandardJavaFileManager.getJavaFileObjectsFromFiles () and
the StandardJavaFileManager.getJavaFileObjectsFromStrings () should work
when the files/paths are not under the roots managed by the FileManager.
It is acceptable to throw an exception?
3) I've looked into the ClassReader and it seems that it uses only the
StandardLocation.CLASS_PATH. How the classes from
StandardLocation.PLATFORM_CLASS_PATH are completed? Should I add the
roots from StandardLocation.PLATFORM_CLASS_PATH also under the roots of
StandardLocation.CLASS_PATH?
4) JavaCompilerTool.getTask (...) takes a FileManager as an argument,
but this JavaFileManager requires a knowledge of
StandardJavaFileManager.StandardLocation class since ClassReader passes
a StandardLocation.CLASS_PATH to the implementation of the JavaFileManager.
Why the StandardLocations are not defined in the JavaFileManager?

EVALUATION We have modified the compiler to call list for PLATFORM_CLASS_PATH, CLASS_PATH, and SOURCE_PATH. This means that the filemanager doesn't have to specical case CLASS_PATH. This should make everything simpler.

03-05-2006

EVALUATION Re 1) the documentation will be updated to explain why URI is used to represent a relative URI. Re 2) it is not acceptable to throw an exception. The documentation will not be updated as this is a consequence of the current specification. Re 3) see StandardJavaFileManager.getEffectiveLocation. The compiler expects that CLASS_PATH will include the platform class path. Re 4) strictly speaking the compiler passes a Location with the name "CLASS_PATH" to the given file manager. The implementation of this location happens to be StandardLocation.CLASS_PATH. The documentation will be updated to clarify 3) and 4). The reason why these locations aren't defined in JavaFileManager is that this interface is supposed to be a bit more general so it can be used by other tools, for example, javadoc.

24-04-2006

EVALUATION These are good questions. The documentation should be updated.

10-04-2006

Relates :	JDK-6440528 - javac deposits package-info.class in bogus directory
Relates :	JDK-6429194 - javax.tools.StandardJavaFileManager.setLocation(CLASS_PATH) has no effect?
Relates :	JDK-6409829 - JSR 199: enforce the use of valid package and class names in get{Java,}FileFor{Input,Output}