Community
Participate
Working Groups
I am getting the CCE below. This appears to be caused because the TypeNameMatchRequestorWrapper that is created internally to handle as-you-type look up of matching class names in a TypeSelectionDialog2 created (again internally) by JavaUI.createTypeDialog(). The API allows you to pass in IJavaSearchScope and this is respected right down to the field of TypeNameMatchRequestorWrapper that stores it, but then in TypeNameMatchRequestorWrapper.createTypeFromPath() is forcibly cast to a JDT JavaSearchScope. java.lang.ClassCastException: org.eclipse.jst.jsf.common.ui.internal.dialogfield.JavaSearchScope at org.eclipse.jdt.internal.core.search.TypeNameMatchRequestorWrapper.createTypeFromPath(TypeNameMatchRequestorWrapper.java:126) at org.eclipse.jdt.internal.core.search.TypeNameMatchRequestorWrapper.acceptType(TypeNameMatchRequestorWrapper.java:78) at org.eclipse.jdt.internal.core.search.BasicSearchEngine$2.acceptIndexMatch(BasicSearchEngine.java:766) at org.eclipse.jdt.internal.core.search.matching.InternalSearchPattern.acceptMatch(InternalSearchPattern.java:51) at org.eclipse.jdt.internal.core.search.matching.InternalSearchPattern.findIndexMatches(InternalSearchPattern.java:89) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.findIndexMatches(MatchLocator.java:325) at org.eclipse.jdt.internal.core.search.PatternSearchJob.search(PatternSearchJob.java:114) at org.eclipse.jdt.internal.core.search.PatternSearchJob.execute(PatternSearchJob.java:64) at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:261) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllTypeNames(BasicSearchEngine.java:777) at org.eclipse.jdt.core.search.SearchEngine.searchAllTypeNames(SearchEngine.java:780) at org.eclipse.jdt.internal.ui.dialogs.TypeInfoViewer$SearchEngineJob.getSearchResult(TypeInfoViewer.java:669) at org.eclipse.jdt.internal.ui.dialogs.TypeInfoViewer$AbstractSearchJob.internalRun(TypeInfoViewer.java:571) at org.eclipse.jdt.internal.ui.dialogs.TypeInfoViewer$AbstractSearchJob.doRun(TypeInfoViewer.java:518) at org.eclipse.jdt.internal.ui.dialogs.TypeInfoViewer$AbstractJob.run(TypeInfoViewer.java:484) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
Created attachment 55325 [details] Possible patch for JDT/Core However, with this patch, I got NPE in following line: TypeInfoViewer$TypeInfoLabelProvider.getContainerName(TypeNameMatch) line: 385 as NoTypeNameMatch.getPackageFragmentRoot() return null... Martin, I think there's some necessary changes in JDT/UI to handle this specific additional TypeNameMatch. Note that in this patch, NoTypeNameMatch does not store the document path in which you can get the container name when there's no type => I can add it and modify the API to provide this piece of information on the match... What's your mind about this?
The result of the Java type dialog is a an IType, so we would need the code that can resolve the IType. Frederic, Any chance to also store the package fragment root in the NoTypesMatch?
This is a major problem for us. Can I get either a workaround or a target milestone for a fix (or both)? Thanks, Cameron
I'll do my best to put a fix in 3.3 M5... In fact we should have make JavaSearchScope API and not allow clients to implement IJavaSearchScope at the beginning. Would it be acceptable for you if we change the API to this? Then you could extend JavaSearchScope instead of reimplement your own version...
> In fact we should have make JavaSearchScope API and not allow clients to > implement IJavaSearchScope at the beginning. Would it be acceptable for you if > we change the API to this? Then you could extend JavaSearchScope instead of > reimplement your own version... I'm not sure how this would fix this in the near term, since I assume you will need to deprecate the interface over a number of releases to give everyone time to switch. It also seems like there is an underlying design problem here: why are framework consumers of IJavaSearchScope suddenly making concrete class assumptions about them? Especially since JDT itself has at least on other implementer of IJavaSearchScope (HierarchyScope). As a near term workaround, I suppose I could switch to sub-classing the internal JavaSearchScope class. I have cc'd Nitin on this bug because the JSP framework also implements this interface.
(In reply to comment #5) > I'm not sure how this would fix this in the near term, since I assume you will > need to deprecate the interface over a number of releases to give everyone time > to switch. It also seems like there is an underlying design problem here: why > are framework consumers of IJavaSearchScope suddenly making concrete class > assumptions about them? Especially since JDT itself has at least on other > implementer of IJavaSearchScope (HierarchyScope). > I agree there are design issues here... First when creating IJavaSearchScope interface, we never should let clients to implement it. Second, when I implemented fix for bug 148380, I never should use JavaSearchScope to find IType. But it was so the best and easiest way for us, that I missed the point that clients couldn't take benefit of it if they implemented their own IJavaSearchScope. That's why, I was just asking you to know if this switch - to correct initial solution - would be feasible... If so, then I would have asked other JDT clients on our development list if they could also accept it. This would have been the easiest solution for us. Note that, in parallel, I continue to investigate if there could be an other solution which would avoid to force all clients to switch to a non backward compatible solution! > As a near term workaround, I suppose I could switch to sub-classing the > internal JavaSearchScope class. > Yes, this workaround is in fact the switch I proposed. It's a so simple solution that I really want to know if all clients would agree to adopt it! > I have cc'd Nitin on this bug because the JSP framework also implements this > interface. >
> IJavaSearchScope. That's why, I was just asking you to know if this switch - > to correct initial solution - would be feasible... If so, then I would have This solution is feasible for us as long as we get a working a dialog box that shows the correct classes for our users. > other JDT clients on our development list if they could also accept it. This > would have been the easiest solution for us. Note that, in parallel, I What would be the timeline on making JavaSearchScope API? Can you commit to doing so before Europa API freeze? The crux of my problem is this: I have a broken user interface. The break is caused by CCE inside code that is arrived at "legally" through a published interface. I need to either: 1) get a fix for this that restores my UI to working order or 2) find an alternative implementation that allows users to select fully-qualified class names from a list of classes that implement or sub-class specific types. I'm fine with any route we can take to that solution as long as: 1) The solution has a feasible milestone for completion (ideally before 3.3 final). 2) The solution does not require me to put my code into a state where it is dependant on non-API code (i.e. the current JavaSearchScope) for a non-determinate amount of time.
Created attachment 57615 [details] New proposed patch I finally found a solution which does not imply any API change... So, this problem will be definitely addressed in 3.3 M5 and hopefully in next week integration build :-) I can send a JDT/Core plugin jar file with the fix if you want the fix asap, just let me know your e-mail address where to send it...
> I finally found a solution which does not imply any API change... So, this > problem will be definitely addressed in 3.3 M5 and hopefully in next week > integration build :-) That's great Frederic! We can wait for the 3.3M5 or the next I-build you can release it in, whichever comes first. I'll also try the patch locally. Thanks!
The patch seems to work! We will do further testing with a release version before resolving 167192, but it looks like we've got a solution. Thanks Frederic!
(In reply to comment #10) > The patch seems to work! We will do further testing with a release version > before resolving 167192, but it looks like we've got a solution. Thanks > Frederic! > You're welcome :-) Thanks for your feedback.
Created attachment 57649 [details] Complete proposed patch This patch is a little bit more better than previous one as it takes into account member types...
Released for 3.3 M5 in HEAD stream.
Verified for 3.3 M5 using build I20070205-1824.
