Bug 137710 - plugin dependency through overloaded method
Summary: plugin dependency through overloaded method
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: 3.3   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-20 09:24 EDT by Carsten Pfeiffer CLA
Modified: 2006-05-15 05:35 EDT (History)
0 users

See Also:

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 Carsten Pfeiffer CLA 2006-04-20 09:24:14 EDT 
I have a plugin that depends on org.eclipse.jdt.launching and calls the method
JavaRuntime.newArchiveRuntimeClasspathEntry(IPath)

I get a compilation error:

"The type org.eclipse.core.resources.IResource cannot be resolved. It is indirectly referenced from required .class files"

This is due to the overloaded method
JavaRuntime.newArchiveRuntimeClasspathEntry(IResource)

As my own plugins doesn't depend on core.resources at all, this dependency seems unwarranted to me.
Comment 1 Philipe Mulet CLA 2006-04-20 09:38:29 EDT 
Please provide a code sample showing how you perform the invocation.
Comment 2 Carsten Pfeiffer CLA 2006-04-20 10:13:03 EDT 
The following class is in the first plugin:

package foo;

import org.eclipse.core.resources.IResource;
import org.eclipse.core.runtime.IPath;

public class Foo {
	public static void doit(IResource resource)	{}
	public static void doit(IPath path) {}
}


And class Bar will be in the second plugin, depending on the first, but not on core.resources:

package bar

import org.eclipse.core.runtime.Path;

import foo.Foo;

public class Bar {
	public Bar() {
		Foo.doit(new Path("/"));
	}
}

The call to doit(IPath) will be flagged with an error.
Comment 3 Philipe Mulet CLA 2006-04-26 18:47:39 EDT 
When looking for an exact match, we could avoid resolving other methods potentially. This could improve performance, as compiler would be more lazy at loading new types.
Comment 4 Kent Johnson CLA 2006-05-10 13:27:30 EDT 
But we do not have an exact method parameter match in this case.

We must resolve both methods to find out which one is a better match.
Comment 5 Kent Johnson CLA 2006-05-10 13:51:10 EDT 
The only solution to this problem is to change the name of one of the methods, since they really shouldn't have the same name as IResource and IPath are not related.
Comment 6 Philipe Mulet CLA 2006-05-15 05:35:24 EDT 
Good point Kent. My exact match trick wouldn't work.