JDK-8255082 : HotSpot Style Guide should permit noexcept
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: other
  • Affected Version: 16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-10-21
  • Updated: 2025-07-03
  • Resolved: 2025-06-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.
JDK 26
26 b04Fixed
Related Reports
Blocks :  
JDK-8316930 - HotSpot should use noexcept instead of throw()
Relates :  
JDK-8305590 - Remove nothrow exception specifications from operator new
Description
The noexcept exception specification was introduced in C++11, and dynamic exception specifications (throw() and variants) were deprecated.  HotSpot code should be permitted to use noexcept (but not noexcept(false)), and should transition existing uses of throw() to noexcept.
Comments
Changeset: 96f71a9a Branch: master Author: Kim Barrett <kbarrett@openjdk.org> Date: 2025-06-20 19:48:41 +0000 URL: https://git.openjdk.org/jdk/commit/96f71a9a6bf7b52c50a1f52d4d401a48dc40480f
20-06-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25574 Date: 2025-06-02 05:28:17 +0000
02-06-2025
Issue for that typo: JDK-8325213
05-02-2024
Not a problem with noexcept after all. There was a makefile typo in the draft changes for JDK-8316930 (where the problem was encountered) that was preventing the intended "-std=" option from propagating to the adlc build, leading to the failures. Fixing that typo removes the problem, and all is well.
11-01-2024
https://github.com/TheShermanTanker/jdk/actions/runs/7070564987/job/19247370401, shows a problem in the adlc build. (I don't think we need to use noexcept in src/hotspot/share/adlc. If we want to, it may be possible that the adlc build needs a fix.) I can't see any relationship to clang 13.
11-01-2024
[~jwaters] According to the configure log for your failure, you are using Apple Clang 13.3. That doesn't correspond to any version of Xcode, according to https://gist.github.com/yamaya/2924292 I tried Xcode 14.3.1 (clang 14.0.3) (which is what Oracle is currently using for mainline), and it works fine. I then tried Xcode 13.2.1 (clang 13.0.0) (which I just happened to have available), and it also works fine. Your version is between those. It looks like either there was a breakage introduced and then fixed in the intervening versions, or there's something wrong with your configuration. Unfortunately, I don't have easy access to any of the intervening Xcode versions, to see if any of them are affected. Based on that, I'm inclined to not consider the problem you are seeing to be a blocker for working on this RFE.
15-12-2023
There is unfortunately no clang bug available as far as a thorough Google search can find, but see for example https://github.com/TheShermanTanker/jdk/actions/runs/7070564987/job/19247370401, where Apple Clang appears to explode when hitting a noexcept specifier on an operator new, while the old throw () syntax, for some reason, appears to work just fine
03-12-2023
[~jwaters] Can you provide more details about that? Is there a clang bug for the issue? Presumably it doesn't affect the old `throw()` syntax, else we'd already be having problems.
02-12-2023
Apple Clang appears to have an issue with parsing noexcept specifiers on operator new, which may pose an additional challenge to this Enhancement
02-12-2023
The style guide should list the places where noexcept affects semantics other than as related to just throwing. For example, `new` expressions behave differently depending on whether the invoked `operator new` is nothrow or not; see JDK-8305590.
29-09-2023
This becomes more important if we start using some parts of the Standard Library (esp. containers), as some operations have different behavior depending on whether relevant allocators, constructors, &etc are marked noexcept or not. We should only use noexcept in those places where it matters. Note that with at least some compilers, compiling with exceptions disabled does not imply everything is considered noexcept.
23-11-2022