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 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 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 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 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 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 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 Wed, 6 Mar 2024 09:14:18 GMT, Serguei Spitsyn wrote:
>> Please, review this fix correcting the JVMTI `RawMonitorWait()`
>> implementation.
>> The `RawMonitorWait()` is using the the `jt->is_interrupted(true)` to
>> update the interrupt status of the interrupted waiting thread. The issue
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 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 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 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 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 05/03/2024 16:38, Eirik Bjørsnøs wrote:
:
Or are we better off just ignoring this, given the eventual removal of
SecurityManager?
I don't think it's worth spending time on this. There will be a JEP to
remove the SM "feature" (not the APIs) so methods like this will likely
be
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 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 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 Tue, 5 Mar 2024 01:06:32 GMT, Serguei Spitsyn wrote:
>>> AFAIK, as it is not a good idea to post the JVMTI events recursively
>>
>> We already do. When the debug agent is handling a JVMTI event and
>> RawMonitorWait is interrupted, that results in the debug agent later on
>> calling
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 Mon, 4 Mar 2024 13:24:05 GMT, Kevin Walls wrote:
>> The deprecated Subject Delegation feature in JMX will be removed.
>>
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the
On Mon, 4 Mar 2024 13:24:05 GMT, Kevin Walls wrote:
>> The deprecated Subject Delegation feature in JMX will be removed.
>>
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the
core-libs-dev is the place to send this.
-Alan
On 04/03/2024 12:11, S A wrote:
Hi all,
after moving our application to Java 21 (up from Java 17), we noticed
a class loader leak. A memory snapshot points to a ProtectionDomain
object held by a ForkJoinWorkerThread, the protection domain holds
On Mon, 4 Mar 2024 09:45:59 GMT, Serguei Spitsyn wrote:
>> On that note, note that the entire comment block preceding this needs to be
>> updated for virtual threads. And it is far from clear to me how to correctly
>> manage the interrupt state of virtual threads within the VM, when it
>>
Hi NZNOG,
The Program Committee is very happy to announce that the *AusNOG 2024 Call
For Papers is now open!*
We are looking for presentations that an audience working predominantly in
the network operating space will find interesting and useful. As always, we
do not accept marketing or sales
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 23:26:48 GMT, Serguei Spitsyn wrote:
> Please, review this fix correcting the JVMTI `RawMonitorWait()`
> implementation.
> The `RawMonitorWait()` is using the the `jt->is_interrupted(true)` to update
> the interrupt status of the interrupted waiting thread. The issue is
On Fri, 1 Mar 2024 15:13:49 GMT, Sean Coffey wrote:
> Proposal to improve the `java.security.debug` output so that options exist to
> add thread ID, thread name, source of log record and a timestamp information
> to the output.
>
> examples:
> format without patch :
>
>
> properties:
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 Thu, 29 Feb 2024 01:50:02 GMT, Alex Menkov wrote:
> Many NSK tests create socket channel for test/target interprocess
> communication.
> The change updates server side to listen only on loopback interface.
>
> Testing - all tests that use then functionality:
> -
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 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 Sun, 25 Feb 2024 14:20:54 GMT, Korov wrote:
> Make sun.net.www.MessageHeader final, and replace C-style array type
> declaration with Java-style array declaration.
The motivation for JDK-8325361 is to remove `@SuppressWarnings("this-escape")`
from the constructor.
-
PR
On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn wrote:
> This enhancement replaces uses of NULL with nullptr in the XML-description
> files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and
> `hotspot/share/prims/jvmti*.xls`.
>
> The following files are auto-generated from
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 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 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
Isha,
Wait, by "lefthand toolbox" are you referring to the process group's
toolbar start button or to the start button in the pallet at the upper
left of the page?
Please clarify.
Thanks
On 2/22/24 04:39, Isha Lamboo wrote:
always use the right-click context menu on a process group you
On Wed, 21 Feb 2024 10:28:49 GMT, Serguei Spitsyn wrote:
> The implementation of the JVM TI `GetCurrentContendedMonitor` does not match
> the spec. It can sometimes return an incorrect information about the
> contended monitor. Such a behavior does not match the function spec.
> With this
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 Wed, 21 Feb 2024 10:28:49 GMT, Serguei Spitsyn wrote:
> The implementation of the JVM TI `GetCurrentContendedMonitor` does not match
> the spec. It can sometimes return an incorrect information about the
> contended monitor. Such a behavior does not match the function spec.
> With this
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 Sat, 17 Feb 2024 02:30:03 GMT, Alex Menkov wrote:
> Can't the instance size as currently computed be computed by hprof tool
> vendors using class information already present in the hprof file (list of
> class fields and types, class hierarchy info, etc)?
That would still be based on VM
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
On Sun, 18 Feb 2024 10:56:03 GMT, Eirik Bjørsnøs wrote:
>> Please review this test-only cleanup PR in preparation for deprecating
>> `Deflater.getTotalOut()` in JDK-8326096.
>>
>> This PR replaces various calls
>> in`test/jdk/java/util/zip/DeflaterDictionaryTests.java` to
>>
On Mon, 19 Feb 2024 05:52:22 GMT, Varada M wrote:
> DeCapo Benchmark Results (3 runs) :
>
> Before :
> = DaCapo 9.12 h2 PASSED in 281402 msec =
> = DaCapo 9.12 h2 PASSED in 269818 msec =
> = DaCapo 9.12 h2 PASSED in 279279 msec =
>
> After:
> = DaCapo 9.12 h2
On Sun, 18 Feb 2024 14:56:03 GMT, Daniel D. Daugherty
wrote:
> Trivial fixes to ProblemList a couple of tests:
> [JDK-8326117](https://bugs.openjdk.org/browse/JDK-8326117) ProblemList
> serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default
> in Xcomp mode
On Sun, 18 Feb 2024 14:56:03 GMT, Daniel D. Daugherty
wrote:
> Trivial fixes to ProblemList a couple of tests:
> [JDK-8326117](https://bugs.openjdk.org/browse/JDK-8326117) ProblemList
> serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default
> in Xcomp mode
On Sat, 17 Feb 2024 13:00:08 GMT, Eirik Bjørsnøs wrote:
> Please review this test-only cleanup PR in preparation for deprecating
> `Deflater.getTotalOut()` in JDK-8326096.
>
> This PR replaces various calls
> in`test/jdk/java/util/zip/DeflaterDictionaryTests.java` to
>
On 16/02/2024 19:20, Eirik Bjørsnøs wrote:
Hi,
Initially, the Deflater and Inflater classes in java.util.zip only
supported up to 2GB of inflated or deflated data, the reason being
that their getTotalIn and getTotalOut methods returns an int.
Around 2004, this limitation was remedied by
On Fri, 16 Feb 2024 01:23:42 GMT, Alex Menkov wrote:
> When I proposed this change 10 years ago, there was a push back:
> https://bugs.openjdk.org/browse/JDK-8005604.
Right, the HPROF format was created to be independent of VM or any
configuration. So JDK-8176520 is not really a bug, instead
On 16/02/2024 09:23, Craig Raw wrote:
I have recently upgraded from Java 18 to Java 21, and noticed that
there has been a change in jpackage which is causing signtool (the
Microsoft code signing tool) to fail when signing the installer. Even
though the installer .exe can be run on the system,
On Thu, 15 Feb 2024 06:29:24 GMT, Christian Stein wrote:
>> Please review this PR that makes the launcher helper keep a reference to the
>> executable JAR file active after extracting the name of the main class and
>> returning it as Class instance. Now, when loading classes from the JAR file,
On Wed, 14 Feb 2024 15:42:48 GMT, Christian Stein wrote:
> `String jarname` is filled by the caller with the value of `String what`, and
> therefore contains the entire path to the executable JAR file. Using only
> `jarFile.getName()` will prevent any parent directories from being noted in
>
On Wed, 14 Feb 2024 15:49:01 GMT, Christian Stein wrote:
>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 596:
>>
>>> 594: String mainValue;
>>> 595: try {
>>> 596: Manifest manifest = jarFile.getManifest();
>>
>> I think the try-catch around the
On Wed, 14 Feb 2024 11:03:07 GMT, Christian Stein wrote:
> Please review this PR that makes the launcher helper keep a reference to the
> executable JAR file active after extracting the name of the main class and
> returning it as Class instance. Now, when loading classes from the JAR file,
>
Vote: yes
On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs wrote:
> 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906
Marked as reviewed by alanb (Reviewer).
This is for jdk22u, not jdk22
This is for jdk22u, not jdk22
-
PR Review:
On Tue, 13 Feb 2024 12:47:26 GMT, Roger Riggs wrote:
>> Correct the result string coder of a string encoded using a CharsetDecoder
>> with multi-byte encoded input.
>> Added tests for UTF16 strings and a regression test.
>
> Roger Riggs has updated the pull request incrementally with one
On Mon, 12 Feb 2024 21:29:02 GMT, Roger Riggs wrote:
> Correct the result string coder of a string encoded using a CharsetDecoder
> with multi-byte encoded input.
> Added tests for UTF16 strings and a regression test.
test/jdk/java/nio/file/Files/ReadWriteString.java line 322:
> 320:
On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Wed, 7 Feb 2024 12:37:23 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which updates the javadoc
>> of several classes in `java.util.jar` and `java.util.zip` to specify their
>> behaviour when `null` arguments are passed to the constructor or methods of
>>
On Wed, 7 Feb 2024 12:37:23 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which updates the javadoc
>> of several classes in `java.util.jar` and `java.util.zip` to specify their
>> behaviour when `null` arguments are passed to the constructor or methods of
>>
On Wed, 7 Feb 2024 11:14:06 GMT, Jaikiran Pai wrote:
>>> These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are
>>> slightly different from the rest of the classes in this changeset. This
>>> javadoc here is for the constructor of the `CheckedInputStream`. The
>>>
On Wed, 7 Feb 2024 11:14:06 GMT, Jaikiran Pai wrote:
>>> These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are
>>> slightly different from the rest of the classes in this changeset. This
>>> javadoc here is for the constructor of the `CheckedInputStream`. The
>>>
On Wed, 7 Feb 2024 10:13:00 GMT, Jaikiran Pai wrote:
> These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are
> slightly different from the rest of the classes in this changeset. This
> javadoc here is for the constructor of the `CheckedInputStream`. The
> implementation
On Wed, 7 Feb 2024 10:13:00 GMT, Jaikiran Pai wrote:
> These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are
> slightly different from the rest of the classes in this changeset. This
> javadoc here is for the constructor of the `CheckedInputStream`. The
> implementation
On Wed, 7 Feb 2024 01:52:06 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which updates the javadoc
>> of several classes in `java.util.jar` and `java.util.zip` to specify their
>> behaviour when `null` arguments are passed to the constructor or methods of
>>
On Wed, 7 Feb 2024 01:52:06 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which updates the javadoc
>> of several classes in `java.util.jar` and `java.util.zip` to specify their
>> behaviour when `null` arguments are passed to the constructor or methods of
>>
On Tue, 6 Feb 2024 12:30:10 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which updates the javadoc
>> of several classes in `java.util.jar` and `java.util.zip` to specify their
>> behaviour when `null` arguments are passed to the constructor or methods of
>>
On Tue, 6 Feb 2024 12:30:10 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which updates the javadoc
>> of several classes in `java.util.jar` and `java.util.zip` to specify their
>> behaviour when `null` arguments are passed to the constructor or methods of
>>
On Mon, 5 Feb 2024 20:11:43 GMT, Mandy Chung wrote:
> Trivial fix. Call `PrintWriter::format` with null `Locale` to format with no
> localization.
>
> This PR also fixes JDK-8325262 to print `FindException` message without the
> stack trace to indicate clearer that the given module path is
On Thu, 1 Feb 2024 12:55:39 GMT, Daniel Jeliński wrote:
> Please review this documentation change that:
> - removes networkcache.cache.*.ttl properties from the [System properties
> page](https://docs.oracle.com/en/java/javase/21/docs/api/system-properties.html)
> - Adds a link to the Security
On Wed, 31 Jan 2024 14:22:44 GMT, Kevin Walls wrote:
> Introduce the jcmd "VM.debug" to implement access to a useful set of the
> established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>
> Not recommended for live production use. Calling these "debug" utilities,
> and not
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the
On Fri, 2 Feb 2024 16:48:12 GMT, Brian Burkhalter wrote:
>> Modify the specification verbiage of `java.io.RandomAccessFile.setLength` to
>> account for the effect of the method on the file offset as returned by
>> `getFilePointer`.
>
> Brian Burkhalter has updated the pull request
On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request with
301 - 400 of 18095 matches
Mail list logo
