Please review the application of the `@Serial` annotation
([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the
java.logging module to enable stricter compile-time checking of
serialization-related declarations. Only one class remains to be covered; all
other relevant fie
On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race wrote:
> The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after
> JEP 486 and JEP 491 integration
> removed use of AppContext from java/util/logging/LogManager.java.
> That was the only place in the JDK that used
> jdk.internal.ac
On Wed, 21 May 2025 00:59:34 GMT, Sergey Bylokhov wrote:
> Both fields were added by the
> [JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777):
> see
> https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8
> And the usage were deleted by the
Both fields were added by the
[JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777):
see
https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8
And the usage were deleted by the
[JDK-8341402](https://bugs.openjdk.org/browse/JDK-8341402):
see
https://github.com/openj
On Wed, 14 May 2025 17:34:45 GMT, Naoto Sato wrote:
>> For the l10n files, they are synced by the translation team and we don't
>> edit them. IMO, I think it's fine leaving those ones as is. Especially
>> because language rules can cause different spacing and punctuation
>> characters, so gene
On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY wrote:
>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Refactor container runtime version code
test/hotspo
On Tue, 13 May 2025 14:46:00 GMT, Ivan Bereziuk wrote:
> I wrote 2 comments. but cold not post them. They are in "pending" state. Not
> sure why. Should the comments be first reviewed by {Committers|Reviewers}?
please go to `Files changed` panel and press Review Changes -> Submit review
--
On Wed, 14 May 2025 06:32:30 GMT, Magnus Ihse Bursie wrote:
> That seems reasonable, yes. However, I'd like to keep this change to the
> absolute minimum. Feel free to open a separate issue for fixing this.
FIled: https://bugs.openjdk.org/browse/JDK-8356937
-
PR Review Comment: ht
On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote:
> A handful of html and xml files in the JDK source tree claims to have
> encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
>
> While perhaps technically correct, this is misleading, and goes contrary to
> the eff
On Tue, 29 Apr 2025 14:45:25 GMT, PAWAN CHAWDHARY wrote:
>> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails
>
> PAWAN CHAWDHARY has updated the pull request incrementally with one
> additional commit since the last revision:
>
> update reference of DockerVersion
test/hotspot/jtr
On Tue, 29 Apr 2025 07:11:30 GMT, Per Minborg wrote:
> In the end, this didn't make the bar in terms of cost/benefit. For example,
> backporting might be impacted.
The first LTS release to include this API will be 25, correct? It would be best
to clean this up in advance, as backporting to ver
On Wed, 19 Feb 2025 09:22:09 GMT, Per Minborg wrote:
> This PR proposes to make all imports consistent in the FFM API tests and
> benchmarks.
>
> This is a follow-up PR from https://github.com/openjdk/jdk/pull/22827
>
> Passes tier1-3
test/jdk/java/foreign/TestFunctionDescriptor.java line 38:
On Thu, 9 Jan 2025 11:47:15 GMT, Per Minborg wrote:
>> This PR proposes to clean up all the imports in the FFM lib (excluding
>> tests).
>>
>> Passes tier1-tier3
>
> Per Minborg has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes th
On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie wrote:
>> Most of the JDK code base has been transitioned to UTF-8, but not all. This
>> has recently become an acute problem, since our mixing of iso-8859-1 and
>> utf-8 in properties files confused the version of `sed` that is shipped with
On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie wrote:
> I have checked the entire code base for incorrect encodings, but luckily
> enough these were the only remaining problems I found.
>
> BOM (byte-order mark) is a method used for distinguishing big and little
> endian UTF-16 encoding
On Fri, 7 Mar 2025 04:34:24 GMT, David Holmes wrote:
>>> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as
>>> well.
>>
>> Thanks for your review @jerboaa ! I cheched the
>> test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master
>> branch.
>
> @se
On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev
wrote:
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
On Sun, 2 Mar 2025 19:07:32 GMT, Severin Gehwolf wrote:
> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as
> well.
Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp,
it's already updated to 2025 in the master branch.
-
PR Co
On Fri, 28 Feb 2025 17:08:19 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updated comment
>
> src/java.base/linux/classes/
On Fri, 28 Feb 2025 12:27:13 GMT, Matthias Baesken wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updated comment
>
> test/jdk/jdk/internal/platform/cgroup/CgroupV1Subsystem
On Fri, 28 Feb 2025 17:07:59 GMT, Severin Gehwolf wrote:
>> src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 2:
>>
>>> 1: /*
>>> 2: * Copyright (c) 2020, 2024, Red Hat Inc.
>>
>> Guess this must be 2025 now ? Same for other files ...
>
> yes indeed.
indeed, updated the copyright headers.
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
On Tue, 25 Feb 2025 17:11:30 GMT, Severin Gehwolf wrote:
>>> This needs to explain exactly what is happening when. The current comment
>>> isn't even remotely explaining in detail what it does. What does "...
>>> handles the case when a process is moved between cgroups" mean exactly?
>>
>> Eit
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
On Mon, 24 Feb 2025 23:33:01 GMT, Sergey Chernyshev
wrote:
>> `CgroupV1Controller::set_subsystem_path` needs high level comment update to
>> describe the logic happening.
>>
>> Testing:
>>>>And after the patch this would become this, right?
>>>>
On Tue, 25 Feb 2025 14:06:03 GMT, Severin Gehwolf wrote:
> This needs to explain exactly what is happening when. The current comment
> isn't even remotely explaining in detail what it does. What does "... handles
> the case when a process is moved between cgroups" mean exactly?
Either it shall
On Mon, 17 Feb 2025 14:04:03 GMT, Severin Gehwolf wrote:
> The above case, doesn't seem to be reflected by any gtest test case (or
> others), please add those.
The subgroup path reduction is covered by
`TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` (it wouldn't be possible in
gtests as i
On Fri, 21 Feb 2025 20:05:07 GMT, Sergey Chernyshev
wrote:
>> Good catch, but as long as cgp#nameCount may change in the loop, this exact
>> patch i cannot take.
>
> How about this?
>
> int currentNameCount = cgp.getNameCount();
> cgp = (currentNameCount > 1) ? c
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
On Mon, 17 Feb 2025 14:04:03 GMT, Severin Gehwolf wrote:
> `CgroupV1Controller::set_subsystem_path` needs high level comment update to
> describe the logic happening.
>
Done, added
-
PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2679664923
On Mon, 24 Feb 2025 08:44:00 GMT, Tagir F. Valeev wrote:
> It appears that the benchmark was erroneous. The combination of "tailMap"
> mode and comparator = true didn't work correctly, as the comparator is
> descending. This PR changes the benchmark to use headMap instead of tailMap
> in compa
On Thu, 20 Feb 2025 17:32:54 GMT, Sergey Chernyshev
wrote:
>> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java
>> line 73:
>>
>>> 71: break;
>>> 72: }
>
On Mon, 17 Feb 2025 11:28:38 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> added details in the log message
>
> test/hotspot/jtreg/containers/docker/TestMe
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
On Mon, 17 Feb 2025 11:09:12 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> added details in the log message
>
> src/java.base/linux/classes/
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
On Mon, 17 Feb 2025 15:48:51 GMT, Matthias Baesken wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> added details in the log message
>
> src/java.base/linux/classes/
On Thu, 12 Dec 2024 01:11:33 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it
On Wed, 11 Dec 2024 15:24:12 GMT, Severin Gehwolf wrote:
>> Would you recommand also to include the paths in that warning? Something like
>> ```cgroup controller path at '/sys/fs/cgroup' seems to have moved to
>> '../../test', detected limits won't be accurate```
>> This way it will have all the
On Wed, 11 Dec 2024 15:24:12 GMT, Severin Gehwolf wrote:
>> Would you recommand also to include the paths in that warning? Something like
>> ```cgroup controller path at '/sys/fs/cgroup' seems to have moved to
>> '../../test', detected limits won't be accurate```
>> This way it will have all the
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
On Fri, 6 Dec 2024 09:51:52 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 13 commits:
>>
>> - diverged after integration of JDK-8344177
>>
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
On Sat, 30 Nov 2024 00:30:02 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it
On Mon, 2 Dec 2024 10:47:01 GMT, Severin Gehwolf wrote:
> And after the patch this would become this, right?
>
> ```
> /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> /sys/fs/cgroup/cpu,cpuacct/
> ```
It depends on whether it was a subgroup in th
On Fri, 29 Nov 2024 17:19:34 GMT, Severin Gehwolf wrote:
> In the cloudflare case we'd end up with a subsystem path of
> `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c`.
> Since the cgroup_path != _root we trigger path adjustment increasing the
On Wed, 27 Nov 2024 11:07:18 GMT, Severin Gehwolf wrote:
> Right. I'm still not convinced this extra reduction buys us much. The adjust
> controller logic will handle it if kept as is in the Metrics version.
The adjust controller logic won't handle it, because it reduces the path from
child to
On Wed, 27 Nov 2024 10:18:24 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust path suffix in cgroup (v1) version specific code, when root !=
>> c
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
On Wed, 27 Nov 2024 09:08:30 GMT, Sergey Chernyshev
wrote:
> Done. Please see the updated PR.
The metrics part still needs the update - in the cgroup version specific
`setPath()`.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860451322
On Mon, 25 Nov 2024 09:44:33 GMT, Severin Gehwolf wrote:
> ```
> "echo '+memory' > /sys/fs/cgroup/memory/cgroup.subtree_control ; "
> ```
>
> ... relies on the user in the container image to be `root`. So depending on
> which base image is being used - by means of
> `-Djdk.test.docker.image.na
On Mon, 25 Nov 2024 09:40:03 GMT, Severin Gehwolf wrote:
> Version specific code can be had in `set_subsystem_path()` of the
> corresponding impl (like an earlier version of your patch). `lowest_limit`
> and `limit_cg_path` fixes are version agnostic and can and should be fixed in
> `CgroupUti
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
On Sat, 23 Nov 2024 00:06:26 GMT, Sergey Chernyshev
wrote:
> It looks like there's no way to see at this point, if we are in cgroup v1 or
> v2 - if I am not mistaken.
On the other hand, a type parameter can be added to
`CgroupUtil::adjust_controller()`. Would you recomme
On Fri, 22 Nov 2024 16:48:04 GMT, Severin Gehwolf wrote:
> The added code in `CgroupUtil::adjust_controller` runs for cg v1 and cg v2
> when path adjustment is deemed needed. So I'm not clear why it's needed for
> cg v2
It looks like there's no way to see at this point, if we are in cgroup v1
On Fri, 22 Nov 2024 10:57:31 GMT, Severin Gehwolf wrote:
> One thing to note is that the new test requires root privileges (AFAIK). We
> should skip the test if we are being run as root.
The test works just like other docker tests, root privileges are not required.
In systems that can't run do
On Fri, 22 Nov 2024 10:54:34 GMT, Severin Gehwolf wrote:
> Good spot! How about this to fix it?
>
> ```
> jlong limit = mem->read_memory_limit_in_bytes(phys_mem);
> jlong lowest_limit = limit < 0 ? phys_mem: limit;
> ```
Make sense to me.
> I'm worried about the added complexity. 1.) Is this
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
On Tue, 12 Nov 2024 23:29:47 GMT, Sergey Chernyshev
wrote:
>> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java
>> line 46:
>>
>>> 44: }
>>> 45:
>>> 46: public void setPath(String cgroupPath) {
On Thu, 14 Nov 2024 23:51:24 GMT, Phil Race wrote:
> remove uses of SM APIs from the java.datatransfer module. Also cleans up the
> now un-needed export from java.base
Marked as reviewed by serb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/22127#pullrequestreview-2437
On Tue, 12 Nov 2024 19:41:50 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contai
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it
On Mon, 11 Nov 2024 10:23:02 GMT, Severin Gehwolf wrote:
> The JBS issue doesn't mention `NullPointerException`. It would be good to
> list the observed NPE issue.
Example for NPE:
public class Test {
public static void main(String[] args) {
java.lang.management.ManagementFactory.
On Mon, 11 Nov 2024 15:48:48 GMT, Severin Gehwolf wrote:
> So on cg v1 you start out and end with a `subsystem_path() == null` and on cg
> v2 you start out and end with a `subsystem_path() ==
> /../../../../../../test`. In both cases the memory limit of 400m won't be
> detected.
Only when doc
On Mon, 11 Nov 2024 15:16:15 GMT, Severin Gehwolf wrote:
> On cg v2, on the other hand, `set_subsystem_path()` will never set the path
> to a `null` value.
Exactly. That's why JDK-8322420 is not in effect and also
[JDK-8336881](https://bugs.openjdk.org/browse/JDK-8336881) does not fix it on
J
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
For example:
>
> 5:cpuacct,cpu,cpuset:/daemons
> ...
> [3] This field contains the pathname of the control group
>in the hierarchy to which the process belongs. This
>pathname is relative to the mount point
On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev
wrote:
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev
wrote:
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev
wrote:
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
Cgroup V1 subsustem fails to initialize mounted controllers properly in certain
cases, that may lead to controllers left undetected/inactive. We observed the
behavior in CloudFoundry deployments, it affects also host systems.
The relevant /proc/self/mountinfo line is
2207 2196 0:43
/system.sl
On Wed, 9 Oct 2024 07:50:20 GMT, Matthias Baesken wrote:
>> There is some old awt/2d coding where warnings occur when running with ubsan
>> enabled binaries.
>> However at most of these locations the coding should work (at least on our
>> supported platform set) so the warnings can be disabled
On Mon, 2 Sep 2024 16:19:01 GMT, fabioromano1 wrote:
>> This implementation of MutableBigInteger.leftShift(int) optimizes the
>> current version, avoiding unnecessary copy of the MutableBigInteger's value
>> content and performing the primitive shifting only in the original portion
>> of the v
On Tue, 3 Sep 2024 15:49:01 GMT, fabioromano1 wrote:
> > It would be nice to see some benchmarks where it gives performance benefits.
>
> @kuksenko Try to run the benchmark of the `BigInteger`'s square root, maybe
> there the benefits are more visible...
"maybe"
So, you don't have proof th
On Mon, 2 Sep 2024 16:19:01 GMT, fabioromano1 wrote:
>> This implementation of MutableBigInteger.leftShift(int) optimizes the
>> current version, avoiding unnecessary copy of the MutableBigInteger's value
>> content and performing the primitive shifting only in the original portion
>> of the v
7;t have benchmarks targeting lambdas startup.
From: Mandy Chung ***@***.***>
Sent: Wednesday, April 17, 2024 9:32 AM
To: openjdk/jdk
Cc: Sergey Kuksenko; Mention
Subject: [External] : Re: [openjdk/jdk] 8294960: Convert
java.base/java.la
Hi Alan,
Thank you for your comments! I will post this to net-nev too as you
suggested.
Am 28.03.24 um 00:23 schrieb Alan Bateman:
On 27/03/2024 17:05, Sergey Chernyshev wrote:
In the discussion of .ofLiteral() it was not concluded that
.ofPosixLiteral() would be insecure or
t for no good reason. I think this was also the conclusion for the
ofLiteral() api.
Sergey Chernyshev wrote on 26. Mar 2024 17:51 (GMT +01:00):
Hello Core Libs Dev team,
I would like to propose a PR to extend the InetAddress API in JDK 23,
ows exactly
what it does.
Please share your thoughts on whether such a change might be desirable
in JDK 23.
Thank you for your help!
Best regards
Sergey Chernyshev
[1] https://bugs.openjdk.org/browse/JDK-8315767
[2] https://bugs.openjdk.org/browse/JDK-8272215
On Thu, 25 Jan 2024 21:35:45 GMT, Sergey wrote:
> The feature allows to extract a private field value in a single expression,
> like so:
>
> object.getClass().getDeclaredField().setAccessible().get(object)
I'm sorry to hear this. It's done all the time in tests, by thi
On Mon, 11 Mar 2024 23:22:44 GMT, Brian Burkhalter wrote:
> > What is the "standard protocol" to find a reviewer?
>
> Reviewers will generally chime in of their own accord depending on their
> expertise, interest, availability, the perceived importance of the issue, and
> so on.
What can I do
On Thu, 25 Jan 2024 21:35:45 GMT, Sergey wrote:
> The feature allows to extract a private field value in a single expression,
> like so:
>
> object.getClass().getDeclaredField().setAccessible().get(object)
So the only thing left seems to be finding a reviewer. What is the "s
On Tue, 27 Feb 2024 06:09:03 GMT, Chen Liang wrote:
> First, usually to propose a patch to core libraries, we usually submit an
> issue or suggest an enhancement to https://bugs.java.com, or ask at
> `core-libs-dev@openjdk.org`.
>
> A field that has been "set accessible" is supposed to be reus
On Thu, 25 Jan 2024 21:35:45 GMT, Sergey wrote:
> The feature allows to extract a private field value in a single expression,
> like so:
>
> object.getClass().getDeclaredField().setAccessible().get(object)
How do I find an eligible reviewer and create an issue to link this PR to
The feature allows to extract a private field value in a single expression,
like so:
object.getClass().getDeclaredField().setAccessible().get(object)
-
Commit messages:
- Add functional-style setAccessible()
Changes: https://git.openjdk.org/jdk/pull/17578/files
Webrev: https://w
On Mon, 22 Jan 2024 20:52:32 GMT, Roger Riggs wrote:
> When an exception handler for an OutOfMemoryError uses string concatenation
> to compose an exception message, the invoke dynamic string format
> implementation may itself exhaust memory, preventing the exception from being
> handled.
> Ex
On Fri, 22 Dec 2023 13:00:11 GMT, Sergey Tsypanov wrote:
>> Currently if we create a record it's fields are compared in their
>> declaration order. This might be ineffective in cases when two objects have
>> "heavy" fields equals to each other, but different &q
On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov wrote:
> SaslInputStream.read() should return a value in the range from 0 to 255 per
> the spec of InputStream.read() but it returns the signed byte from the inBuf
> as is.
This pull request has now been integrated.
Changeset: 5cf794
On Fri, 12 Jan 2024 07:22:09 GMT, Alan Bateman wrote:
> Just curious if this was found by inspection or when debugging some issue
> with LDAP authentication? Asking on whether it is feasible or not to have
> more tests in this area.
It was found by the code inspection.
-
PR Comme
SaslInputStream.read() should return a value in the range from 0 to 255 per the
spec of InputStream.read() but it returns the signed byte from the inBuf as is.
-
Commit messages:
- 8323562: SaslInputStream.read() may return wrong value
Changes: https://git.openjdk.org/jdk/pull/1736
On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov wrote:
> SaslInputStream.read() should return a value in the range from 0 to 255 per
> the spec of InputStream.read() but it returns the signed byte from the inBuf
> as is.
I'll wait until GA will be fixed.
-
PR
On Wed, 3 Jan 2024 18:01:59 GMT, Brian Burkhalter wrote:
> The final position instead of the number of bytes to write was being passed
> to `ByteArrayOuputStream.write(byte[],int,int)`.
Marked as reviewed by stsypanov (Author).
-
PR Review: https://git.openjdk.org/jdk/pull/17250#p
On Wed, 29 Nov 2023 11:57:37 GMT, Sergey Tsypanov wrote:
> It looks like we can skip copying of `byte[]` in
> `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in
> `java.io`.
>
> See comment by @vlsi in
> https://github.com/openjdk/jdk/pul
e677ecbd977af1R612
Sergey Tsypanov has updated the pull request incrementally with one additional
commit since the last revision:
Update TransferToTrusted.java
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16879/files
- new: https://git.openjdk.org/jdk/pull/16879/files/
1 - 100 of 361 matches
Mail list logo
