Bug 15677 - Exception calling sourceType.getFields on working copy of new class
Summary: Exception calling sourceType.getFields on working copy of new class
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P2 normal (vote)
Target Milestone: 2.0 M6   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 15349 15602 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-05-09 16:39 EDT by Tim Francis CLA
Modified: 2002-05-28 09:43 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Francis CLA 2002-05-09 16:39:53 EDT
This works correctly in M5 (0416), and fails in the 0502 & 0508 builds.

In most cases, our code (which is unchanged in this area) still works 
correctly.  However, there is one test case we have that is now throwing a 
JavaModelException.

I have tried, but been unable to reproduce this in a small testcase (although 
it reproducibly fails in the same place with this one testcase, so it does not 
look like a timing style bug)

The scenario is that we generate a class, and before it's commited, we add a 
field to the class.  As a side effect of that add, our code gets all fields 
defined on the class, and during that operation, we get an exception thrown 
that the class itself does not exist.

//////////////////////////////////////////////////////
Here's the bottom part of the callstack (this is from the 0502 build):

Thread [main] (Suspended)
	org.eclipse.jdt.internal.core.SourceType
(org.eclipse.jdt.internal.core.JavaElement).openHierarchy() line: 507
	org.eclipse.jdt.internal.core.SourceType
(org.eclipse.jdt.internal.core.JavaElement).getElementInfo() line: 288
	org.eclipse.jdt.internal.core.SourceType
(org.eclipse.jdt.internal.core.JavaElement).getChildren() line: 245
	org.eclipse.jdt.internal.core.SourceType
(org.eclipse.jdt.internal.core.JavaElement).getChildrenOfType(int) line: 254
	org.eclipse.jdt.internal.core.SourceType.getFields() line: 159
	com.ibm.etools.ejbdeploy.gen20.jdbc.FunctionSetHashField
	com.ibm.etools.java.codegen.JavaFieldGenerator).getNextSibling
(org.eclipse.jdt.core.IMember) line: 230
	com.ibm.etools.ejbdeploy.gen20.jdbc.FunctionSetHashField
(com.ibm.etools.java.codegen.JavaMemberGenerator).run() line: 298
	com.ibm.etools.ejbdeploy.gen20.jdbc.Entity20FunctionSetClass
(com.ibm.etools.codegen.BaseGenerator).runChildren() line: 250

//////////////////////////////////////////////////////
Here's the function that's actually throwing the exception (included in case 
line numbers have changed since 0502)

protected void openHierarchy() throws JavaModelException {
	if (this instanceof IOpenable) {
		((Openable) this).openWhenClosed(null);
	} else {
		Openable openableParent = (Openable)getOpenableParent();
		if (openableParent != null) {
			JavaElementInfo openableParentInfo = (JavaElementInfo) 
fgJavaModelManager.getInfo((IJavaElement) openableParent);
			if (openableParentInfo == null) {
				openableParent.openWhenClosed(null);
			} else {
/* line 507 */			throw newNotPresentException();
			}
		}
	}
}

//////////////////////////////////////////////////////
And here are the variables as they stand at line 507 above (ie, as the 
exception is about to be thrown)

this= org.eclipse.jdt.internal.core.SourceType  (id=372)
	fLEType= 7
	fName= "PhoneBeanFunctionSet"
	fOccurrenceCount= 1
	fParent= org.eclipse.jdt.internal.core.WorkingCopy  (id=328)
		bufferFactory= org.eclipse.jdt.internal.core.BufferManager  
(id=381)
		fLEType= 5
		fName= "PhoneBeanFunctionSet.java"
		fOccurrenceCount= 1
		fParent= org.eclipse.jdt.internal.core.PackageFragment  (id=385)
			fLEType= 4
		
	fName= "com.sun.cts.tests.ejb.ee.pm.ejbql.schema.websphere_deploy.DB2UDB
