Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 369096 - [common types] StringIndexOutOfBoundsException if JvmDeclaredType has no package
Summary: [common types] StringIndexOutOfBoundsException if JvmDeclaredType has no package
Status: CLOSED INVALID
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.3.0   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: M5   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-19 10:23 EST by Moritz Eysholdt CLA
Modified: 2012-01-20 09:18 EST (History)
1 user (show)

See Also:
sven.efftinge: juno+

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 Moritz Eysholdt CLA 2012-01-19 10:23:10 EST 
calling JdtTypeProvider.findTypeByName with a URI such as java:/Objects/okInteger#okInteger causes 

java.lang.StringIndexOutOfBoundsException: String index out of range: -1
	at java.lang.String.substring(String.java:1937)
	at org.eclipse.xtext.common.types.access.impl.IndexedJvmTypeAccess.resolveJavaObject(IndexedJvmTypeAccess.java:98)
	at org.eclipse.xtext.common.types.access.impl.IndexedJvmTypeAccess.getIndexedJvmType(IndexedJvmTypeAccess.java:59)
	at org.eclipse.xtext.common.types.access.jdt.JdtTypeProvider.findTypeByName(JdtTypeProvider.java:85)
Comment 1 Moritz Eysholdt CLA 2012-01-20 05:17:05 EST 
The fix should be synchronous to org.eclipse.xtext.common.types.access.impl.AbstractClassMirror... however, AbstractClassMirror seems to assume that the JvmType is always in resource.getContents().get(0). This isn't true for JvmTypes created by a JvmModelInferrer. There, resource.getContents().get(0) is the "original" models and JvmTYpes are at resource.getContents().get(n) with n in [1..n]
Comment 2 Moritz Eysholdt CLA 2012-01-20 09:18:20 EST 
The latest code in the repository already has an explicit check for this exception. 
Furthermore, as it turn out, the original cause for this exception was bogus contents of the xtext index so that org.eclipse.xtext.common.types.access.impl.IndexedJvmTypeAccess.resolveJavaObject(JvmType, String) was called this the wrong JvmType.

I'm closing this one as invalid until other evidence shows up.