question about symlink handling

[Jonathan Gibbons]

On 4/3/17 6:41 PM, Liam Miller-Cushon wrote:
> On Mon, Apr 3, 2017 at 5:54 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto: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.

Maybe you're right that we can't do too much with getKind. I'll take 
another look at the code tomorrow. Mostly, I was wanting to come up with 
a definition that was "the best of both worlds" -- user path, and 
canonical path, supporting those folk on Windows who may be used to 
case-equivalence for user paths, and those folk who apparently use 
unadorned cryptographic hashes for their canonical file names!

-- Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170403/165b601a/attachment.html>