Bug 137087 - Open Type - missing matches when using mixed case pattern
Summary: Open Type - missing matches when using mixed case pattern
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.2 RC2   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 137244
  Show dependency tree
 
Reported: 2006-04-17 17:07 EDT by Andrey Loskutov CLA
Modified: 2006-04-28 14:31 EDT (History)
4 users (show)

See Also:

Attachments
Proposed patch (27.70 KB, patch)
2006-04-18 11:26 EDT, Frederic Fusier CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Loskutov CLA 2006-04-17 17:07:15 EDT 
See also bug 136313 comment 9

In RC1, Build id: I20060413-1718 I have no matches for "hashM" or "Hashm" (in
3.1 I've got in both cases at least HashMap), but I've got match for "hashm". I
think this is very confusing and "not compatible" with 3.1.
Comment 1 Dani Megert CLA 2006-04-18 03:57:09 EDT 
Note that 3.1 was completely case-insensitive for non-camle-case patterns.
Comment 2 Frederic Fusier CLA 2006-04-18 04:54:45 EDT 
We have a big problem here. Since CamelCase improvment (bug 130390), lowercase characters are accepted for patterns. That means that as soon as user put a uppercase in the string, then we assume that it's a camel case pattern.

So, given patterns "Hashm" and "hashM" currently fail because CamelCase is case sensitive. It succeeded with 3.1 (but also with 3.2 M6), because pattern validation said they were not CamelCase patterns and then search was done with prefix and case insensitive...

I'm currently trying to figure out how we can solve this problem. My first thoughts about this are:
1) Add a insensitive CamelCase (or make current one insensitive if we do not want to add new API method)
2) Make search to try to match pattern as prefix when camel case fails instead of returning false

Not sure that solution 1) is possible, I have to look at algorithm carefully to be able to answer this. Solution 2) is feasible but would make search slower than before...

Philippe, I think we need to address this issue for RC2...
Comment 3 Frederic Fusier CLA 2006-04-18 11:26:45 EDT 
Created attachment 38802 [details]
Proposed patch

This patch implements solution 2) as we definitely need to retrieve previous behavior (ie. 3.1 or 3.2 Mx) without changing API...

Performance impact should not be so big because given string considered as a prefix pattern makes the number of possible matches really tiny (and so additional calls to CharOperation.prefix(*) method...).
However, I'll try to have a more precise idea of this impact using performance tests to measure it..

Note also that even with this fix, we get incorrect behavior in Open type dialog. This is due to a similar problem in method matches(String) of org.eclipse.jdt.internal.corext.util.TypeInfoFilter.
I'll open a new bug for this against JDT-UI component...
Comment 4 Frederic Fusier CLA 2006-04-18 11:39:10 EDT 
Open bug 137244 for JDT/UI part of this problem...
Comment 5 Philipe Mulet CLA 2006-04-18 12:20:23 EDT 
+1 for 3.2RC2
Comment 6 Frederic Fusier CLA 2006-04-18 12:38:43 EDT 
Patch released in HEAD
Comment 7 Olivier Thomann CLA 2006-04-28 14:31:49 EDT 
Verified with I20060427-1600 for 3.2RC2