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 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 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 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 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 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 Mon, 1 Apr 2024 23:37:21 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 Mon, 1 Apr 2024 23:37:21 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 Fri, 29 Mar 2024 00:52:46 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 Fri, 29 Mar 2024 00:52:46 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 29/03/2024 05:43, science2000 wrote:
Hello Core Libs Dev team,
I would like to propose a patch [1] that applies pattern matching for
'instanceof' (JEP-394) and 'switch-case' (JEP-433) on java.base. I
suppose this enchantment will improve readability and reduce the code
redundancy in
On 27/03/2024 17:05, Sergey Chernyshev wrote:
In the discussion of .ofLiteral() it was not concluded that
.ofPosixLiteral() would be insecure or undesirable. From the 'security
issues' point of view, it is a new method, it won't change the
behavior of old apps. If any code (a csrf filter)
On 27/03/2024 01:51, Sergey Chernyshev wrote:
Hello Core Libs Dev team,
I would like to propose a PR to extend the InetAddress API in JDK 23,
namely to provide interface to constructing InetAddress objects from
literal addresses in POSIX/BSD form (please see the discussion [1]),
to the Apps
On Sun, 3 Mar 2024 17:03:51 GMT, Doug Simon wrote:
>> The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail
>> when run on libgraal and `-Xcomp` is specified. The problem is that libgraal
>> in `-Xcomp` temporarily causes some extra memory pressure (probably due to
>>
Vote: yes
On Mon, 18 Mar 2024 17:40:26 GMT, Mandy Chung wrote:
> A simple fix. This is caused by a bug in `VerifyAccess::isClassAccessible`
> that checks if a class is exported from `java.base` before the exports are
> fully setup.It should check if the module system is fully initialized
> before
On Mon, 18 Mar 2024 16:47:24 GMT, Bill Huang wrote:
> This task addresses an essential aspect of our testing infrastructure: the
> proper handling and cleanup of temporary files and socket files created
> during test execution. The motivation behind these changes is to prevent the
>
On Thu, 14 Mar 2024 17:35:22 GMT, Mandy Chung wrote:
> Trivial fix. Improve the error message to print the cause of the module
> resolution failure if present.
Tests that depend on exception messages can be problematic but this one is easy
to change if/when the exception message changes.
On Mon, 11 Mar 2024 16:32:31 GMT, Naoto Sato wrote:
>> Removing left over "applet" mention in the package-info doc.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Addressing review comments
Marked as reviewed by alanb
On Wed, 6 Mar 2024 12:14:10 GMT, Magnus Ihse Bursie wrote:
> * `test/jdk/java/lang/Thread/jni/AttachCurrentThread/libImplicitAttach.c` was
> missing an export. This had not been discovered before since that file was
> not compiled on Windows.
It's a Linux/macOS specific test so it wasn't
On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie wrote:
>> Currently, our symbol visibility handling for tests are sloppy; we only
>> handle it properly on Windows. We need to bring it up to the same levels as
>> product code. This is a prerequisite for
>>
On Sun, 10 Mar 2024 08:24:42 GMT, Eirik Bjørsnøs wrote:
> GHA revealed two call sites for `getAndSetObject` in the test
> `test/hotspot/jtreg/gc/shenandoah/compiler/TestUnsafeLoadStoreMergedHeapStableTests.java`.
>
> I have replaced these with the `getAndSetReference`, grepped for any
>
On Sun, 10 Mar 2024 05:50:33 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which removes the 19 deprecated `xxObject*` alias
> methods from `jdk.internal.misc.Unsafe`.
>
> These methods were added in JDK-8213043 (JDK 12), presumably to allow
> `jsr166.jar` to be used across JDK versions.
On Fri, 8 Mar 2024 19:54:31 GMT, Naoto Sato wrote:
> Removing left over "applet" mention in the package-info doc.
src/java.base/share/classes/java/text/package-info.java line 29:
> 27: * Provides classes and interfaces for handling text, dates, numbers,
> 28: * and messages in a manner
On Fri, 8 Mar 2024 16:47:33 GMT, Magnus Ihse Bursie wrote:
> What is the rationale for introducing a special configure flag for this
> functionality? I've tried to look though all comments in this PR, and read
> the JBS issue and CSR, but I have not found any motivation for this. I'm
> sorry
On Thu, 7 Mar 2024 21:53:07 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
On Wed, 6 Mar 2024 21:16:25 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
On Wed, 6 Mar 2024 21:22:40 GMT, Jan Lahoda wrote:
>> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line
>> 812:
>>
>>> 810: }
>>> 811:
>>> 812: private static void addEnableNativeAccess(ModuleLayer layer,
>>> Set moduleNames, boolean shouldWarn) {
>>
>> The
On Wed, 6 Mar 2024 22:58:54 GMT, Viktor Klang wrote:
> The common ForkJoinPool creating threads as a result of submitting tasks is
> preventing class unloading when the thread construction is initiated from a
> class loaded in a separate classloader. This fix avoids that when no
>
On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
On Wed, 6 Mar 2024 18:00:25 GMT, Mandy Chung wrote:
> Native access is needed for modules which calls restricted methods [1].
In time, we'll need it for modules using JNI too. We can do this trimming in
another PR to avoid Jan getting pulled into deeply.
-
PR Review Comment:
On Wed, 6 Mar 2024 15:45:16 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
On Wed, 6 Mar 2024 14:25:09 GMT, Matthias Baesken wrote:
> We could maybe also use the existing
> https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/include/jni_md.h
> - what do you think ?
jni_md.h goes into the JDK run-time image (for jni.h to include) so I don't
think we
On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken wrote:
> We define the RESTARTABLE macro again and again at a lot of places in the JDK
> native codebase. This could be centralized to avoid repeating it again and
> again !
src/java.base/share/native/libjava/jni_util.h line 243:
> 241: }
On 06/03/2024 10:56, wenshao wrote:
Many libraries use Unsafe to improve performance, especially in many
performance-critical scenarios of big data, such as Apache
Flink/Apache Arrow, etc. Direct removal will make it difficult to
adopt the new version of JDK.
It is recommended to use it
On Tue, 5 Mar 2024 22:44:20 GMT, Mandy Chung wrote:
> Many of these modules do not need native access in the current implementation.
In addition this will eventually need jlink support. I view the change to
ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules() as
very
On 05/03/2024 22:57, mandy.ch...@oracle.com wrote:
These deprecated methods were added to make jsr166.jar to run on
different JDK releases. I think it's time to remove these deprecated
xxxObject* methods as the renames have been done since JDK 12 for 5
years.
Yes, I think they can be
On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
On Tue, 5 Mar 2024 13:42:32 GMT, Jaikiran Pai wrote:
> to make the intention clear as well as reduce the chances of missing some
> boot or platform module in this NATIVE_ACCESS_MODULES?
The list to be be granted native access is a subset, it shouldn't be granted
all modules mapped to the boot
On Mon, 4 Mar 2024 13:55:15 GMT, Claes Redestad wrote:
> [JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) accidentally
> removed `final` from the `static final DataInputStream.readUTF` method. This
> has a minor compatibility impact (allows hiding the method in a subclass,
> while
On Sat, 2 Mar 2024 18:51:16 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which proposes that we officially deprecate the
>> following four methods in the `java.util.zip` package:
>>
>> * `Inflater.getTotalIn()`
>> * `Inflater.getTotalOut()`
>> * `Deflater.getTotalIn()`
>> *
On Fri, 1 Mar 2024 01:50:46 GMT, Vladimir Petko wrote:
> This MR fixes segsegv in jspawnhelper when it is called without args.
> This scenario happens when a long running Java process is not restarted
> during upgrade.
>
> It updates
On Wed, 28 Feb 2024 09:19:20 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which proposes that we officially deprecate the
>> following four methods in the `java.util.zip` package:
>>
>> * `Inflater.getTotalIn()`
>> * `Inflater.getTotalOut()`
>> * `Deflater.getTotalIn()`
>> *
On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote:
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
>
On Mon, 26 Feb 2024 20:46:01 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which proposes that we officially deprecate the
>> following four methods in the `java.util.zip` package:
>>
>> * `Inflater.getTotalIn()`
>> * `Inflater.getTotalOut()`
>> * `Deflater.getTotalIn()`
>> *
On Mon, 26 Feb 2024 15:04:01 GMT, Eirik Bjørsnøs wrote:
> I'm wondering if the somewhat tedious "number of compressed bytes input so
> far" could be further simplified. Besides being a long repetition from the
> leading sentence, when used in this sentence, we actually mean to refer to
> the
On Mon, 26 Feb 2024 14:14:21 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.
-
PR
On Mon, 26 Feb 2024 06:00:13 GMT, Jaikiran Pai wrote:
>>> (In passing, the casing of "zip file" is very inconsistent in the javadoc,
>>> it's "ZIP file" in some places, "zip file" in others, the change here uses
>>> "Zip file").
>>
>> Thank you for pointing out the discrepancy above.
>>
>>
On Mon, 26 Feb 2024 11:34:18 GMT, Claes Redestad wrote:
>> jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when
>> generating some classes.
>>
>> Since JDK 9 we have a fast-path (which avoids creating encoders) for
>> UTF-8-encoding strings which is bootstrapped very
On Sun, 25 Feb 2024 14:17:05 GMT, Lance Andersen wrote:
>> Please review this PR which addresses the handling of invalid UTF-8 byte
>> sequences in the entry name of a LOC file header and a Zip file comment
>> which is returned via ZipFile::getComment.
>>
>> As part of the change,
On Thu, 22 Feb 2024 14:06:25 GMT, Eirik Bjørsnøs wrote:
> Alan,
>
> Finding a good way to express this while being correct and succinct was
> surprisingly hard. What I have now is probably far from perfect, but at least
> something to serve as a starting point for review:
The `@depreacted`
On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato wrote:
> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
> `COMPAT` locale data was introduced for applications' migratory purposes
> transitioning to `CLDR`. It is becoming a technical debt and now is the time
> to
On Wed, 21 Feb 2024 15:01:15 GMT, Viktor Klang wrote:
> More aggressively breaking chains in order to prevent nodes promoted to older
> generations standing in the way for collecting younger nodes. I decided that
> it was most efficient to add this logic to the else-branch of updating the
>
On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan wrote:
> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all
> the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
>
>
On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan wrote:
> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all
> the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
>
>
On Tue, 20 Feb 2024 13:29:28 GMT, Eirik Bjørsnøs wrote:
> Should these methods specify return values when the number of processed bytes
> exceed Integer.MAX_VALUE?
I think they should, otherwise it's not clear if the return value is clamped at
Integer.MAX_VALUE. The wording can make it clear
On Mon, 19 Feb 2024 10:30:24 GMT, Sean Coffey wrote:
> Nice improvement to have. would it be ok to pad out this comment a bit more ?
> I found it difficult to understand the specifics. Perhaps :
>
> ```
> // In LM_JAR mode, keep the underlying file open to retain it
> in
>
On Mon, 19 Feb 2024 07:04:07 GMT, David Holmes wrote:
> Please reviews these manpage updates in relation to "JEP 458: Launch
> Multi-File Source-Code Programs". The manpage sources had previously been
> updated internally at Oracle under JDK-8322478, but the open troff file was
> not
On Sun, 18 Feb 2024 10:56:47 GMT, Eirik Bjørsnøs wrote:
> Thanks for your review Alan!
>
> > The hazard when the format specifiers are all %s.
>
> Not sure I understand your comment since all arguments are of the same type
> (int) anyhow, I guess they would still be easy to get wrong or in
201 - 300 of 2040 matches
Mail list logo
