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