Description Nick Edgar 2001-10-10 22:35:18 EDT

There are currently 7 copies of StringMatcher in the environment.
It needs to be given a proper home, ideally in Core.
Should coordinate with JM after the release to do this.

NOTES:

Email trace:

NE says:
Actually, this is a bug after all.

match(...) should match the whole string.  If you want to do a substring search, use find(...), which can find any occurrence (and gives you its position).

For match(...), a pattern of "" should only match the empty string.
For example: new StringMatcher("ab", false, false).match("abz") is false,
so new StringMatcher("", false, false).match("z") should be false too, but it's currently true.

This is due to the segCount == 0 test, which should check whether there are actually wildcards before returning true.
The next two tests check for empty target and empty pattern, but they're not currently reached.

I also noticed another bug, where if ignoreWildcards is true, it doesn't check the length.
So new StringMatcher("a", false, true).match("ab") currently returns true, but it should return false.

The corrected lines are:
		if (fIgnoreWildCards)
			return (end - start == fLength) && fPattern.regionMatches(fIgnoreCase, 0, text, start, fLength);
		int segCount = fSegments.length;
		if (segCount == 0 && (fHasLeadingStar || fHasTrailingStar))  // pattern contains only '*'(s)
			return true;

I've filed 1GET09O: ITPUI:WIN2000 - Bugs in StringMatcher
but have not released the fix since we are frozen.

EG says:
As of the 118 we have 7 copies of the StringMatcher class in the system and
we would have to fix 7 classes, this is insane. We should rather make the class availble for general use and fix it once.

JW says:
This is the problem that we feared.  There is no API here, so we have N copies.  A bug is discovered late, and now everyone is scrambling.

The only possible home for this is core.  We should look at making this occur next time if we can't do anything about it now.  
(It is reasonable to believe that the implementation will want to improve over time - this is also a problem with 7 copies)

JM says:
I am happy to host a utils plugin (eg., org.eclipse.utils).  I do not want to be the one to integrate or test or fix unless it is code that I supplied.

I am willing to make this happen today.  Just let me know.

JW says:
We should do this.  Please get the correct implementation from NE.   Clients should then use your implementation 
once they can transition (or live temporarily with the incorrect one).

NE says:
Just to clarify here, that nobody is actually affected by this bug currently.  It's only when you create an empty pattern.  
James has a workaround for his situation.
None of the 7 copies are API.
So I think we should hold off, and do it after the release.

JW says:
I am glad to hold off if no change is necessary (to any of the StringMatcher implementations).  
If any change is necessary (or likely necessary), we should move now.
Given NE's comments, I assume no change is necessary given James' workaround.
(After 0.9, we should address this promptly)

JM says:
We have an adequate and safe workaround in our code and need no fix at this time.