Merge jdk-17+35 #2
Merge tag jdk-17+35. All CRaC-specific tests pass, although there are only few of them.
The text was updated successfully, but these errors were encountered:
Reviewed-by: sviswanathan, jiefu
…th "RuntimeException: java.net.SocketException: Connection reset" Reviewed-by: xuelei, rhalade
…ed XML in <pre> tag Reviewed-by: hannesw
… on win-x64 Reviewed-by: herrick
…ght) failed: avoid overflow Reviewed-by: tschatzl, iwalulya
…nconsistent klass hierarchy Reviewed-by: kvn, roland, neliasso
…p is no longer needed Reviewed-by: roland, kvn
…ortedOperationExc for unsupported modes Reviewed-by: xuelei
…is retired Backport-of: 58e6e6d
…flags Reviewed-by: dholmes, mseledtsov
… VM flags Reviewed-by: dholmes, mseledtsov
… flags Reviewed-by: hseigel, mseledtsov
Reviewed-by: dholmes, mseledtsov
… VM flags Reviewed-by: hseigel, mseledtsov
…al VM flags Reviewed-by: dholmes, mseledtsov
…l VM flags Reviewed-by: sspitsyn
…M flags Reviewed-by: sspitsyn
…al VM flags Reviewed-by: sspitsyn
…iled with "SocketException: Cannot allocate memory" Reviewed-by: dfuchs, michaelm, chegar
Reviewed-by: naoto, lancea, iris
…n java stack' missing from stdout/stderr Reviewed-by: dcubed
8271413: ProblemList 2 locale tests on macOS-x64 Reviewed-by: naoto
…lags Reviewed-by: dholmes
…48912 Reviewed-by: dcubed
…a due to 8270326 Reviewed-by: dcubed
Reviewed-by: kvn, thartmann, chagedorn
…C promotion on Aug 5, 2021(B34) Reviewed-by: iris, mikael
Reviewed-by: ayang, pliden, tschatzl
…ent.java in JDK17 Reviewed-by: darcy
…n JDK17 Reviewed-by: darcy
… with ZGC Backport-of: a007cb1
To avoid this situation, create a new branch for your changes and reset the
Then proceed to create a new pull request with
@AntonKozlov This change now passes all automated pre-integration checks.
After integration, the commit message for the final commit will be:
At the time when this comment was updated there had been no new commits pushed to the
@AntonKozlov What's the preferred process on this kind of change? I'm new to managing merges of the JDK mainline into project specific repos so not yet clear on what level of review something like this would need.
As this is a merge of mainline (well, 17) I'm OK with giving this the +1 assuming that's the process we typically follow for this?
Do projects typically follow the releases or the mainline development? Still learning the norms here :)
I'm not sure also :) But I wanted to provide a heads up at least for the bump of the major version. Merges of minor versions probably are OK without review, if we'll do them often.
Yeah, I think this would be useful, a simple acknowledgment from other member(s).
We are free to choose something most suitable for us. I think having both makes sense: following mainline development for fast resolution of the problems with merges and a stable release for users to try. However, it is an additional burden in maintenance. Having 17, the merge of the early pre-18 state should be simple, the opposite looks harder. So for following 17 looks useful but simple enough. We can extend this any time we'd want, I think.
Seems like a reasonable starting point.
github repeatedly fails to load the "files" tab with a "This page is taking too long to load." so I'm unable to actually review the PR in the UI. Anyone know of a workaround for this? Otherwise, please consider this reviewed.
Funny enough, it's actually impossible to provide review (e.g. after checking out changes locally) without github attempt to show the diff.