JDK-8344261 : Obsolete the LockingMode flag and related code
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: In Progress
  • Resolution: Unresolved
  • Submitted: 2024-11-15
  • Updated: 2025-11-04
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
tbdUnresolved
Related Reports
Relates :  
Relates :  
Sub Tasks
JDK-8359437 :  
JDK-8364141 :  
JDK-8364406 :  
JDK-8364570 :  
JDK-8365146 :  
JDK-8365188 :  
JDK-8365189 :  
JDK-8365190 :  
JDK-8365191 :  
JDK-8367601 :  
JDK-8367982 :  
JDK-8370257 :  
Description
The LockingMode flag was deprecated in JDK 24 and marked for obsoletion in JDK 26.
Comments
[~cjplummer] I think this task is effectively complete as far as the LockingMode and any associated warnings is concerned. Those PL entries should now be able to be removed. I created a new sub-task for that: JDK-8370257
21-10-2025

There are a number of tests failing due the warning produced and are problem listed because of this flag. I seem to recall some discussion on whether or not the warning should instead be filtered by the tests so they don't need to be problem listed, and it was decided to wait for this fix instead. However, this fix is a long time in coming, and in the meantime the tests remain problem listed. BTW, I might be remembering this wrong. I also seem to recall that we were going to remove the LockingMode test task that was causing the warning to appear. Maybe that has already been done and these tests don't need to be problem listed anymore.
20-10-2025

The CSR states: > Deprecate LockingMode in JDK 24, make obsolete in 26 and remove in 27. I see no reason to revisit that decision
19-11-2024

Unless you can dig up the complete history of the decision we can't just change it. As I said my recollection is that the code was deliberately left in place in the next LTS.
19-11-2024

The wording in the CSR link is a probably intentionally vague. The deprecation process is that we deprecate in release n, obsolete in release n+x, and remove the option in n+x+1. I do sort of remember we decided for this it should be JDK 24, 26, 27 making the value of x=2. But the CSR comment doesn't actually say that. So I'm wondering if we can and should make the decision to obsolete the option (removing underlying code) in JDK 25.
19-11-2024

I was wondering why we decided this and whether it was a good decision. Maybe it would be better to remove the code in JDK 25.
18-11-2024

[~coleenp] IIRC the decision to obsolete in 26 was so that it would remain available in JDK 25 LTS. I don't recall where that decision was made/recorded, but there are numerous references to it e.g. https://bugs.openjdk.org/browse/JDK-8331076?focusedId=14694107&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14694107
18-11-2024

Did we decide to do this in JDK 26 and not JDK 25?
15-11-2024

Fix version 26 doesn't exist yet so marked tbd
15-11-2024