JDK-8346689 : Consider reverting deprecation-for-removal of primitive wrapper class constructors
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P4
  • Status: New
  • Resolution: Unresolved
  • Submitted: 2024-12-19
  • Updated: 2025-06-27
Related Reports
Duplicate :  
JDK-8354335 - No longer deprecate wrapper class constructors for removal
Description
See Dan's writeup in https://mail.openjdk.org/pipermail/valhalla-spec-experts/2024-February/002443.html

>  when we did JEP 390 [1], we understood that there would continue to be class files in the wild calling 'new java/lang/Integer' and those class files would need to continue to work. The JEP refers to "Tooling to support execution of binaries that are unable to update their usages of wrapper class constructors" as future work. We envisioned some sort of bytecode rewriting capability to clean up these class files.
>
> Since then, we've updated our construction approach for value classes (see [2]), and it is no longer the case that 'new java/lang/Integer' in bytecode is incompatible with a value class Integer. Thus, we no longer need any special tooling—the stale binaries will just continue working!
>
> That said, these old classes will stop working if we ever go through with the threatened removal, as advertised by JEP 390. It probably makes sense to roll that back and just treat these constructors as normal @Deprecated APIs, with no specific plans for future removal.
Comments
Thanks, to be clear I was trying to raise the question of switching from `@Deprecated(forRemoval = true)` back to just `@Deprecated`, not removing the deprecation entirely. > I think the current vision is to drop `forRemoval` when value objects roll out, but it can happen earlier. Sounds good. I think this makes sense to do at some point if there are no longer plans to remove these APIs, I don't have input on the exact timing at this point.
19-12-2024
I think the current plan is to keep the deprecation of these constructors, as the legacy uses are almost always making use of the distinct identities of the wrapper objects. I think the current vision is to drop `forRemoval` when value objects roll out, but it can happen earlier.
19-12-2024