Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 354860

Summary:	Java compile errors with two libraries in different project/packages and the same name
Product:	z_Archived	Reporter:	Kathy Carroll <carrollk>
Component:	EDT	Assignee:	Matt Heitz <mheitz>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	jqian, mheitz
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Kathy Carroll

2011-08-16 12:56:10 EDT

EGL source in Project ONE:

package api.eglx_lang;
library EBoolean002 {}
	function runMethodOne()
		syslib.writeStdout("zebraone runMethodOne");
	end	
	function runMethodTwo()
		syslib.writeStdout("zebraone runMethodTwo");
	end	
end

EGL Source in Project TWO:

package eunit.gen;
import api.eglx_lang.EBoolean002;
library EBoolean002 {}
	function initializeLibTest() 
		testMethods String[] = ["runMethodOne", "runMethodTwo"];
		runTestMtds runTestMethod[];
		runTestMtds[1] = EBoolean002.runMethodOne;
		runTestMtds[2] = EBoolean002.runMethodTwo;
	end
end
delegate runTestMethod()	
end


Java compiler message:

The import api.eglx_lang.EBoolean002 conflicts with a type defined in the same file

Second project has first project in both the EGL and the Java Path

Comment 1 Matt Heitz

2011-08-17 09:26:59 EDT

I see two problems with eunit.gen.EBoolean002.

1. runTestMtds runTestMethod[]; should be runTestMtds runTestMethod[2];  Without the initial size, the array is null, so the next statement would fail.

2. The line runTestMtds[1] = EBoolean002.runMethodOne; (and the one after it) are invalid.  You're referring to the other EBoolean002 but the compiler won't look there for runMethodOne.  You need to use the fully-qualified name: api.eglx_lang.EBoolean002.runMethodOne

I don't know why you didn't get a validation error for #2.  I'm talking it over with Paul Harmon.

Comment 2 Matt Heitz

2011-08-17 09:34:46 EDT

Oh, and the import of api.eglx_lang.EBoolean002 isn't going to do anything.  When you don't use the fully-qualified name, we resolve the meaning of "EBoolean002" by matching the name of the part being defined, before looking at any imports.

Comment 3 Kathy Carroll

2011-08-17 10:37:58 EDT

Jing, could you make the necessary changes to the generated framework code?

Comment 4 Jing Qian

2011-08-17 11:30:14 EDT

I have made the changes to 
- remove the imports
- generate the fully qualified library name for the delegate functions

to avoid the naming conflicts

Comment 5 Jing Qian

2011-08-17 11:30:41 EDT

fixed

Comment 6 Matt Heitz

2011-08-17 12:02:44 EDT

Fixed the generator by changing CommonUtilities.processImport().  We'll always use the fully-qaulified name of a type when its unqualified name matches the
unqualified name of the type currently being generated.

Paul also changed Egl2MofExpression for this.

Comment 7 Kathy Carroll

2011-08-23 09:44:24 EDT

verified

Comment 8 Lisa Lasher

2011-10-11 16:24:19 EDT

Closing this defect.