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

Bug 209252

Summary:	[DOM] Recovered type bindings have inconsistent package and qualified name
Product:	[Eclipse Project] JDT	Reporter:	Markus Keller <markus.kell.r>
Component:	Core	Assignee:	JDT-Core-Inbox <jdt-core-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	frederic_fusier
Version:	3.4
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Markus Keller

2007-11-08 15:01:33 EST

HEAD, follow-up to bug 186410 and bug 209150.

Recovered type bindings have inconsistent package and qualified name.

Test case:

package p;
public class Try {
	Type t;
	not.existent.Type t2;
	Object o;
	other.Object o2;
	java.lang.Unknown u;
	Serializable s;
	java.io.Serializable s2;
}

Expected:
1.) ITypeBinding#getQualifiedName() is always getPackage().getName() + '.' + ITypeBinding#getName() (with special case for default package, of course)

2.) for qualified references where the package binding could be resolved, the recovered type binding of the type reference should return the resolved package on getPackage()

3.) Javadoc of ITypeBinding#getPackage() need to be adjusted, since only java.lang.Object got special treatment, but not other well-known types.

Nice to have (with and without rt.jar on build path):
4.) well-known types (qualified, maybe also unqualified) could always get a package binding that corresponds to the well-known type's package

Comment 1 Olivier Thomann

2008-07-14 11:42:45 EDT

(In reply to comment #0)
> Expected:
> 2.) for qualified references where the package binding could be resolved, the
> recovered type binding of the type reference should return the resolved package
> on getPackage()
How do you know what is the package portion of the fully qualified name ?
 
> 3.) Javadoc of ITypeBinding#getPackage() need to be adjusted, since only
> java.lang.Object got special treatment, but not other well-known types.
Will look at it.
 
> Nice to have (with and without rt.jar on build path):
> 4.) well-known types (qualified, maybe also unqualified) could always get a
> package binding that corresponds to the well-known type's package
Will see if this is feasible.

Comment 2 Markus Keller

2008-07-31 11:08:30 EDT

> How do you know what is the package portion of the fully qualified name ?

Just try to resolve the package from the left. E.g. for java.lang.Unknown, java.lang can be resolved to a package, but Unknown is not resolvable (so we assume it's a type). This already looks fine in I20080730-1200, so I guess it has already been improved since I filed the bug.

For not.existent.Type, no package is resolvable, so we have to guess. But the guess should be consistent, and the last segment should always be considered as a type (because not.existent.Type cannot mean a package at the spot it shows up in the AST). The deluxe guess would look at the capitalization and consider the first segment starting with an uppercase letter as a type.

The binding for not.existent.Type looks OK (class binding, with getPackage() returning a package binding for not.existent). 

But the binding for not.existent should then be a package binding. Currently, it's a type binding for a type 'not' in package 'p'. This makes little sense. And the SimpleName 'existent' even says it's a type binding with name "not" ;-)

Comment 3 Eclipse Genie

2019-08-13 14:15:38 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.