Hi Aman,
I think you meant CVE-2021-42392 instead of 2022.
For your approach of an "allowlist" for Java runtime, project Leyden is
looking to generate a static image [1], that
> At run time it cannot load classes from outside the image, nor can it
create classes dynamically.
Leyden mainly avoids
On Thu, 16 May 2024 02:37:02 GMT, Ioi Lam wrote:
> JavacBench is a test program that compiles 90 Java source files. It uses a
> fair amount of invokedynamic callsites, so it's good for testing CDS support
> for indy and lambda expressions.
>
> This test was first integrated into the
>
JavacBench is a test program that compiles 90 Java source files. It uses a fair
amount of invokedynamic callsites, so it's good for testing CDS support for
indy and lambda expressions.
This test was first integrated into the
[leyden](https://github.com/openjdk/leyden/tree/premain) repo. Hence
Indeed, ReflectionFactory. newConstructorForSerialization can be used to
access otherwise-private constructors. Before JDK-8315810, it could even
allocate one class and call the constructor of another class.
I strongly support your proposal to restrict ReflectionFactory.
Regards, Chen
On Wed,
On Fri, 10 May 2024 01:25:45 GMT, xiaotaonan wrote:
>> Clean up non-standard use of /// comments in `java.base`
>
> @mdinacci @hns @landonf
Hello @xiaotaonan, like Jon noted in his comment, there's already another PR
addressing this change. So I think this current PR can be closed.
If you forget to implement RandomAccess, you'll get a very subtle
performance bug.
Just because it's easy if you know how to do it doesn't make it easy for a
random developer to do correctly.
On Wed, May 15, 2024 at 3:21 PM Mateusz Romanowski <
romanowski.mate...@gmail.com> wrote:
> Hi,
> I
Hi,
I would say it is not worth any effort.
One can easily write an ad-hoc *local* adapter extending
`java.util.AbstractList`..
.. and immediately invoke existing `java.util.Collections::binarySearch`
method.
Cheers,
MR
On Thu, Apr 25, 2024 at 9:09 PM Pavel Rappo wrote:
>
>
> > On 25 Apr
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 Tue, May 14, 2024 at 10:01 AM David Lloyd wrote:
> (Moving to core-libs-dev)
>
> On Tue, May 14, 2024 at 9:40 AM Alan Bateman
> wrote:
>
>> On 14/05/2024 14:42, David Lloyd wrote:
>>
>> ReflectionFactory allows access to serialization facilities without any
>> access checking (other than the
On Wed, 15 May 2024 19:21:37 GMT, Volodymyr Paprotski wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rearrange; add lambdas for clarity
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 47:
>
>> 45:
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 Tue, 23 Apr 2024 20:35:43 GMT, Naoto Sato wrote:
> Proposing new overloaded methods in `java.io.Console` class that explicitly
> take a `Locale` argument. Existing methods rely on the default locale, so the
> users won't be able to format their prompts/outputs in a certain locale
>
On Wed, 15 May 2024 18:49:49 GMT, ExE Boss wrote:
>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java
>> line 240:
>>
>>> 238: }
>>> 239: } finally {
>>> 240: supplying = false;
>>
>> Resetting a stable field is a bad idea.
On Wed, 15 May 2024 16:10:06 GMT, Chen Liang wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Switch to monomorphic StableValue and use lazy arrays
>
>
On Wed, 15 May 2024 15:27:34 GMT, Per Minborg wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable
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
On Wed, 15 May 2024 17:05:17 GMT, Naoto Sato wrote:
>> Proposing new overloaded methods in `java.io.Console` class that explicitly
>> take a `Locale` argument. Existing methods rely on the default locale, so
>> the users won't be able to format their prompts/outputs in a certain locale
>>
> Proposing new overloaded methods in `java.io.Console` class that explicitly
> take a `Locale` argument. Existing methods rely on the default locale, so the
> users won't be able to format their prompts/outputs in a certain locale
> explicitly.
Naoto Sato has updated the pull request
On Wed, 15 May 2024 15:27:34 GMT, Per Minborg wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable
On Mon, 6 May 2024 19:31:43 GMT, Per Minborg wrote:
>> src/java.base/share/classes/jdk/internal/lang/StableArray.java line 25:
>>
>>> 23: * @since 23
>>> 24: */
>>> 25: public sealed interface StableArray
>>
>> Do we have a use case for StableArray beyond those of StableList?
>
> I am trying
On Tue, 14 May 2024 13:18:51 GMT, Adam Sotona wrote:
> Class file with `LineNumberTable` attribute element pointing behind the
> bytecode array throws `ArrayIndexOutOfBoundsException`.
> This patch performs the check and throws expected `IllegalArgumentException`
> instead.
> Relevant test is
> Proposing new overloaded methods in `java.io.Console` class that explicitly
> take a `Locale` argument. Existing methods rely on the default locale, so the
> users won't be able to format their prompts/outputs in a certain locale
> explicitly.
Naoto Sato has updated the pull request
> 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`
On Wed, 15 May 2024 07:51:33 GMT, Adam Sotona wrote:
>> Class file with `LineNumberTable` attribute element pointing behind the
>> bytecode array throws `ArrayIndexOutOfBoundsException`.
>> This patch performs the check and throws expected
>> `IllegalArgumentException` instead.
>> Relevant
On Wed, 15 May 2024 10:40:34 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
On Wed, 15 May 2024 15:20:58 GMT, Per Minborg wrote:
>> At some point in the future, 'jdk.unsupported' will be removed
>
> Maybe there is a better home for this?
I don't think we should publish this API; this will soon be phased out by
strict final fields (written only before super constructor
On Tue, 14 May 2024 11:12:39 GMT, Per Minborg wrote:
>> src/hotspot/share/ci/ciField.cpp line 262:
>>
>>> 260: const char* stable_array3d_klass_name =
>>> "jdk/internal/lang/StableArray3D";
>>> 261:
>>> 262: static bool trust_final_non_static_fields_of_type(Symbol* signature) {
>>
>> Is
On Wed, 15 May 2024 15:27:34 GMT, Per Minborg wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable
On Wed, 15 May 2024 08:53:32 GMT, ExE Boss wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revise docs for ofBackground()
>
> src/java.base/share/classes/jdk/internal/lang/StableValue.java line 1:
>
>> 1: /*
>
>
> # Stable Values & Collections (Internal)
>
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API,
> which provides immutable value holders where elements are initialized _at
> most once_. Stable Values & Collections offer the performance and safety
>
On Wed, 15 May 2024 12:26:34 GMT, Rémi Forax wrote:
>> Given that `TrustedFieldType` is more generic than stable values, it could
>> be moved to `jdk.internal.misc` or `jdk.internal.reflect`, then
>> `jdk.unsupported` could use it without exporting new packages to
>> `jdk.unsupported`.
>
> At
On Thu, 9 May 2024 15:00:35 GMT, Maurizio Cimadamore
wrote:
> Consider this layout:
>
>
> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
> MemoryLayout.sequenceLayout(10, JAVA_INT));
>
>
> And the corresponding offset handle:
>
>
> MethodHandle offsetHandle =
On Wed, 15 May 2024 11:17:42 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewhere in
>> java.base, such as
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
On Wed, 15 May 2024 11:55:39 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
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
On Wed, 15 May 2024 10:18:11 GMT, Maurizio Cimadamore
wrote:
> The FFM code throws if an unknown value is passed. Here we log. Should we try
> to be more consistent?
I don't have a strong opinion on this. The value of --illegal-native-access is
examined during startup so startup can fail if
On Wed, 15 May 2024 11:27:04 GMT, ExE Boss wrote:
>>> Maybe export this interface to `jdk.unsupported`?
>>
>> I don't we should do that. In general, we need jdk.unsupported to go away in
>> the long term. Also integrity of the platform depends on java.base being
>> very stingy and not
> 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 find Java SE Runtime Environment.
> ]
> exitValue = 2
>
>
> Please review this patch which adds a jlink mode to the JDK which doesn't
> need the packaged modules being present. A.k.a run-time image based jlink.
> Fundamentally this patch adds an option to use `jlink` even though your JDK
> install might not come with the packaged modules (directory
On Wed, 15 May 2024 11:40:38 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 Wed, 15 May 2024 07:16:37 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 226:
>>
>>> 224: for (int i = 0; i < rank; i++) {
>>> 225: sb.append('[');
>>> 226: }
>>
>> Would `sb.repeat("[", rank);` be better here?
>>
> 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 find Java SE Runtime Environment.
> ]
> exitValue = 2
>
>
On Wed, 15 May 2024 10:47:23 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
>>
On Wed, 15 May 2024 10:43:52 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/jdk/internal/lang/stable/TrustedFieldType.java
>> line 14:
>>
>>> 12: * operations.
>>> 13: */
>>> 14: public sealed interface TrustedFieldType
>>
>> Maybe export this interface to `jdk.unsupported`?
>
>>
On Wed, 15 May 2024 07:51:33 GMT, Adam Sotona wrote:
>> Class file with `LineNumberTable` attribute element pointing behind the
>> bytecode array throws `ArrayIndexOutOfBoundsException`.
>> This patch performs the check and throws expected
>> `IllegalArgumentException` instead.
>> Relevant
> This PR suggests refactoring the implementation classes of java.lang.constant
> into a new package jdk.internal.constant to enable sharing some trusted
> static factory methods with users elsewhere in java.base, such as
> java.lang.invoke and java.lang.classfile. The refactoring also adds
On Wed, 15 May 2024 10:55:31 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewhere in
>> java.base, such as
On Wed, 15 May 2024 07:20:37 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewhere in
>> java.base, such as
On Wed, 15 May 2024 10:34:01 GMT, Maurizio Cimadamore
wrote:
> I don't fully agree that this option is not module related (which is why I
> gave it that name). The very definition of illegal native access is related
> to native access occurring from a module that is outside a specific set. So
> This PR suggests refactoring the implementation classes of java.lang.constant
> into a new package jdk.internal.constant to enable sharing some trusted
> static factory methods with users elsewhere in java.base, such as
> java.lang.invoke and java.lang.classfile. The refactoring also adds
On Wed, 15 May 2024 10:06:42 GMT, Adam Sotona 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 size = -1;
>>> 205:
On Wed, 15 May 2024 09:45:24 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> applied the suggested changes
>
>
> 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/share/classfile/classFileParser.cpp`.
>
> Also new
On Wed, 15 May 2024 08:49:46 GMT, ExE Boss wrote:
> Maybe export this interface to `jdk.unsupported`?
I don't we should do that. In general, we need jdk.unsupported to go away in
the long term. Also integrity of the platform depends on java.base being very
stingy and not exporting internal
> 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`
On Wed, 15 May 2024 06:15:35 GMT, Alan Bateman wrote:
>> So my recollection/understanding is that we use this mechanism to convert
>> module-related `--` flags passed to the VM into system properties that the
>> Java code can then read, but we set them up such that you are not allowed to
>>
On Wed, 15 May 2024 09:51:13 GMT, Adam Sotona wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use sb.repeat, consolidate
>
> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 341:
>
>> 339:
> This PR suggests refactoring the implementation classes of java.lang.constant
> into a new package jdk.internal.constant to enable sharing some trusted
> static factory methods with users elsewhere in java.base, such as
> java.lang.invoke and java.lang.classfile. The refactoring also adds
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 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
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
On Wed, 15 May 2024 09:43:04 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> applied the suggested changes
>
>
On Wed, 15 May 2024 07:55:27 GMT, ExE Boss wrote:
> Note that this line is still not entirely correct, as for code like:
You are correct - the message is however consistent with what written in JEP
472. I'll discuss with @pron
-
PR Review Comment:
On Wed, 15 May 2024 07:20:37 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewhere in
>> java.base, such as
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Small
> Please review this patch which adds a jlink mode to the JDK which doesn't
> need the packaged modules being present. A.k.a run-time image based jlink.
> Fundamentally this patch adds an option to use `jlink` even though your JDK
> install might not come with the packaged modules (directory
On Wed, 8 May 2024 22:36:51 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 105 commits:
>>
>> - Generate the runtime image link diff at jlink time
>>
>>But only do that
On Mon, 13 May 2024 23:59:17 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
On Tue, 14 May 2024 11:42:19 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
>>
Add specific regression tests for Calendar.roll() method to explicitly various
leap year test scenarios. This is inspired by the ambiguity which occurred in
leap year unaware test creation as in case with Calendar.add() in swing
component test case as detailed in
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 Wed, 15 May 2024 07:48:42 GMT, Per Minborg wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable
On Tue, 14 May 2024 18:10:28 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
On Tue, 14 May 2024 15:59:33 GMT, Paul Sandoz wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed exception message
>
> src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java line
> 241:
>
>>
> Class file with `LineNumberTable` attribute element pointing behind the
> bytecode array throws `ArrayIndexOutOfBoundsException`.
> This patch performs the check and throws expected `IllegalArgumentException`
> instead.
> Relevant test is added.
>
> Please review.
>
> Thanks,
> Adam
Adam
> # Stable Values & Collections (Internal)
>
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API,
> which provides immutable value holders where elements are initialized _at
> most once_. Stable Values & Collections offer the performance and safety
>
> # Stable Values & Collections (Internal)
>
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API,
> which provides immutable value holders where elements are initialized _at
> most once_. Stable Values & Collections offer the performance and safety
>
> This PR suggests refactoring the implementation classes of java.lang.constant
> into a new package jdk.internal.constant to enable sharing some trusted
> static factory methods with users elsewhere in java.base, such as
> java.lang.invoke and java.lang.classfile. The refactoring also adds
On Tue, 14 May 2024 20:20:59 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add microbenchmark for ClassDesc methods + a few optimizations
>
>
On Tue, 14 May 2024 16:02:41 GMT, Viktor Klang wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove text in public class that references an internal class
>
>
On Tue, 14 May 2024 16:08:22 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.
>
> Raffaello Giulietti has updated the pull request
On Wed, 15 May 2024 06:30:35 GMT, Jaikiran Pai wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Replace SimpleImmutableEntry constructor with Map.entry() factory method.
>
>
On Tue, 14 May 2024 16:08:22 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.
>
> Raffaello Giulietti has updated the pull request
On Wed, 15 May 2024 00:54:43 GMT, David Holmes wrote:
>> src/hotspot/share/runtime/arguments.cpp line 2271:
>>
>>> 2269: } else if (match_option(option, "--illegal-native-access=",
>>> )) {
>>> 2270: if (!create_module_property("jdk.module.illegal.native.access",
>>> tail,
85 matches
Mail list logo
