question about symlink handling

Liam Miller-Cushon cushon at
Tue Apr 4 01:41:49 UTC 2017

On Mon, Apr 3, 2017 at 5:54 PM, Jonathan Gibbons <
jonathan.gibbons at> wrote:

> It seems a somewhat specialized use case to be storing source code in
> files with non-standard file names.  That's not to say you shouldn't but it
> seems like that is a different sort of "host system" than the one currently
> supported by javac. How easy would it be for you to provide and use a
> different file manager that has the semantics suitable for your environment?

Agreed, the environment where I noticed this is unusual, and if it wasn't
for the issue with the diagnostic I might not have reported it. I'll think
about whether there's a cleaner way to hide those details from javac. For
the most part it's a normal filesystem with a lot of symlinks, so it'd be
nice to continue to use as much of the JavacFileManager implementation as

> Given the existing "fault tolerant" code in PathFileObject.isNameCompatible,
> how practical would it be to override isNameCompatible in SimpleFileObject
> such that it first checks the userPath, and then rolls over to the default
> definition.   Ideally that first check should be as fault-tolerant as the
> existing checks, so there would be a small refactoring to be able to apply
> the same checks to both the userPath and the real path.

That sounds practical to me.

> And, similar treatment for getKind().

Changing the handling of kind in isNameCompatible is straightforward, but
making all uses of getKind() fault-tolerant seems harder. For example,
JavacTool uses getKind() to validate that the source file objects are
actually sources.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the compiler-dev mailing list