About FileSystem.getPathMatcher glob groups' whitespace

Alan Bateman Alan.Bateman at oracle.com
Wed Sep 19 05:46:27 PDT 2012


On 19/09/2012 13:02, 向雅 wrote:
> Hi Alan,
> Fine? I backed the topic:) seems long time pass
>
> Almost:) you maybe have some impression, this guy English bad or different:)
>
> before last message, after several tries, I got the fact: space accept
> as match element in glob pattern.
> Because the javadoc not clear it.
> And from my view, many other people in declaration style, will not
> notice this too.
> So I make advice: Ignore the whitespace, at least in tail extension part.
> Of cause, it's a option.
The specification is that, aside from the special characters, all 
characters match themselves. I guess we could make it very explicit that 
"all" includes spaces but I don't think it's strictly required. Note 
that there will be cases where you may want to match on file names that 
contain spaces, the spaces might be in the file extension (I don't think 
we want to prohibit that).

>
> More, current the PathMatcher only provided by FileSystem,
> Advice, add some SPI mekenism for some customerized PathMatcher.
> Through there already have a FileSystemProvider, seems it's too weight
> for the simple matcher problem.
>
> Even, add a registerPathMatcher method to filesystem for custom pattern.
> Because the JDK class library relative steady, maybe the SPI or
> register method is a candidate.
>
> Thought?
Can you just use your own PathMatcher implementation? You are right that 
if you want the default provider to know about other pattern languages 
then it means creating your own FileSystemProvider. It's not clear that 
it's worth adding a special provider interfaces for this (not that it's 
a bad things, it's just that there are lots of things that people want 
to customize and we don't want lots of provider interfaces).

-Alan




More information about the nio-dev mailing list