JDK-7017414 : before the move of JSR 292 to package java.lang.invoke, javac must recognize the new package
- Type: Bug
- Component: tools
- Sub-Component: javac
- Affected Version: 7
- Priority: P2
- Status: Closed
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2011-02-04
- Updated: 2011-03-08
- Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 7 |
|---|
7 b130Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
The processing of invokeExact and invokeGeneric methods in MethodHandle is special-cased by javac, because these are signature polymorphic methods. The specification for this relies (currently) on the private @PolymorphicSignature annotation. This state of affairs will be disturbed when we move the 292 API from java.dyn to java.lang.invoke. (The move is bug 7012648.) In particular, the name of the marker annotation will change from this: java.dyn.MethodHandle$PolymorphicSignature to this: java.lang.invoke.MethodHandle$PolymorphicSignature In order to build the JDK with the API in the new package, the javac compiler will have to recognize the new name. For compatibility during a transitional period, it will have to recognize *both* names. This bug is urgent because we cannot check new JDK code into the repositories until an upgraded javac has gone all the way through release engineering and been propagated to the tool set used by JPRT (and customers, etc.). We will need a separate cleanup bug to remove the transitional support for "java.dyn".
Comments
|