Community
Participate
Working Groups
When using the CharOperation#match method and isCaseSensitive the results are not always what you expect. If you pass the same string for both the pattern and the path and thouse identical strings contain one capital letter match will return FALSE when TRUE would be epxected. This is because in #match there is a bit of logic that says if isCaseSensitive is false then lowercase the character from the path but NOT the character from the pattern. This needs to be updated so that if isCaseSensitive is set to false then both characters are lower cased.
Created attachment 187210 [details] fix patch Needed fix.
Created attachment 187706 [details] unit tests
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This utility matching method doesn't correctly handle case insensitivity. As it is used when applying inclusion/exclusion filters to our project Include Path, it can cause us to index and process files not as intended. * Is there a work-around? If so, why do you believe the work-around is insufficient? No workaround. Exclusion patterns and file paths could fail the match test incorrectly, affecting search results and indexing operations. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? JUnit attached. * Give a brief technical overview. Who has reviewed this fix? Corrects the logic in the test so that case insensitivity actually does what it should. * What is the risk associated with this fix? Far-reaching, but low.
I'm fine with this fix, sounds better than it was. But ... I will remind you of all the nice ICU case checking methods that will automatically handle locale sensitive case differences for you (you know, like that lower/uppercase Turkish "i" problem :) Not sure if this is locale sensitive data (or, if already does call icu deep in the scanner code?) ... just reminding you. And, thanks for including a test case!
Released.
