Fw: Patch for File Scanning

[Alan Bateman]

On 28/10/2011 00:21, Mike Skells wrote:
> Hi Alan,
> I that that the benefit in cpu would be more the store the file name 
> than the parent directory [I was just storing it because it was 
> available].
> I would be surprised if most implementations would not inspect the 
> name of the file in some way as there is not a lot that you could do 
> [open the file, print the full path and count the paths]
> and the cost just a String reference [the local file name] or an 
> offset in the current string. Not including the parent also avoids a 
> single path retaining the memory for a chain of parent paths
>
> Either way it is your call and I defer to your judgement :-)
Point taken but I'd prefer to separate any changes to representation 
into a separate project. In particular I think we should revisit the 
need for the array to each of the elements in the path. If you are okay 
with that then are you okay with the changes in the webrev? I'd like to 
get that push (with you listed as the contributor) and get it out of the 
way. Might also be useful to have it in for your discussions with 
Sherman as it sounds like he has a preference to spiting the jar work 
into small chunks.
>
> BTW I always found it strange that the file name could not be read as 
> a  string directly as opposed to Path.getFileName().toString()
>
Using Strings can be problematic because it causes the internal 
representation to be lost. It has been suggested that we add a 
getFileNameAsString or some such method where the String representation 
is needed. I think it needs more consideration.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111028/bec0c308/attachment.html