Community
Participate
Working Groups
I20080827-0935 - import org.eclipse.swt plug-in and the platform-specific fragment as binary projects - open org.eclipse.swt.graphics.Cursor - show Javadoc for constructor Cursor(Device, int) (either hover or show in Javadoc view) - click the link SWT.CURSOR_ARROW under "See Also:" - in JavaElementLinks#resolveType(IType, String), we call IType#resolveType(String) on the binary type 'Cursor' with argument "SWT" => should return {{"org.eclipse.swt", "SWT"}} but returns null Works fine with SWT from source. Also works fine in the JDK (e.g. java.lang.ThreadGroup.setMaxPriority(int) has a link to Thread#MIN_PRIORITY).
The unresolvable types are all *-imported. Adapting summary. The same problem occurs in I20080930-0921 when I open javax.annotation.Generated from jdk6 and try to resolve "Documented", "Retention", etc. which are imported with "import java.lang.annotation.*;".
IType.resolveType(...) doesn't consider the attached source. As a result, SWT is not found since it is not referenced in the .class file. To solve this, we will need to consider the attached source if any.
Lowering priority since this bug no longer blocks another one.
This also breaks e.g. the link to type "Target" in the Javadoc of the SafeVarargs annotation. This bug should not be P5, since it really is an issue for users.
Jay, please investigate.
The issue is the class Cursor is referring to SWT only through Javadoc and no code references to the same. This means the generated code doesn't have the corresponding import since we only use an on-demand import. Hence the type can't be resolved. Olivier, what can we do here?
Created attachment 197879 [details] Testcase A small test I used. Will use it later when we have a fix. The test will pass if we uncomment the method parameter.
(In reply to comment #6) > Olivier, what can we do here? If you're asking how to fix the bug, see comment 2: > IType.resolveType(...) doesn't consider the attached source. As a result, SWT > is not found since it is not referenced in the .class file. > > To solve this, we will need to consider the attached source if any. => The DOM AST contains the imports.
*** Bug 337563 has been marked as a duplicate of this bug. ***
*** Bug 434098 has been marked as a duplicate of this bug. ***
Created attachment 247085 [details] Patch under test
(In reply to Jayaprakash Arthanareeswaran from comment #11) > Created attachment 247085 [details] > Patch under test In hindsight, this is correct. This just searches all the types with the given name in the name lookup and returns the results and probably works because UI filters in the right ones. But IType#resolveType() should not be returning those that are irrelevant to this type.
This needs closer inspection. Moving to 4.6.
Example in JDK 8: Javadoc of java.lang.Comparable contains ... * specify a {@linkplain Comparator comparator}.<p> ... at the end of the second paragraph. This link doesn't work in the Javadoc view. There's an import java.util.*;, and Comparator is not referenced in code.
No progress yet and unlikely to get time during 4.6. Moving out.
Bulk move out of 4.8
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
