Bug 78452 - Call Hierarchy throws StringIndexOutOfBoundsException when used on some static methods
Summary: Call Hierarchy throws StringIndexOutOfBoundsException when used on some stati...
Status: RESOLVED DUPLICATE of bug 73784
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.1 M4   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-11 17:40 EST by Jason M. Fox CLA
Modified: 2004-11-12 06:54 EST (History)
0 users

See Also:

Attachments
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 Jason M. Fox CLA 2004-11-11 17:40:19 EST 
I am using Eclipse 3.1M3 on a linux box running RedHat 9 with Java 1.5.

1. Start eclipse in a fresh workspace
2. Create a plug-in project with all the default options checked
3. Open the "plugin" java file
4. Right click on the public static getDefault() method and select "Open Call
Hierarchy"

At this point, an "Internal Error" appears in the Error Log.  If selected, this
error reveals a stack trace:

java.lang.StringIndexOutOfBoundsException: String index out of range: -1
	at java.lang.String.substring(String.java:1768)
	at
org.eclipse.jdt.internal.core.search.matching.PossibleMatch.getQualifiedName(PossibleMatch.java:109)
	at
org.eclipse.jdt.internal.core.search.matching.PossibleMatch.<init>(PossibleMatch.java:41)
	at
org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:924)
	at
org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94)
	at
org.eclipse.jdt.internal.core.search.SearchBasicEngine.findMatches(SearchBasicEngine.java:196)
	at
org.eclipse.jdt.internal.core.search.SearchBasicEngine.search(SearchBasicEngine.java:382)
	at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:512)
	at
org.eclipse.jdt.internal.corext.callhierarchy.CallerMethodWrapper.findChildren(CallerMethodWrapper.java:69)
	at
org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.performSearch(MethodWrapper.java:253)
	at
org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.doFindChildren(MethodWrapper.java:194)
	at
org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.getCalls(MethodWrapper.java:76)
	at
org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.getCalls(DeferredMethodWrapper.java:62)
	at
org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.fetchDeferredChildren(DeferredMethodWrapper.java:80)
	at
org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:168)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:66)


One additional interesting piece of information.  In the "Session Data" section
of the Event Details dialog, it reports the following information (note the
buildId is for eclipse 3.1M2 even though I upgraded to and am running eclipse
3.1M3):

eclipse.buildId=I200409240800
java.version=1.5.0
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US


However, in the "Help -> About Eclipse Platform" dialog the buildId is listed as
 the correct buildId for eclipse 3.1M3.

Version: 3.1.0
Build id: 200411050810
Comment 1 Jason M. Fox CLA 2004-11-11 17:50:14 EST 
Regarding the improper buildId issue:

I found the following config:
~/.eclipse/org.eclipse.platform_3.1.0/configuration/config.ini

And it contains an "osgi.sharedConfiguration.area" property that points to the
eclipse 3.1M2 configuration directory.

I don't know if there are any side effects of having this config.ini laying
around after upgrading eclipse versions.
Comment 2 Frederic Fusier CLA 2004-11-12 06:54:14 EST 

*** This bug has been marked as a duplicate of 73784 ***