JDK-8029953 : Backport ASM warning fixes to JDK 8
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 8u20
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-12-11
  • Updated: 2014-05-27
  • Resolved: 2014-03-20
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.
8u20 b09Fixed 9Fixed
There were some last minute ASM changes discovered in Java 8, that had to do with the ambiguity of interface methods, and that interface methods can be called by other opcodes than invoke interface. This was fixed by specifying an extra " is interface " parameter to method.visitMethodInsn in ASM and deprecating the old one.

Nashorn uses the old visitMethodInsn in a couple of places, and does not explicitly need to say that anything is an interface. We removed the use of the deprecated method in the JDK9 branch, basically by adding "false" or "true" arguments to this call where applicable, as we had a large number of compile time warnings.

(Thus, this has currently been resolved in JDK9 with JDK-8029031, but I think it makes sense to backport it to openJDK8).

I want to backport because it looks very unprofessional with a large number of deprecation warnings when building nashorn, and more importantly, because I've missed REAL warnings in the list of deprecation warnings. The fix would be very small and risk free and has been thoroughly tested in the 9 branch already. It is independent of everything else.

See http://cr.openjdk.java.net/~sundar/8029031/ for web rev that I want to backport.

It's not a showstopper, but it is completely risk free and doesn't break stuff. It also looks very unprofessional to keep it as it is

Release team: Rejected for 8 as it's not a showstopper. Deferring to 8u20

- Rationale for why it must be fixed It produces ~��20 warnings when compiling Nashorn. This looks unprofessional, but it can also take the focus from "real" warnings that may be introduced when building, which is something that happened when I did a bug fix yesterday. I didn't see the 21st warning among the 20 "deprecated" printouts. Leaving warnings in trains the developer to helplessness. - Risk Assessment Extremely low - This has already been tested thoroughly in our JDK9 branch, and we don't have any case where we do an exotic invoke interface, i.e. invoking an interface method with anything but the invoke interface byte code. - Level of testing coverage Testing covered by nashorn tests (1000+ tests) and nashorn test262 (11000+) tests. - Size of fix Very small. Basically adding true or false as the last parameter to ~��20 call sites to ASM visitMethodInsn. See web rev.