On Wed, 8 May 2024 08:19:54 GMT, Daniel Jeliński wrote:
> Replace the custom unsigned divide / remainder functions with the
> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>
> No new tests. Existing tier1-3 tests continue to pass.
>
> I added a new set of divide benchmarks. Resul
On Fri, 10 May 2024 16:16:18 GMT, Daniel Jeliński wrote:
>> Replace the custom unsigned divide / remainder functions with the
>> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>>
>> No new tests. Existing tier1-3 tests continue to pass.
>>
>> I added a new set of divide benchmarks
On Mon, 13 May 2024 09:56:35 GMT, Pavel Rappo wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git merg
On Mon, 13 May 2024 21:32:18 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one add
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Fri, 10 May 2024 16:16:18 GMT, Daniel Jeliński wrote:
>> Replace the custom unsigned divide / remainder functions with the
>> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>>
>> No new tests. Existing tier1-3 tests continue to pass.
>>
>> I added a new set of divide benchmarks
On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Thu, 9 May 2024 07:50:00 GMT, Julian Waters wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during the build. Currently, which gcc
> This change adds wrapping of the CancellationException produced by
> CompletableFuture::get() and CompletableFuture::join() to add more diagnostic
> information and align better with FutureTask.
>
> Running the sample code from the JBS issue in JShell will produce the
> following:
>
>
> jsh
On Mon, 13 May 2024 18:16:55 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line
>> 392:
>>
>>> 390: return null;
>>> 391: if (x instanceof CancellationException)
>>> 392: throw new CancellationExceptio
On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
Hello,
Class-File API has a convenient Signature model API, which can replace the
Generic Tree internal API in the current core reflection implementation.
The old internal Tree API + visitor pattern was bloated with a lot of
unnecessary classes, which can be removed with the new CF API.
A working
On Mon, 13 May 2024 17:06:32 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one add
> Making sure `restoreEcho` correctly reflects the state in the shutdown
> thread, which differs from the application's thread that issues the
> `readPassword()` method.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Addresses a revi
On Mon, 13 May 2024 17:06:32 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one add
On Sun, 12 May 2024 07:27:26 GMT, Alan Bateman wrote:
>> If an event class is loaded before JFR is started, the event class needs to
>> be retransformed, but if it is loaded later, we can add instrumentation on
>> class load and avoid the retransformation. More happens when an event class
>> i
> I added `@since` tags for methods/constructors that do not match the `@since`
> of the enclosing class.
>
> The `write` method already existed in `PrintStream` in earlier versions and
> instances of it could always call this method, since it extends
> `FilterOutputStream` [which has the
> me
> I added `@since` tags for methods/constructors that do not match the `@since`
> of the enclosing class.
>
> The `write` method already existed in `PrintStream` in earlier versions and
> instances of it could always call this method, since it extends
> `FilterOutputStream` [which has the
> me
> Please review this PR that aims to add all the remaining needed `@since` tags
> in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose
> of the
On Mon, May 13, 2024 at 12:16 PM Brent Christian
wrote:
> On 5/10/24 10:54 AM, Hans Boehm wrote:
> > I'm not convinced this helps.
> >
> > The isAlive() spec says:
> >
> > "A thread is alive if it has been started and has not yet terminated."
> >
> > Clearly an object is reachable if it can be ac
On Sun, 21 Apr 2024 22:00:52 GMT, Doug Simon wrote:
> This PR adds a check for the format of ProblemList files and ensures they
> only have entries referring to existing tests.
>
> The cleanups in the second commit of this PR were done based on the output of
> `CheckProblemLists`:
>
>> make t
On Wed, 24 Apr 2024 10:50:44 GMT, Doug Simon wrote:
>> This PR adds a check for the format of ProblemList files and ensures they
>> only have entries referring to existing tests.
>>
>> The cleanups in the second commit of this PR were done based on the output
>> of `CheckProblemLists`:
>>
>>>
On 5/10/24 10:54 AM, Hans Boehm wrote:
I'm not convinced this helps.
The isAlive() spec says:
"A thread is alive if it has been started and has not yet terminated."
Clearly an object is reachable if it can be accessed by a thread that will be started in the
future. Is that part of a "potentia
On Mon, 13 May 2024 18:00:27 GMT, Chen Liang wrote:
>> I don't want to merge or rebase on an active PR. It should get fixed once
>> this is integrated.
>
> Sure, this comment serves as a note to reviewers that these 2 header changes
> have been committed in other changes and thus can be safely
On Mon, 13 May 2024 17:06:10 GMT, Viktor Klang wrote:
>> This change adds wrapping of the CancellationException produced by
>> CompletableFuture::get() and CompletableFuture::join() to add more
>> diagnostic information and align better with FutureTask.
>>
>> Running the sample code from the J
On Mon, 13 May 2024 17:06:32 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one add
On Sun, 12 May 2024 18:52:30 GMT, Alan Bateman wrote:
> This mostly looks good. I'm just puzzled CHECK_EXCEPTION_NULL_FAIL. The JNI
> functions GetStaticMethodID, GetMethodID and NewObject return NULL with a
> pending exception when they fail. So I would expect CHECK_EXCEPTION_NULL_FAIL
> to j
On Mon, 13 May 2024 17:52:23 GMT, Chen Liang wrote:
>> Nizar Benalla has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - (C)
>> - (C)
>
> src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java line
> 2:
>
>> 1: /*
>> 2:
On Mon, 13 May 2024 17:57:42 GMT, Nizar Benalla wrote:
>> src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java line
>> 2:
>>
>>> 1: /*
>>> 2: * Copyright (c) 1998, 2023, Oracle and/or its affiliates. All rights
>>> reserved.
>>
>> This diff is redundant but no-op. You shou
On Mon, 13 May 2024 17:44:52 GMT, Nizar Benalla wrote:
>> Please review this PR that aims to add all the remaining needed `@since`
>> tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags are
> Please review this PR that aims to add all the remaining needed `@since` tags
> in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose
> of the
On Thu, 9 May 2024 10:11:22 GMT, Adam Sotona wrote:
>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
>> bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
>> additional class checks inspired by
>> `hotspot/s
On Mon, 13 May 2024 17:24:39 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java
>> line 205:
>>
>>> 203: private void verifyAttribute(AttributedElement ae, Attribute a,
>>> List errors) {
>>> 204: int payLoad = (
Hi,
With Stephen/Roger's comments, as well as Kevin's observation that
until(end) has a good argument ordering that is easy to understand, I'd
still propose `until()`. Please post if you have further comments.
Naoto
On 5/3/24 6:39 AM, Roger Riggs wrote:
Hi,
I would also reinforce Stephen's
On Mon, 13 May 2024 16:41:37 GMT, Viktor Klang wrote:
> This change adds wrapping of the CancellationException produced by
> CompletableFuture::get() and CompletableFuture::join() to add more diagnostic
> information and align better with FutureTask.
>
> Running the sample code from the JBS is
On Mon, 13 May 2024 17:15:15 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - fixed error thrown by VerifierImpl
>> - applied suggested changes
>
> src/java.base/share/classes/jdk/interna
On Thu, 9 May 2024 10:11:22 GMT, Adam Sotona wrote:
>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
>> bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
>> additional class checks inspired by
>> `hotspot/s
On Mon, 13 May 2024 17:06:32 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one add
On Mon, 13 May 2024 16:41:37 GMT, Viktor Klang wrote:
> This change adds wrapping of the CancellationException produced by
> CompletableFuture::get() and CompletableFuture::join() to add more diagnostic
> information and align better with FutureTask.
>
> Running the sample code from the JBS is
On Mon, 13 May 2024 17:06:32 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one add
On Mon, 13 May 2024 14:52:45 GMT, Daniel Fuchs wrote:
>> Fine with me.
>
> Not sure if that's an issue - but if you wanted/needed to delay the loading
> of those random generator classes that will not be used until something
> actually wants to use them, you could consider using a `Supplier ext
On Mon, 13 May 2024 17:03:00 GMT, Chen Liang wrote:
>> This change adds wrapping of the CancellationException produced by
>> CompletableFuture::get() and CompletableFuture::join() to add more
>> diagnostic information and align better with FutureTask.
>>
>> Running the sample code from the JBS
> Making sure `restoreEcho` correctly reflects the state in the shutdown
> thread, which differs from the application's thread that issues the
> `readPassword()` method.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Replaced another
On Fri, 12 Apr 2024 08:55:01 GMT, Viktor Klang wrote:
>> Keep-alive, maybe people like @viktorklang-ora might look at this simple fix
>> too
>
> @liach I'm not a Reviewer (yet) so I'll defer to someone like @stuart-marks :)
@viktorklang-ora Can you just leave an approval as a collections engine
> Making sure `restoreEcho` correctly reflects the state in the shutdown
> thread, which differs from the application's thread that issues the
> `readPassword()` method.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Update src/java.
On Mon, 13 May 2024 16:41:37 GMT, Viktor Klang wrote:
> This change adds wrapping of the CancellationException produced by
> CompletableFuture::get() and CompletableFuture::join() to add more diagnostic
> information and align better with FutureTask.
>
> Running the sample code from the JBS is
This change adds wrapping of the CancellationException produced by
CompletableFuture::get() and CompletableFuture::join() to add more diagnostic
information and align better with FutureTask.
Running the sample code from the JBS issue in JShell will produce the following:
jshell> java.util.conc
On Fri, 10 May 2024 00:19:32 GMT, Volodymyr Paprotski wrote:
>> Performance. Before:
>>
>> Benchmark(algorithm) (dataSize) (keyLength)
>> (provider) Mode Cnt ScoreError Units
>> SignatureBench.ECDSA.signSHA256withECDSA1024 256
On Wed, 24 Apr 2024 10:50:44 GMT, Doug Simon wrote:
>> This PR adds a check for the format of ProblemList files and ensures they
>> only have entries referring to existing tests.
>>
>> The cleanups in the second commit of this PR were done based on the output
>> of `CheckProblemLists`:
>>
>>>
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Wed, 8 Nov 2023 17:27:19 GMT, Lance Andersen wrote:
>> @LanceAndersen
>>
>> I noticed that this PR did not update `ZipInputStream.readLOC` to perform
>> consistency validation between expected and actual extra field size and
>> values. Any particular reason why processing of LOC headers wa
On Mon, 13 May 2024 13:21:23 GMT, Raffaello Giulietti
wrote:
>> A followup PR is fine. I think once this PR which addresses the API aspects
>> (like removal of ServiceLoader and then updates to the create() method
>> javadoc) is integrated, then the subsequent PR can just be all internal
>> i
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Mon, 13 May 2024 14:08:01 GMT, Jaikiran Pai wrote:
>> Then I would even remove the double-checking idiom, the `volatile` on `ctor`
>> and `properties`, and declare methods `getProperties()` and
>> `ensureConstructors()` as `synchronized`.
>> I'm not sure that the double-checking optimization
On Mon, 13 May 2024 13:54:18 GMT, Raffaello Giulietti
wrote:
> Then I would even remove the double-checking idiom, the volatile on ctor and
> properties, and declare methods getProperties() and ensureConstructors() as
> synchronized.
> I'm not sure that the double-checking optimization brings
On Mon, 13 May 2024 13:41:50 GMT, Jaikiran Pai wrote:
>> All random number generator algorithms are implemented in module
>> `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory`
>> is no longer needed.
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactor
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Mon, 13 May 2024 08:47:50 GMT, Raffaello Giulietti
wrote:
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
src/java.base/share/classes/java/util/random/RandomGeneratorFact
On Mon, 13 May 2024 08:47:50 GMT, Raffaello Giulietti
wrote:
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
src/java.base/share/classes/java/util/random/RandomGeneratorFact
On Mon, 13 May 2024 13:18:24 GMT, Jaikiran Pai wrote:
>> @jaikiran I agree that we can simplify even more. I just wanted to change as
>> little as possible in this PR to facilitate reviews.
>> Shall I push your proposed changes in this PR or is a followup PR preferable?
>
> A followup PR is fine
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Mon, 13 May 2024 13:14:57 GMT, Raffaello Giulietti
wrote:
>> Thinking a bit more, I think we can even get rid of the reflection used in
>> `create()` methods implementation, if we wanted to, by doing something like
>> this:
>>
>>
>> private record RandomGenEntry(Class
>> randomGenClass,
On Mon, 13 May 2024 13:06:04 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java
>> line 190:
>>
>>> 188: if (properties == null) { // double-checking idiom
>>> 189: RandomGeneratorProperties props =
>>> rgCl
On Mon, 13 May 2024 12:45:59 GMT, Jaikiran Pai wrote:
>> All random number generator algorithms are implemented in module
>> `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory`
>> is no longer needed.
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactor
On Thu, 9 May 2024 08:18:41 GMT, David Holmes wrote:
>> Please review this mechanical change to man pages. This PR should be
>> integrated after https://github.com/openjdk/jdk/pull/18787.
>
> src/java.base/share/man/java.1 line 3856:
>
>> 3854: .SH REMOVED JAVA OPTIONS
>> 3855: .PP
>> 3856: The
On Mon, 13 May 2024 08:47:50 GMT, Raffaello Giulietti
wrote:
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
src/java.base/share/classes/java/util/random/RandomGeneratorFact
On Mon, 13 May 2024 07:51:19 GMT, Adam Sotona wrote:
>> src/java.base/share/classes/java/lang/classfile/Attributes.java line 153:
>>
>>> 151:
>>> 152: /**
>>> 153: * {@return Attribute mapper for the {@code AnnotationDefault}
>>> attribute}
>>
>> Just wondering, can we change `{@code
> Consider this layout:
>
>
> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
> MemoryLayout.sequenceLayout(10, JAVA_INT));
>
>
> And the corresponding offset handle:
>
>
> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(),
> PathElement.sequenceLayout(
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
> the use of JNI in the following ways:
>
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` metho
On Mon, 13 May 2024 11:38:40 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
> the use of JNI in the following ways:
>
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` metho
On Sun, 12 May 2024 19:46:42 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review comments
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1242:
>
>> 1240:
This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the
use of JNI in the following ways:
* `System::load` and `System::loadLibrary` are now restricted methods
* `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
* binding a JNI `native` method declaratio
On Mon, 13 May 2024 10:42:26 GMT, Maurizio Cimadamore
wrote:
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
> the use of JNI in the following ways:
>
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibr
On Mon, 13 May 2024 10:30:43 GMT, Per Minborg wrote:
> Some of the deprecated methods are very likely to be run in hot loops (e.g.
> read/store operations). Unless we set
> `--sun-misc-unsafe-memory-access=allow`, what would be the performance impact
> on various platforms for these operations
On Fri, 10 May 2024 21:55:26 GMT, Naoto Sato wrote:
> Making sure `restoreEcho` correctly reflects the state in the shutdown
> thread, which differs from the application's thread that issues the
> `readPassword()` method.
Generally looks good.
It's hard to imagine that this shutdown hook migh
On Fri, 10 May 2024 16:41:28 GMT, Naoto Sato wrote:
>> When implementing, I asked myself if I must use any of those monitors and
>> decided that I don't have to. My reasoning is below.
>>
>> `readLock`:
>>
>> - is used inside the object that `Reader reader` is initialised with, and
>>
>> - it
On Mon, 13 May 2024 09:56:35 GMT, Pavel Rappo wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git merg
On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman wrote:
> This is the implementation changes for JEP 471.
>
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated
> for removal. This means a removal warning at compile time. No methods have
> been removed. A deprecated me
On Sun, 12 May 2024 02:42:32 GMT, Chen Liang wrote:
>> Summary of the changes:
>> - Moved `com.sun.tools.classfile.Dependency` and `Dependencies` to jdeps;
>> they are exclusively used by jdeps in sources, and they are not used in any
>> tests too. This will ease the removal of `com.sun.tools.
On Thu, 9 May 2024 18:44:10 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.
>>
>
> Please review this PR which introduces the `java.io.IO` top-level class and
> three methods to `java.io.Console` for [Implicitly Declared Classes and
> Instance Main Methods (Third Preview)].
>
> This PR has been obtained as `git merge --squash` of a now obsolete [draft
> PR].
>
> [Implicitl
On Fri, 10 May 2024 00:45:31 GMT, Chen Liang wrote:
> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's
> LambdaForm method type parameters. Since they are distinct from those of
> Linkers, they are now tracked and generated separately. It seems that no
> proper invoke
On Mon, 13 May 2024 08:47:50 GMT, Raffaello Giulietti
wrote:
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
This is a followup of [18932](https://github.com/openjdk/jdk/pul
All random number generator algorithms are implemented in module `java.base`.
The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
needed.
-
Commit messages:
- 8332086: Remove the usage of ServiceLoader in j.u.r.RandomGeneratorFactory
Changes: https://git.op
I was thinking of zip api’s other than java’s. The field needs to be at a fixed
place in the file format whatever the name? Unless a significant api change has
been made.
A couple of links from googling on “zip extra field chaining"
https://libzip.org/specifications/extrafld.txt
https://www.hac
The OpenJDK net-dev mailing list is the best place to bring this. There
was discussion about SOCKS when the HTTP client was developed, I thought
JEP 321 had a summary on this but it seems not. I'm sure others on
net-dev can say more on this.
-Alan
On 12/05/2024 22:58, Alessandro Autiero wr
On Fri, 3 May 2024 10:11:02 GMT, Jan Lahoda wrote:
> When JLine reads a line, there may be a prompt provided. However, JLine will
> not interpret the prompt literally, it will handle `%` specially. As a
> consequence, doing:
>
> System.console().readLine("%%s");
>
>
> will not print `%s`, as
On Sun, 12 May 2024 15:11:17 GMT, Chen Liang wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed tests
>
> src/java.base/share/classes/java/lang/classfile/Attributes.java line 153:
>
>> 151:
>> 152: /**
>> 1
On Mon, 13 May 2024 06:58:42 GMT, Per Minborg wrote:
> Would it make sense to add some verbiage in the JavaDocs for
> `sun.misc.Unsafe` that indicates the planned direction for said class and the
> use of the new command line options?
There is an API note to say that the class predates VarHand
> Hi,
>
> Could I have a review of a change that moves the jdk.FileRead and
> jdk.FileWrite events to java.base to remove the use of the ASM
> instrumentation.
>
> Testing: jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated the pull request incrementally with three additional
commits sinc
On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman wrote:
> This is the implementation changes for JEP 471.
>
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated
> for removal. This means a removal warning at compile time. No methods have
> been removed. A deprecated me
On Fri, 10 May 2024 13:24:53 GMT, Chen Liang wrote:
>> This is the implementation changes for JEP 471.
>>
>> The methods in sun.misc.Unsafe for on-heap and off-heap access are
>> deprecated for removal. This means a removal warning at compile time. No
>> methods have been removed. A deprecated
94 matches
Mail list logo
