JDK-8046202 : Make persistent code store more flexible
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-06-06
  • Updated: 2015-06-04
  • Resolved: 2014-09-19
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.
8u40 b08Fixed 9Fixed
Related Reports
Relates :  
Persistent code store introduced in JDK-8038638 is not very configurable. The following steps would allow Nashorn users/embedders to provide their own CodeStore implementation:

 - Use of ServiceLoader to get CodeStore implementation. 
 - Separate (non final) abstract base class/interface and default implementation.

Verfied 8u40 b22 with regtests

Added noreg-sqe label. New code is exercised by tests for JDK-8048079 and JDK-8039403.

Avatar does want this, as I've always maintained. I had been led to believe that any required security assessment was undertaken already -- if this is a blocking issue, it needs to be escalated.

We need to evaluate if this is still needed after Attila's work on JDK-8046921 which achieves much of the benefit of code persistence. If we still want to do this some kind of security assessment is necessary as this affects public classes (within internal nashorn packages). Optimistic code persistence was implemented in JDK-8043956.

Triaged: Avatar wants this for 8u40

We also need to separate optimistic code persistence. I am not sure if this is part of this CR, or it can be tracked separately