eclipse-jdt / eclipse-jdt/eclipse.jdt.core
Building OpenJDK: method not resolving by extended object type?
- Dominant language
- Java
- Stars
- 237
- Forks
- 195
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 49
Description
Trying to building JDK8u in ECJ (for speed).
Encountering an error in `openjdk\jaxws\src\share\jaxws_classes\com\sun\xml\internal\ws\server\DefaultResourceInjector.java`.
```
----------
1. ERROR in D:\ikvm\ext\openjdk\jaxws\src\share\jaxws_classes\com\sun\xml\internal\ws\server\DefaultResourceInjector.java (at line 44)
instance.getClass(),WebServiceContext.class,false).inject(instance,(WebServiceContext)context);
^^^^^^
The method inject(capture#1-of ? extends Object, WebServiceContext) in the type InjectionPlan is not applicable for the arguments (Object, WSWebServiceContext)
```
Casting the second argument to (WebServiceContext) does not resolve it. So, it's something with the first argument of type Object.
The code that is failing:
```
public final class DefaultResourceInjector extends ResourceInjector {
public void inject(@NotNull WSWebServiceContext context, @NotNull Object instance) {
InjectionPlan.buildInjectionPlan(
instance.getClass(),WebServiceContext.class,false).inject(instance,context);
}
}
```
The InjectionPlay.buildInjectionPlan method looks something like this:
```
public static
InjectionPlan buildInjectionPlan(Class clazz, Class resourceType, boolean isStatic) {
...
```
So, from what I see, it's trying to infer the type for T from the first parameter `clazz`. Which should then be returning an InjectionPlan, where T is typed to the passed Class. And that is passed as instance.getClass(), where instance is an Object.... so I really think Class should be Class. But ECJ is considering it an `capture#1-of ? extends Object`.
A workaround is to explicitly cast the resulting InjectionPlan to InjectionPlan before calling inject.
Attempted on ecj-4.35
Contributor guide
Research direction
Start with openjdk\jaxws\src\share\jaxws_classes\com\sun\xml\internal\ws\server\DefaultResourceInjector.java and the generic InjectionPlan.buildInjectionPlan signature shown in the report. Reproduce the error with ECJ 4.35, compare it with the explicit InjectionPlan cast workaround, and verify that the uncast call type-checks correctly when the issue is fixed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100