JDK-6981791 : remove experimental code for JSR 292
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs21,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-09-02
  • Updated: 2012-02-01
  • Resolved: 2011-04-25
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.
JDK 7 Other
7Fixed hs21Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
This is a tracking bug.  There may be code left from the EDR phase of JSR 292 which is no longer relevant to the final specification.  This code should be removed if no longer relevant, or relegated to some special experimental category.

Features to remove from langtools, hotspot, and jdk include:

- allowTransitionalJSR292 flag (various places)
- deprecated methods
- registerBootstrapMethod and related "Global BSM" functionality

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ed69575596ac

EVALUATION This is the cleanup for a complex 2-phase commit changing a package name from java.dyn to java.lang.invoke, in the JDK, JVM, and langtools. Here's the approximate timeline: b130: 7017414 in langtools: Release javac which supports both java.dyn and java.lang.invoke. b135: 6839872/7012648 in JVM: Release JVM which supports both java.dyn and java.lang.invoke. b136: 6839872/7012648 in JDK: Release JDK which uses only java.lang.invoke. b137 (or later): 6981791 (this bug) in JVM and 7028405 in langtools: Release cleaned-up JVM and javac, purging all java.dyn references. More explanation: We can't remove transitional code (for java.dyn) in the JVM until the meth-rename-7012648 change (java.lang.invoke) in the JDK works out (into b136 or b137). If we yank JVM support for java.dyn while the b135 JDK code is alive, we'll get lots more failures. This assumes that the bulk of testing (in various phases) is using the released build. If this is so, we can only cut support from the JVM and javac after the new JDK has released. And of course, we could not release the new JDK until the transitional JVM and javac were released (b135 and b130).