AW: [Patch] 6502392 Invalid relative names for Filer.createResource and Filer.getResource

[Emil Siemes]

Hi Jon,

true, the code actually does things which would belong into java.net.URI. Reason for this is that JSR269 requires compliance with path-rootless rule of RFC3986 whereas java.net.URI supports the older and obsolete RFC 2396. Basically I was afraid of relying on the old implementation but that can be changed of course.
Given the limitation of the actual URI implementation it might be tricky to achieve compliance with the JSR269 requirements without parsing URI.getPath(). Dot-segments are not allowed as relative path names in JSR269 but are fine for the URI class. The current implementation calls URI.normalize().getPath() which actually removes dot-segments and therefore doesn't throw an exception. 

Given your feedback I propose I rewrite my code in a way that it relies on java.net.URI and does a quick check on the path. May be I can compare URI.getPath() and URI.normalize().getPath() to find out if any dot-segments are part of the path. I'll check and let you know.

Thanks
   Emil


 




________________________________
Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Andreas Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Dienstag, den 6. Januar 2009, 02:11:22 Uhr
Betreff: Re: [Patch] 6502392 Invalid relative names for Filer.createResource and Filer.getResource

Emil,

Thank you for looking at this, and for your patch.

I do not understand why 6419701 is not public. I am trying to find out
why it is not.
The bug itself is about the use of URI.create, not about the use of
isRelativeURI.

I'm not sure that your patch is warranted (or arguably, the correct
fix).  Your patch certainly 
contains functionality that on the face of it would better belong in
java.net..URI and not 
JavacFileManager. 

The way I read the code in JavacFileManager, isRelativeURI is not
intended to be a full and 
complete implementation of checking whether a URI is path-rootless.
Instead, it is used in 
exactly 3 places, and always in conjunction with URI.create. 
JavacFileManager is assuming 
the full syntax checking is done by URI.create, and is just using a
simple impl of 
isRelativeURI to distinguish relative URIs from absolute URIs created
by URI.create.

6419701 is about removing the use of URI.create -- presumably because
it is mildly icky
to create the URI object just to check whether a path string is a valid
URI.  So it seems 
to me that there are two ways to take this issue:  
1) Rewrite isRelativeURI to take a String argument and thereby avoid
the use of URI.create
2) Wait for URI to have some better method for checking the validity of
a path without
actually constructing the URI object..

I guess that I dislike JavacFileManager having code for detailed
parsing of URIs, and so
I think the current impl is better, of using URI.create to check the
syntax of a URI, and
then apply a quick check as to whether it is absolute or relative is
better.

Or am I misreading the situation or perhaps missing some subtlety in
your proposed code?

-- Jon


Emil Andreas Siemes wrote: 
com.sun.tools.javac.file.JavacFileManager checks if a name
fulfills the requirements of relative names:

"A relative name is a
non-null, non-empty sequence of path segments separated by '/'; '.' and '..' are
invalid path segments. A valid relative name must match the
"path-rootless" rule of RFC 3986, section 3.3."

This is done via the isRelativeUri() method. Unfortunately this
method doesn't currently really check for path-rootless compliance. A
patch with an improved method is attached.
When java.net.Uri eventually supports RFC 3986 the need for
isRelativeUri() goes away. I would also like to propose to rename
isRelativeUri() to isRF3986PathRootless() which would more clearly
describe what the method does.

There is a comment in JavacFileManager in a couple of lines:
//FIX ME 6419701
but I don't find bug 6419701 in the bug database. Any thoughts?

Thanks
    Emil




 
________________________________


________________________________


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090106/22126b1d/attachment.html