question about symlink handling

[Liam Miller-Cushon]

On Mon, Apr 3, 2017 at 5:54 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> 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
possible.


> 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: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170403/cb894b63/attachment.html>