NT_V71_1"
			fOccurrenceCount= 1
			fParent= 
org.eclipse.jdt.internal.core.PackageFragmentRoot  (id=390)
				fLEType= 3
				fName= "ejbModule"
				fOccurrenceCount= 1
				fParent= 
org.eclipse.jdt.internal.core.JavaProject  (id=5188)
				fResource= 
org.eclipse.core.internal.resources.Folder  (id=5189)
		problemRequestor= null
		useCount= 1

openableParent= org.eclipse.jdt.internal.core.WorkingCopy  (id=328)
	bufferFactory= org.eclipse.jdt.internal.core.BufferManager  (id=381)
	fLEType= 5
	fName= "PhoneBeanFunctionSet.java"
	fOccurrenceCount= 1
	fParent= org.eclipse.jdt.internal.core.PackageFragment  (id=385)
		fLEType= 4
	
	fName= "com.sun.cts.tests.ejb.ee.pm.ejbql.schema.websphere_deploy.DB2UDB
NT_V71_1"
		fOccurrenceCount= 1
		fParent= org.eclipse.jdt.internal.core.PackageFragmentRoot  
(id=390)
			fLEType= 3
			fName= "ejbModule"
			fOccurrenceCount= 1
			fParent= org.eclipse.jdt.internal.core.JavaProject  
(id=5188)
			fResource= org.eclipse.core.internal.resources.Folder  
(id=5189)
	problemRequestor= null
	useCount= 1

openableParentInfo= org.eclipse.jdt.internal.core.WorkingCopyElementInfo  
(id=329)
	fChildren= org.eclipse.jdt.core.IJavaElement[1]  (id=378)
		[0]= org.eclipse.jdt.internal.core.PackageDeclaration  (id=5185)
			fLEType= 11
		
	fName= "com.sun.cts.tests.ejb.ee.pm.ejbql.schema.websphere_deploy.DB2UDB
NT_V71_1"
			fOccurrenceCount= 1
			fParent= org.eclipse.jdt.internal.core.WorkingCopy  
(id=328)
				bufferFactory= 
org.eclipse.jdt.internal.core.BufferManager  (id=381)
				fLEType= 5
				fName= "PhoneBeanFunctionSet.java"
				fOccurrenceCount= 1
				fParent= 
org.eclipse.jdt.internal.core.PackageFragment  (id=385)
				problemRequestor= null
				useCount= 1
	fIsStructureKnown= true
	fSourceLength= 82
	fTimestamp= 275
	problems= null
Comment 1 Jerome Lanneluc CLA 2002-05-13 13:00:54 EDT
As far as we can reproduce under debugger, the exception seems legite since the 
offending working copy only contains a package statement.

What is it supposed to contain at this stage ?
Comment 2 Tim Francis CLA 2002-05-13 15:43:00 EDT
The same code works for other classes that are generated, and for this class 
with previous versions of JDT.  I can't give you a definitive list of what 
should exist in the working set at that point in time without more research... 
but it should certainly include all the pre-reqs (the CU, the class, etc).

I'm quite willing to believe that the problem is upstream in the process, 
perhaps during the creation of the class, and the exception I'm seeing when 
calling getFields is not the root cause of the problem -- but something has 
changed in JDT, as the scenario used to work (and still does in most cases).
Comment 3 Jerome Lanneluc CLA 2002-05-13 17:37:17 EDT
It turned out that the problem was our. WorkingCopy.openBuffer() was loosing 
the new contents of the buffer because it was flushed from the buffer cache 
before the contents was set.

Fixed and released (and thanks a lot for your help Tim)
Comment 4 Jerome Lanneluc CLA 2002-05-14 06:02:45 EDT
*** Bug 15349 has been marked as a duplicate of this bug. ***
Comment 5 Philipe Mulet CLA 2002-05-28 09:43:50 EDT
*** Bug 15602 has been marked as a duplicate of this bug. ***