JDK-8235602 : Re-examine if a hidden class should trust final non static fields
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: repo-valhalla
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-12-09
  • Updated: 2020-04-21
  • Resolved: 2020-03-24
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.
Other
repo-valhallaFixed
Related Reports
Relates :  
JDK-8238358 - Implementation of JEP 371: Hidden Classes
Relates :  
JDK-8233873 - final field values should be trusted as constant
Description
In the current prototype, in ciField.cpp:
    static bool trust_final_non_static_fields(ciInstanceKlass* holder) {
       :
       // Trust VM hidden and unsafe anonymous classes. They are created via Lookup.defineClass or
      // the private API (jdk.internal.misc.Unsafe) and can't be serialized, so there is no hacking
      // of finals going on with them.
     if (holder->is_hidden() || holder->is_unsafe_anonymous())
        return true;
Comments
Review thread: https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-January/006727.html
24-03-2020
Also follow up Paul's comment [1]: "I thought the same trigger (package of the lookup class) for whether those compiler-based annotations were allowed was the same trigger for whether final fields were trusted. So I had some slight concern that replacements with the public methods in the JDK for code within j.l.lnvoke (bootstrap methods etc) might affect final field behavior." https://mail.openjdk.java.net/pipermail/valhalla-dev/2019-December/006642.html
09-12-2019