On Wed, 8 May 2024 17:30:22 GMT, Claes Redestad wrote:
>> A rather large startup regression was introduced in 23-b13 from
>> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
>> been dealt with as enhancements such as
>>
On Wed, 8 May 2024 17:30:22 GMT, Claes Redestad wrote:
>> A rather large startup regression was introduced in 23-b13 from
>> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
>> been dealt with as enhancements such as
>>
On Wed, 8 May 2024 17:01:05 GMT, Claes Redestad wrote:
>> A rather large startup regression was introduced in 23-b13 from
>> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
>> been dealt with as enhancements such as
>>
On Wed, 8 May 2024 17:01:05 GMT, Claes Redestad wrote:
>> A rather large startup regression was introduced in 23-b13 from
>> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
>> been dealt with as enhancements such as
>>
On Tue, 7 May 2024 08:08:05 GMT, Joachim Kern wrote:
>> Since ~ end of March, after
>> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131),
>> tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>>
>> stdout: [];
>> stderr: [Error: could not find libjava.so
>> Error: Could
On Mon, 29 Apr 2024 21:17:24 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Mon, 29 Apr 2024 21:17:24 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Tue, 19 Mar 2024 00:40:02 GMT, Y. Srinivas Ramakrishna
wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> further tweaks to reachability
>
> src/java.base/share/classes/java/lang/ref/package-info.java line
On Mon, 29 Apr 2024 21:17:24 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Fri, 23 Feb 2024 06:06:21 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Wed, 1 May 2024 22:33:29 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>> jaxp-compat.properties: used to regain compatibility from any
On Wed, 8 May 2024 05:29:03 GMT, Jaikiran Pai wrote:
> Hello Raffaello, the proposed changes look OK to me. Do you think we should
> add a jtreg test for this?
>
> In general, the test coverage for these APIs appears to be missing. I think
> that can be addressed separately in some of the
On Sat, 4 May 2024 18:29:25 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
Yes, what you described is what was happening, Mark. I didn't display
all of the code to the session methods, and I did re-read the in-coming
flowfile for different purposes than I had already read and written it.
So, I wasn't helpful enough. In the end, however, I had forgotten,
immediately
On Tue, 7 May 2024 14:58:00 GMT, Viktor Klang wrote:
> Removes SORTED if not also ORDERED for escape-hatch `Stream::spliterator()`
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19123#pullrequestreview-2043916265
In /pom.xml/ I specify using NiFi framework libraries from 1.13.2.
There are peculiar reasons (that we are trying to fix) that inhibit us
from moving forward as all of our customer machines are running 1.1.2.
(Don't shoot me, I'm not DevOps, but just the guy who writes custom
processors.)
I
Public bug reported:
Both apt.log and main.log do not appear to contain any help in
pinpointing the error
ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: ubuntu-release-upgrader-core 1:22.04.19
ProcVersionSignature: Ubuntu 6.5.0-28.29~22.04.1-generic 6.5.13
Uname: Linux 6.5.0-28-generic
On Sun, 5 May 2024 12:05:48 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java
>> line 147:
>>
>>> 145:
>>> FactoryMapHolder.class.getModule().addUses(RandomGenerator.class);
>>> 146: return ServiceLoader
>>>
On Sat, 4 May 2024 18:29:25 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
On Fri, 3 May 2024 18:31:21 GMT, Chris Plummer wrote:
> What "debugging option" are you referring to.
`-Djdk.tracePinnedThreads=full`. When this system property is set then it means
the onPinned callback is running the printing code. This is happen in a
transition when running with JVMTI
On Fri, 3 May 2024 08:15:32 GMT, Matthias Baesken wrote:
> The naming GetApplicationHomeFromLD_LIBRARY_PATH looks a bit unconventional ;
> maybe adjust this ? Regarding if the code should be added for all platforms
> or just AIX, let's hear what Alan and others have to say.
I was busy with
On Thu, 2 May 2024 22:40:02 GMT, Chris Plummer wrote:
> It seems maybe we should instead be trying to avoid these events by
> preloading the classes as was suggested as an option in the CR.
I don't think preloading PinnedThreadPrinter will solve it completely. First
usage could potentially
On Thu, 2 May 2024 21:44:43 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: Corrections in: 1) JVMTI/JDWP spec; 2) test vthread checks; 3)
>> test comments
>
>
On 02/05/2024 19:33, Chris Marshall wrote:
:
Last week I upgraded the application to be compiled by JDK22, and run
on JDK22. Immediately, we started to see failures from within the
User-SRP auth code /only when it was run on a virtual thread from
within a StructuredTaskScope./ The failures
On Thu, 2 May 2024 17:17:54 GMT, Liam Miller-Cushon wrote:
> Please keep this open, assistance on progressing this pull request is welcome
ACK. There was a lengthy bug tail when zip64 support was added. We've got away
without needing this for executable JAR files for a long time so it's great
On Thu, 2 May 2024 07:33:09 GMT, Serguei Spitsyn wrote:
>> The fix is to degrade virtual threads support in the JVM TI
>> `GetObjectMonitorUsage` function so that it is specified to only return an
>> owner when the owner is a platform thread. Also, virtual threads are not
>> listed in the
On Tue, 30 Apr 2024 10:21:49 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
On Mon, 29 Apr 2024 21:53:02 GMT, Tim Prinzing wrote:
> Should I set the default to be fairly high (like maybe 1600ms)? I think to be
> useful people will have to set the threshold to something that fits their
> needs anyway.
I wonder about the usefulness of this event if the default
On Mon, 29 Apr 2024 16:42:05 GMT, Viktor Klang wrote:
> This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and
> status for Stream Gatherers.
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19003#pullrequestreview-2030820148
On Mon, 29 Apr 2024 16:42:59 GMT, Viktor Klang wrote:
> @AlanBateman Let me know if I should create a new JBS issue for this change,
> or if it is fine to target the JEP JBS issue. 樂
The bot has spotted this already (see "Integration Blocker" in the updated
description). You'll need to create
On Mon, 29 Apr 2024 14:45:07 GMT, Joachim Kern wrote:
> Since ~ end of March, after
> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131),
> tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>
> stdout: [];
> stderr: [Error: could not find libjava.so
> Error: Could not
On Fri, 26 Apr 2024 09:41:21 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
On Fri, 26 Apr 2024 08:08:25 GMT, Viktor Klang wrote:
> This PR adds the exception documentation as per the ExecutorService API
> contract. I also took the liberty of adding @Override-annotations to be clear
> about intent.
Marked as reviewed by alanb (Reviewer).
I think this is okay. The
On Thu, 25 Apr 2024 13:17:51 GMT, Matthias Baesken wrote:
> I removed the mentioned 'private JRE' check and also the related size check.
Good, I'll look at it as soon as I can. I suspect we'll need some follow on
issues as there are several issues here.
-
PR Comment:
On Tue, 23 Apr 2024 14:29:05 GMT, Matthias Baesken wrote:
>
> `/* Does the app ship a private JRE in /jre directory? */`
>
> part meant? This looks indeed obsolete .
Yes, this is code that doesn't make sense since JDK 9 and should be
removed/cleanup at some point. I suspect we had to leave
On Wed, 24 Apr 2024 15:27:23 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
On Thu, 25 Apr 2024 07:56:59 GMT, Adam Sotona wrote:
> Pr/18914 broke tests build.
> This patch fixes
> `test/micro/org/openjdk/bench/jdk/classfile/CodeAttributeTools`
>
> Please review.
>
> Thanks,
> Adam
Marked as reviewed by alanb (Reviewer).
-
PR Review:
On 25/04/2024 05:29, Iñigo Mediavilla wrote:
Hello,
For my first contribution to OpenJDK, I've started looking into
JDK-8313674, an issue that falls into core-libs. According to the
OpenJDK Developers’ Guide I'd need a sponsor to help me through the
contribution process, would anyone be
On Wed, 24 Apr 2024 15:45:58 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request with a new target base due to a
> merge or a
On Wed, 24 Apr 2024 13:50:56 GMT, Raffaello Giulietti
wrote:
> Move all random generators mandated in package `java.util.random` and
> currently implemented in module `jdk.random` to module `java.base`, and
> remove module `jdk.random`.
What is the footprint implications for this? I'm trying
On Tue, 23 Apr 2024 18:08:34 GMT, Brian Burkhalter wrote:
>> I was thinking more of a subclass that counted invocations to public methods
>> or metering which would cause subclass to double the counts when calling via
>> virtual thread.
>
> So do we think it better not to invoke `toByteArray`
On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman wrote:
> This change drops the adjustments to the virtual thread scheduler's target
> parallelism when virtual threads do file operations on files that are opened
> for buffered I/O. These operations are usually just too short to
On Tue, 23 Apr 2024 11:16:01 GMT, Jason Mehrens wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Correct ID in test @bug tag
>
> src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 164:
>
>>
On Mon, 22 Apr 2024 11:57:19 GMT, Alan Bateman wrote:
>> Hi, any additional comments / reviews ?
>> Thanks Matthias
>
>> Hi, any additional comments / reviews ? Thanks Matthias
>
> It still looks like left over trace messages from a debugging session, need
> to
On Tue, 23 Apr 2024 08:04:54 GMT, Viktor Klang wrote:
>> Alan Bateman 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
On Tue, 23 Apr 2024 07:11:34 GMT, Viktor Klang wrote:
> Has the alternative of moving to a j.u.c.Lock (Needs Reentrant or not?) been
> explored/benchmarked?
Yes, decided not to do because it's just guarding access to a byte[] and any
changes can influence the inlining. Plus, it would need to
On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since
direct
> buffer in some I/O operations). This part is a pre-requisite to the changes
> to better support object monitor there are more places where preemption is
> possible and this quickly leads to unbalanced begin/end.
>
> The changes have been baking in loom repo for some time.
On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman wrote:
> This change drops the adjustments to the virtual thread scheduler's target
> parallelism when virtual threads do file operations on files that are opened
> for buffered I/O. These operations are usually just too short to
On Mon, 22 Apr 2024 10:34:29 GMT, Claes Redestad wrote:
> This switch expression in `Locale::createLocale` is causing a somewhat large
> startup regression on my local system. Desugaring to if statements seem like
> the right thing to do while we investigate ways to further reduce overheads
>
On Mon, 22 Apr 2024 10:34:29 GMT, Claes Redestad wrote:
> This switch expression in `Locale::createLocale` is causing a somewhat large
> startup regression on my local system. Desugaring to if statements seem like
> the right thing to do while we investigate ways to further reduce overheads
>
On Mon, 22 Apr 2024 11:30:41 GMT, Matthias Baesken wrote:
> Hi, any additional comments / reviews ? Thanks Matthias
It still looks like left over trace messages from a debugging session, need to
think about about what tracing make sense here.
-
PR Comment:
On Fri, 19 Apr 2024 11:33:59 GMT, Evemose wrote:
> but i cant manage to find where exactly and how I can file CSR review
> request. Could you help me out?
I think you can ignore CSR for now, the first step when proposing an API in
this area is to start a discussion on core-libs-dev to make
On Wed, 17 Apr 2024 01:34:07 GMT, Tim Prinzing wrote:
>> Currently the JFR event FileForceEvent is generated by instrumenting the
>> sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer
>> mirror events with static methods.
>>
>> Added the event at
On Wed, 17 Apr 2024 23:24:06 GMT, Joe Wang wrote:
> Add two sample configuration files:
>
> jaxp-strict.properties: used to set strict configuration, stricter than
> jaxp.properties in previous versions such as JDK 22
>
> jaxp-compat.properties: used to regain compatibility from any more
On Tue, 16 Apr 2024 14:29:13 GMT, Matthias Baesken wrote:
>> src/java.base/windows/native/libjli/java_md.c line 326:
>>
>>> 324: }
>>> 325:
>>> 326: JLI_TraceLauncher("GetJREPath - attempt to get JRE location from
>>> shared lib of the image\n");
>>
>> Maybe add a trace also in the
On Wed, 17 Apr 2024 19:33:09 GMT, Jan Lahoda wrote:
>> This is an implementation of JEP JDK-8315129: Module Import Declarations
>> (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>>
>> It is mostly straightforward - the module imports are parsed, and
On Tue, 16 Apr 2024 14:29:13 GMT, Matthias Baesken wrote:
> I am not sure if this even works any more. Maybe Alan could comment on this ?
The GetPublicJREHome function was removed at some point, I think JDK 9, as it
didn't make sense to have in the OpenJDK project. However, Oracle installer
On Tue, 16 Apr 2024 11:59:12 GMT, Severin Gehwolf wrote:
> If I understand you correctly, this would be no longer a build-time only
> approach to produce the "linkable runtime"? It would be some-kind of
> jlink-option driven approach (as it would run some code that should only run
> when
On Tue, 16 Apr 2024 11:59:12 GMT, Severin Gehwolf wrote:
> If I understand you correctly, this would be no longer a build-time only
> approach to produce the "linkable runtime"? It would be some-kind of
> jlink-option driven approach (as it would run some code that should only run
> when
On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move CreateLinkableRuntimePlugin to build folder
>>
>> Keep runtime link supporting classes in package
>>
On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move CreateLinkableRuntimePlugin to build folder
>>
>> Keep runtime link supporting classes in package
>>
On Tue, 16 Apr 2024 08:25:01 GMT, Thomas Stuefe wrote:
>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 912:
>>
>>> 910: private static final int MAIN_WITHOUT_ARGS = 1;
>>> 911: private static final int MAIN_NONSTATIC = 2;
>>> 912: private static int mainType =
On Tue, 9 Apr 2024 15:28:08 GMT, Matthias Baesken wrote:
> We have already good JLI tracing capabilities. But GetApplicationHome and
> GetApplicationHomeFromDll lack some tracing and should be enhanced.
I think this is way too ad hoc and looks like lefts over from a debugging
session. So I
On Mon, 26 Feb 2024 14:17:09 GMT, Daniel Fuchs wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 44:
>>
>>> 42: @Label("SelectionKey Count")
>>> 43: @Description("Number of channels ready for I/O or added to ready
>>> set")
>>> 44: public int
On Mon, 15 Apr 2024 20:39:26 GMT, Tim Prinzing wrote:
>> test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 64:
>>
>>> 62:
>>> 63: data.flip();
>>> 64: ch.write(data, 0);
>>
>> This just initiates the write operation, it doesn't wait until it
On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles
wrote:
> Hi folks,
>
> This PR aims to fix
> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>
> I think the regression got introduced in
> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>
> In the issue
On Mon, 15 Apr 2024 07:36:05 GMT, Jan Lahoda wrote:
>> Consider code like:
>>
>> public class MainClass {
>> public MainClass() {
>> System.out.println("Constructor called!");
>> }
>> public static void main() {
>> System.out.println("main called!");
>> }
>> }
>>
On Fri, 12 Apr 2024 10:16:36 GMT, Jan Lahoda wrote:
> Consider code like:
>
> public class MainClass {
> public MainClass() {
> System.out.println("Constructor called!");
> }
> public static void main() {
> System.out.println("main called!");
> }
> }
>
> and
On 12/04/2024 14:06, Fabian Meumertzheim wrote:
Hi,
I noticed that jlink fails if the directory specified with --output
already exists. This makes it less convenient to use the tool with
build systems that pre-create output directories and expect build
actions to fill them (e.g. Bazel).
On Thu, 11 Apr 2024 09:12:30 GMT, Daniel Fuchs wrote:
>>> Maybe that's OK - and maybe in that case the onus is on the user to set a
>>> threshold greater than 1500ms?
>>
>> The threshold is 20ms so these timed-select ops in the HTTP client will
>> record an event when they timeout.
>
> We
On Wed, 10 Apr 2024 23:51:34 GMT, Tim Prinzing wrote:
>> Added mirror event with static methods: jdk.internal.event.SelectionEvent
>> that provides the duration of select calls and the count of how many keys
>> are available.
>>
>> Emit the event from SelectorImpl::lockAndDoSelect
>>
>> Test
On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman wrote:
> This change drops the adjustments to the virtual thread scheduler's target
> parallelism when virtual threads do file operations on files that are opened
> for buffered I/O. These operations are usually just too short to
On Wed, 10 Apr 2024 00:41:39 GMT, Brian Burkhalter wrote:
> changes look to be the most complicated here but I don't see any problems.
I have some changes come that should make this easier to read, I'll update the
PR in a few days.
-
PR Comment:
On Tue, 9 Apr 2024 15:28:08 GMT, Matthias Baesken wrote:
> We have already good JLI tracing capabilities. But GetApplicationHome and
> GetApplicationHomeFromDll lack some tracing and should be enhanced.
This looks very ad hoc. Not opposed to expanding the set of trace messages when
this env
On Tue, 9 Apr 2024 15:15:52 GMT, Jaikiran Pai wrote:
>> This change drops the adjustments to the virtual thread scheduler's target
>> parallelism when virtual threads do file operations on files that are opened
>> for buffered I/O. These operations are usually just too short to have any
>>
On Tue, 9 Apr 2024 14:59:00 GMT, Jaikiran Pai wrote:
> Was the use the word `tryCompensate` intentional here? I don't see that
> method in this class or in the implementation of
> `CarrierThread.beginBlocking()`
The FJP method is named tryCompensate and the same method name was used here at
On Tue, 9 Apr 2024 13:58:31 GMT, Jaikiran Pai wrote:
>> This change drops the adjustments to the virtual thread scheduler's target
>> parallelism when virtual threads do file operations on files that are opened
>> for buffered I/O. These operations are usually just too short to have any
>>
On Tue, 9 Apr 2024 13:53:11 GMT, Jaikiran Pai wrote:
>> This change drops the adjustments to the virtual thread scheduler's target
>> parallelism when virtual threads do file operations on files that are opened
>> for buffered I/O. These operations are usually just too short to have any
>>
On Tue, 9 Apr 2024 14:20:51 GMT, Jaikiran Pai wrote:
>> This change drops the adjustments to the virtual thread scheduler's target
>> parallelism when virtual threads do file operations on files that are opened
>> for buffered I/O. These operations are usually just too short to have any
>>
On Tue, 9 Apr 2024 07:54:19 GMT, Daniel Fuchs wrote:
> @jaikiran the only reservation I have is that the new wording makes it look
> like the default implementation of `ServerSocket` methods is going to call
> `SocketImpl::getOption(SocketOption<>)` while in fact it still calls
>
On Tue, 9 Apr 2024 01:27:29 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this test-only change which proposes to address
>> the intermittent failures in
>> `java/util/Properties/StoreReproducibilityTest.java`? This should address
>> https://bugs.openjdk.org/browse/JDK-8329729.
>>
On Sun, 7 Apr 2024 08:16:56 GMT, Jaikiran Pai wrote:
> > So I think we need a follow-up to the change here to say that the value is
> > Boolean.FALSE to disable (or disabled), otherwise an Integer with the
> > linger timeout.
>
> I've opened https://bugs.openjdk.org/browse/JDK-8329825 to
On Sun, 7 Apr 2024 01:43:31 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only changes to java.net.ServerSocket
>> and java.net.Socket classes?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes
>> currently refer to the legacy
On Fri, 5 Apr 2024 11:49:25 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which proposes to clean up
>> the documentation of `java.net.SocketOptions` interface?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing
>> documentation in this
On 07/04/2024 00:37, robert engels wrote:
Hi Daniel,
Here is a PR which fixes it.
I don't think anyone will be able to look at this PR until the "oca"
label is removed. Look for the comment that the bot added about signing
the OCA for instructions.
-Alan
On Fri, 5 Apr 2024 13:03:13 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only changes to java.net.ServerSocket
>> and java.net.Socket classes?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes
>> currently refer to the legacy
On Fri, 5 Apr 2024 11:49:25 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which proposes to clean up
>> the documentation of `java.net.SocketOptions` interface?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing
>> documentation in this
On Sat, 6 Apr 2024 08:41:23 GMT, Jaikiran Pai wrote:
> Alan, in context of another old issue
> https://bugs.openjdk.org/browse/JDK-6431396 would you want anything more to
> be added/updated for the `SO_BINDADDR` field's javadoc as part of this PR?
> The current update in PR already takes into
On Fri, 5 Apr 2024 12:06:21 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only changes to java.net.ServerSocket
>> and java.net.Socket classes?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes
>> currently refer to the legacy
On Fri, 5 Apr 2024 07:31:47 GMT, Jaikiran Pai wrote:
> Can I please get a review of this doc-only changes to java.net.ServerSocket
> and java.net.Socket classes?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes
> currently refer to the legacy `java.net.SocketOptions`
On Fri, 5 Apr 2024 06:56:06 GMT, Jaikiran Pai wrote:
> Can I please get a review of this doc-only change which proposes to clean up
> the documentation of `java.net.SocketOptions` interface?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing
> documentation in this
On Fri, 5 Apr 2024 01:11:49 GMT, David Holmes wrote:
> Does this generate a warning with `-Xcheck:jni` due to exceptions not being
> checked for?
I run with`TEST_OPTS_JAVA_OPTIONS=-Xcheck:jni` and don't see any warnings. Are
you asking about the usage of GetObjectClass (which is not
On Tue, 19 Mar 2024 12:16:29 GMT, Viktor Klang wrote:
> This is a draft PR with a potential solution to 8328366 without regressing
> 8327501.
>
> @DougLea To avoid regressions in the future, where would regression tests for
> this ideally be located?
The change looks okay. It's unfortunate
This change drops the adjustments to the virtual thread scheduler's target
parallelism when virtual threads do file operations on files that are opened
for buffered I/O. These operations are usually just too short to have any
benefit and may have a negative benefit when reading/writing a small
This is a test-only addition to add a test for virtual threads invoking a
synchronized native method and invoking a native method that enter/exits a
monitor with JNI MonitorEnter/MonitorExit. The test has been in the loom repo
for some time, it can move to the main line in advance of changes to
On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy wrote:
> When new language features are added, the javax.lang.model may need to be
> updated. For certain classes of features, the API update includes introducing
> a new set of concrete visitors to handle the language feature.
>
> The API
On Tue, 2 Apr 2024 15:42:05 GMT, Volodymyr Paprotski wrote:
> Performance. Before:
>
> Benchmark(algorithm) (dataSize) (keyLength)
> (provider) Mode Cnt ScoreError Units
> SignatureBench.ECDSA.signSHA256withECDSA1024 256
>
On Tue, 2 Apr 2024 15:42:05 GMT, Volodymyr Paprotski wrote:
> Performance. Before:
>
> Benchmark(algorithm) (dataSize) (keyLength)
> (provider) Mode Cnt ScoreError Units
> SignatureBench.ECDSA.signSHA256withECDSA1024 256
>
On Tue, 2 Apr 2024 15:42:05 GMT, Volodymyr Paprotski wrote:
> Performance. Before:
>
> Benchmark(algorithm) (dataSize) (keyLength)
> (provider) Mode Cnt ScoreError Units
> SignatureBench.ECDSA.signSHA256withECDSA1024 256
>
1 - 100 of 17953 matches
Mail list logo
