On Mon, 13 Jun 2022 17:01:48 GMT, Alexander Matveev
wrote:
> - Error will be thrown if app image is generated with another JDK version or
> has malformed .jpackage.xml.
> - Re-fixed as Alexey suggested in https://github.com/openjdk/jdk/pull/9098.
On Mon, 13 Jun 2022 17:01:48 GMT, Alexander Matveev
wrote:
> - Error will be thrown if app image is generated with another JDK version or
> has malformed .jpackage.xml.
> - Re-fixed as Alexey suggested in https://github.com/openjdk/jdk/pull/9098.
On Tue, 14 Jun 2022 15:16:27 GMT, Claes Redestad wrote:
> Avoid doing MH creation when initializing `StringConcatFactory` by lazily
> initializing to a `@Stable` field instead.
Marked as reviewed by mchung (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/9154
On Wed, 8 Jun 2022 22:07:38 GMT, liach wrote:
>> Paul Sandoz has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Let java.management participate in preview features.
>
> Just curious, is it still up to incubator modules' discretion to avoid
Update the code examples in the api notes of Long::compress/expand. Some
constants need to be explicitly long values.
-
Commit messages:
- Correct Long.compress/expand api notes.
Changes: https://git.openjdk.org/jdk19/pull/14/files
Webrev:
On Tue, 14 Jun 2022 16:28:37 GMT, Paul Sandoz wrote:
> Update the code examples in the api notes of Long::compress/expand. Some
> constants need to be explicitly long values.
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.org/jdk19/pull/14
On Tue, 14 Jun 2022 15:16:27 GMT, Claes Redestad wrote:
> Avoid doing MH creation when initializing `StringConcatFactory` by lazily
> initializing to a `@Stable` field instead.
Marked as reviewed by jvernee (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/9154
On Wed, 8 Jun 2022 15:46:24 GMT, Paul Sandoz wrote:
> Allow JDK modules that use preview features (preview language features or
> preview API features from dependent modules) to participate without the need
> to compile with `--enable-preview`.
>
> It's difficult to enable participation using
ti 14.6.2022 klo 18.49 Rodion Efremov kirjoitti:
> Hi community,
>
> > One use case I've had in the past was for a list that is
> always sorted but also allows index based access when displaying a
> window into the list.
>
> I suppose you are talking about an order statistic tree. If that is the
Avoid doing MH creation when initializing `StringConcatFactory` by lazily
initializing to a `@Stable` field instead.
-
Commit messages:
- 8288425: Footprint regression due MH creation when initializing
StringConcatFactory
Changes: https://git.openjdk.org/jdk/pull/9154/files
On Tue, 14 Jun 2022 02:32:54 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>>
On Tue, 14 Jun 2022 02:32:54 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>>
On Thu, 12 May 2022 12:14:49 GMT, Ludovic Henry wrote:
>> Despite the hash value being cached for Strings, computing the hash still
>> represents a significant CPU usage for applications handling lots of text.
>>
>> Even though it would be generally better to do it through an enhancement to
On Tue, 14 Jun 2022 12:18:52 GMT, Matthias Baesken wrote:
>> When trying to construct an LdapURL object with a bad input string (in this
>> example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we
>> run into the
On Tue, 14 Jun 2022 12:18:52 GMT, Matthias Baesken wrote:
>> When trying to construct an LdapURL object with a bad input string (in this
>> example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we
>> run into the
On Sat, 11 Jun 2022 15:42:34 GMT, Alan Bateman wrote:
> JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change
> GetVersion to return this version.
>
> test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that
> JNI_VERSION_19 is returned. The native library
> When trying to construct an LdapURL object with a bad input string (in this
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run
> into the exception below :
>
> import com.sun.jndi.ldap.LdapURL;
>
>
On 14/06/2022 10:44, Andrey Turbanov wrote:
Hello.
During investigation of signal handling in JVM (for
https://github.com/openjdk/jdk/pull/9100#discussion_r894992558 )
I found out that sending USR2 crashes my JDK. (Linux fastdebug x64)
kill -USR2 1346792
# assert(thread != __null) failed:
The change does not seem to be related to your description, and the description
does not match the shown exception. In fact the example stacktrace contains the
authority value twice and your change adds a diagnostic which is not really
helpful for the case of the underscore? I would not be too
On Tue, 14 Jun 2022 11:36:36 GMT, Matthias Baesken wrote:
>> When trying to construct an LdapURL object with a bad input string (in this
>> example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we
>> run into the
On Tue, 14 Jun 2022 10:43:54 GMT, Matthias Baesken wrote:
>> When trying to construct an LdapURL object with a bad input string (in this
>> example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we
>> run into the
> When trying to construct an LdapURL object with a bad input string (in this
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run
> into the exception below :
>
> import com.sun.jndi.ldap.LdapURL;
>
>
On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken wrote:
> We still handle at a number of places ancient historic _MSC_VER versions of
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't
> want to
On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken wrote:
> When trying to construct an LdapURL object with a bad input string (in this
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run
> into the
> When trying to construct an LdapURL object with a bad input string (in this
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run
> into the exception below :
>
> import com.sun.jndi.ldap.LdapURL;
>
>
Hello.
During investigation of signal handling in JVM (for
https://github.com/openjdk/jdk/pull/9100#discussion_r894992558 )
I found out that sending USR2 crashes my JDK. (Linux fastdebug x64)
kill -USR2 1346792
# assert(thread != __null) failed: Missing current thread in SR_handler
# Internal
On Wed, 8 Jun 2022 13:12:09 GMT, Raffaello Giulietti
wrote:
> These 19'545 doubles were generated on purpose by Paul Zimmermann of INRIA as
> hard test cases.
Many of the test cases failed before
[PR3402](https://github.com/openjdk/jdk/pull/3402), so it's worth having them
in the codebase
On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken wrote:
>> We still handle at a number of places ancient historic _MSC_VER versions of
>> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't
>> want
On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken wrote:
>> We still handle at a number of places ancient historic _MSC_VER versions of
>> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't
>> want
> Please review this PR.
> SDK 10.15 and earlier reports os.version as 10.16 on Big Sur. This fix will
> check if dynamic linker support, which is supported from Big Sur, is
> available or not on the OS even if os.version is reported as 10.16 instead of
> 11. The os.version 10.16 doesn't
On Fri, 10 Jun 2022 17:51:37 GMT, Mandy Chung wrote:
>> Please review this PR.
>> SDK 10.15 and earlier reports os.version as 10.16 on Big Sur. This fix will
>> check if dynamic linker support, which is supported from Big Sur, is
>> available or not on the OS even if os.version is reported as
> This is an early review of changes to better model JVM access flags, that is
> "modifiers" like public, protected, etc. but explicitly at a VM level.
>
> Language level modifiers and JVM level access flags are closely related, but
> distinct. There are concepts that overlap in the two domains
On Wed, 1 Jun 2022 05:09:42 GMT, ExE Boss wrote:
>> Or `AbstractMethodError`, which is what `Executable::getParameterCount()`
>> does:
>> https://github.com/openjdk/jdk/blob/e751b7b1b6f7269a1fe20c07748c726536388f6d/src/java.base/share/classes/java/lang/reflect/Executable.java#L248-L258
>
>
On Tue, 14 Jun 2022 01:40:53 GMT, liach wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make mask fields final in ModuleDescriptor.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 300:
>
>>
On Tue, 31 May 2022 17:23:18 GMT, Rémi Forax wrote:
>> For completeness, I think including SUPER is reasonable, even though has
>> been a no-op for some time. (Some time in the future, there could be a class
>> file version aware additions to this enum class.) Well spotted omission.
>
>
On Tue, 14 Jun 2022 01:25:02 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>>
> This is an early review of changes to better model JVM access flags, that is
> "modifiers" like public, protected, etc. but explicitly at a VM level.
>
> Language level modifiers and JVM level access flags are closely related, but
> distinct. There are concepts that overlap in the two domains
On Tue, 31 May 2022 17:20:08 GMT, Rémi Forax wrote:
>> Joe Darcy 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 contains 32 additional commits
>> since
On Tue, 14 Jun 2022 00:56:47 GMT, Naoto Sato wrote:
> Backing out a fix that is causing a T1 failure.
>
> This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.
This pull request has now been integrated.
Changeset: fbe92666
Author:Naoto Sato
URL:
Backing out a fix that is causing a T1 failure.
This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.
-
Commit messages:
- 8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ
env variable
Changes: https://git.openjdk.org/jdk/pull/9151/files
On Tue, 14 Jun 2022 00:56:47 GMT, Naoto Sato wrote:
> Backing out a fix that is causing a T1 failure.
>
> This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.
Backout looks accurate - thanks.
-
Marked as reviewed by dholmes (Reviewer).
PR:
> This is an early review of changes to better model JVM access flags, that is
> "modifiers" like public, protected, etc. but explicitly at a VM level.
>
> Language level modifiers and JVM level access flags are closely related, but
> distinct. There are concepts that overlap in the two domains
On Wed, 13 Apr 2022 21:21:25 GMT, liach wrote:
>> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 167:
>>
>>> 165: * but is optional in the dynamic phase, during execution.
>>> 166: */
>>> 167: STATIC(AccessFlag.STATIC.mask()),
>>
> This is an early review of changes to better model JVM access flags, that is
> "modifiers" like public, protected, etc. but explicitly at a VM level.
>
> Language level modifiers and JVM level access flags are closely related, but
> distinct. There are concepts that overlap in the two domains
On Tue, 15 Feb 2022 09:06:02 GMT, ExE Boss wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Respond to more review feedback.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 163:
>
>> 161: *
> Allow JDK modules that use preview features (preview language features or
> preview API features from dependent modules) to participate without the need
> to compile with `--enable-preview`.
>
> It's difficult to enable participation using an annotation due to the nature
> in which symbols
On Mon, 13 Jun 2022 14:29:44 GMT, Jaikiran Pai wrote:
> > Hi Daniel, should we maybe better print something like "check for not
> > allowed characters" in the exception ? Do you have an easy and cheap way in
> > mind to the get the unsupported character (in this case "_") to add it to
> > the
On Mon, 13 Jun 2022 07:26:32 GMT, Matthias Baesken wrote:
> Hi Daniel, should we maybe better print something like "check for not allowed
> characters" in the exception ? Do you have an easy and cheap way in mind to
> the get the unsupported character (in this case "_") to add it to the output
JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change
GetVersion to return this version.
test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that
JNI_VERSION_19 is returned. The native library in the JMX agent, and several
tests, define JNI_OnLoad that
I took a look.
I found a few results odd:
|com.github.coderodde.util.IndexedLinkedList.addLast in (ms): 8
java.util.LinkedList.addLast in (ms): 2 java.util.ArrayList.addLast in
(ms): 157 org.apache.commons.collections4.list.TreeList.addLast in (ms): 38|
Basically, ArrayList's performance
> We still handle at a number of places ancient historic _MSC_VER versions of
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't
> want to adjust.
>
> Currently still supported ("valid") VS version
On Mon, 13 Jun 2022 10:33:24 GMT, Andrey Turbanov wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> use round directly
>
> src/hotspot/share/adlc/main.cpp line 491:
>
>> 489: }
>> 490:
>> 491: // VS2005 has
On Mon, 13 Jun 2022 07:24:52 GMT, Matthias Baesken wrote:
>> We still handle at a number of places ancient historic _MSC_VER versions of
>> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't
>> want
On Mon, 13 Jun 2022 07:24:52 GMT, Matthias Baesken wrote:
>> We still handle at a number of places ancient historic _MSC_VER versions of
>> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't
>> want
On Wed, 8 Jun 2022 12:09:27 GMT, Severin Gehwolf wrote:
>> Please review this cleanup change in the cgroup subsystem which used to use
>> hard-coded stack allocated
>> buffers for concatenating strings in memory. We can use `stringStream`
>> instead which doesn't have the issue
>> of
On Sun, 15 May 2022 10:31:20 GMT, Andrey Turbanov wrote:
>> TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
>> Compared via JMH benchmark: 150ns -> 125ns/op
>>
>> Benchamark adapted from
>> http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java
>>
>>
>>
Hello,
I have this List/Deque implementation [1] that (in a versatile benchmark)
runs much faster than ArrayList/LinkedList. Under mild assumptions, it
accesses an element in O(sqrt(N)) time.
Now, if all we want to do is to add at the tail and read via get(int
index), you are better of using
On Fri, 10 Jun 2022 14:19:27 GMT, Daniel Fuchs wrote:
> I might question whether the added "null:-1" information is really helpful,
> or just as confusing however.
Hi Daniel, should we maybe better print something like "check for not allowed
characters" in the exception ? Do you have an easy
On Fri, 10 Jun 2022 21:04:04 GMT, Phil Race wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> use round directly
>
> src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 38:
>
>> 36: # define
> We still handle at a number of places ancient historic _MSC_VER versions of
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't
> want to adjust.
>
> Currently still supported ("valid") VS version
On Wed, 8 Jun 2022 12:09:27 GMT, Severin Gehwolf wrote:
>> Please review this cleanup change in the cgroup subsystem which used to use
>> hard-coded stack allocated
>> buffers for concatenating strings in memory. We can use `stringStream`
>> instead which doesn't have the issue
>> of
At present, MethodHandle's invokeExact() is declared as the following:
>From [1]:
> @IntrinsicCandidate
> public final native @PolymorphicSignature Object invokeExact(Object...
> args) throws Throwable;
I think this is a case where this method should probably never have
thrown a checked
I'd like to point out that rodde has also asked this project to be
included in Apache Commons Collections:
https://lists.apache.org/thread/klwtkbz96rp9zfr1077sc9r8tjtthfl4
On 11/06/2022 15:53, - wrote:
Hello,
What do you think?
First, for your benchmarks, I recommend you write them with
Hello,
> What do you think?
First, for your benchmarks, I recommend you write them with
https://github.com/openjdk/jmh, a library that allows configuration of
warmup time, number of trials, and has utilities that avoid jvm
optimization's impact on your benchmarks.
A few cents: I recall seeing a
On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov wrote:
> Hashtable doesn't allow `null` values. So, instead of pair
> `containsKey`/`remove` calls, we can directly call `remove` and then compare
> result with `null`.
>
On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov wrote:
> Hashtable doesn't allow `null` values. So, instead of pair
> `containsKey`/`remove` calls, we can directly call `remove` and then compare
> result with `null`.
>
On Sat, 11 Jun 2022 07:55:52 GMT, Peter Levart wrote:
>> Oops, yes you are correct!
>
> Hi,
> I think the synchronized block was redundant already in original code. Since
> the entire handle method is `static synchronized` and it is the only method
> that modifies the `handlers` and `signals`
On Fri, 10 Jun 2022 11:45:28 GMT, David M. Lloyd wrote:
>> Hello David, I suspect you mean `handlers.put(sig, handler)` and not
>> `handlers.replace(...)`? And yes, I think what you suggest will help remove
>> the synchronized block here.
>
> Oops, yes you are correct!
Hi,
I think the
On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes wrote:
> Expired Flags in 20:
>
> - FilterSpuriousWakeups
> - MinInliningThreshold
> - PrefetchFieldsAhead
>
> No remaining usages in code or tests.
>
> - UseHeavyMonitors (expired in PRODUCT ONLY)
>
> As this flag now only exists for debug
On Sat, 11 Jun 2022 05:48:14 GMT, Alan Bateman wrote:
>> Expired Flags in 20:
>>
>> - FilterSpuriousWakeups
>> - MinInliningThreshold
>> - PrefetchFieldsAhead
>>
>> No remaining usages in code or tests.
>>
>> - UseHeavyMonitors (expired in PRODUCT ONLY)
>>
>> As this flag now only exists
On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes wrote:
> Expired Flags in 20:
>
> - FilterSpuriousWakeups
> - MinInliningThreshold
> - PrefetchFieldsAhead
>
> No remaining usages in code or tests.
>
> - UseHeavyMonitors (expired in PRODUCT ONLY)
>
> As this flag now only exists for debug
On Fri, 10 Jun 2022 15:57:40 GMT, Vladimir Kozlov wrote:
>> Expired Flags in 20:
>>
>> - FilterSpuriousWakeups
>> - MinInliningThreshold
>> - PrefetchFieldsAhead
>>
>> No remaining usages in code or tests.
>>
>> - UseHeavyMonitors (expired in PRODUCT ONLY)
>>
>> As this flag now only exists
On Sat, 11 Jun 2022 00:35:52 GMT, Joe Darcy wrote:
> 8288173: JDK-8202449 fix causes conformance test failure :
> api/java_util/Random/RandomGenerator/NextFloat.html
This pull request has now been integrated.
Changeset: f4b05a11
Author:Joe Darcy
URL:
8288173: JDK-8202449 fix causes conformance test failure :
api/java_util/Random/RandomGenerator/NextFloat.html
-
Commit messages:
- Backport da2339cf6971532593e4f1b5ebbce8d1ed2e83b2
Changes: https://git.openjdk.org/jdk19/pull/5/files
Webrev:
On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken wrote:
> We still handle at a number of places ancient historic _MSC_VER versions of
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't
> want to
As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's
locale data (before CLDR). This is useful for legacy applications, but some of
its data got obsolete for later locale data updates, such as the country name
change for `Eswatini` (formerly known as `Swaziland`).
On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti
wrote:
> This fixes a bug introduced with JDK-8202449.
This pull request has now been integrated.
Changeset: da2339cf
Author:Raffaello Giulietti
Committer: Brian Burkhalter
URL:
On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti
wrote:
> This fixes a bug introduced with JDK-8202449.
Changes look okay, but please do a follow-up fix to add some regression tests
for this condition.
-
Marked as reviewed by darcy (Reviewer).
PR:
On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes wrote:
> Expired Flags in 20:
>
> - FilterSpuriousWakeups
> - MinInliningThreshold
> - PrefetchFieldsAhead
>
> No remaining usages in code or tests.
>
> - UseHeavyMonitors (expired in PRODUCT ONLY)
>
> As this flag now only exists for debug
On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken wrote:
> We still handle at a number of places ancient historic _MSC_VER versions of
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't
> want to
On Fri, 10 Jun 2022 11:31:06 GMT, Andrey Turbanov wrote:
>> https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178
>>
>> Instead of separate Hashtable.get/remove calls we can just use value
>> returned by
On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken wrote:
> When trying to construct an LdapURL object with a bad input string (in this
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run
> into the
On Fri, 10 Jun 2022 18:19:42 GMT, Thiago Henrique Hüpner
wrote:
>> test/jdk/tools/jar/modularJar/Basic.java line 44:
>>
>>> 42:
>>> 43: import jdk.internal.module.ModuleReferenceImpl;
>>> 44: import jdk.internal.module.ModuleResolution;
>>
>> At some point we need to put in test
On Fri, 10 Jun 2022 18:01:24 GMT, Alan Bateman wrote:
>> Thiago Henrique Hüpner has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix copyright year
>
> test/jdk/tools/jar/modularJar/Basic.java line 44:
>
>> 42:
>> 43: import
On Fri, 10 Jun 2022 18:25:09 GMT, Thiago Henrique Hüpner
wrote:
>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved
>> flags is used
>
> Thiago Henrique Hüpner has updated the pull request incrementally with one
> additional commit since the last revision:
>
>
> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved
> flags is used
Thiago Henrique Hüpner has updated the pull request incrementally with one
additional commit since the last revision:
Rename dataprovider
-
Changes:
- all:
On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti
wrote:
> This fixes a bug introduced with JDK-8202449.
Marked as reviewed by bpb (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/9120
On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti
wrote:
> This fixes a bug introduced with JDK-8202449.
The fix reverts an inadvertent "correction" sneaked into JDK-8202449, restoring
previous (correct) behavior.
-
PR: https://git.openjdk.org/jdk/pull/9120
On Fri, 10 Jun 2022 16:30:57 GMT, Thiago Henrique Hüpner
wrote:
>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved
>> flags is used
>
> Thiago Henrique Hüpner has updated the pull request incrementally with one
> additional commit since the last revision:
>
>
On Wed, 8 Jun 2022 04:59:07 GMT, Yoshiki Sato wrote:
> Please review this PR.
> SDK 10.15 and earlier reports os.version as 10.16 on Big Sur. This fix will
> check if dynamic linker support, which is supported from Big Sur, is
> available or not on the OS even if os.version is reported as
On Fri, 10 Jun 2022 16:15:36 GMT, Joe Darcy wrote:
> There are many instanceof checks in the sun.reflection.annotation code; these
> would be improved by using pattern matching for instanceof.
This pull request has now been integrated.
Changeset: aaa89714
Author:Joe Darcy
URL:
On Fri, 10 Jun 2022 16:15:36 GMT, Joe Darcy wrote:
> There are many instanceof checks in the sun.reflection.annotation code; these
> would be improved by using pattern matching for instanceof.
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/9129
On Fri, 10 Jun 2022 16:15:36 GMT, Joe Darcy wrote:
> There are many instanceof checks in the sun.reflection.annotation code; these
> would be improved by using pattern matching for instanceof.
Seems clean
-
PR: https://git.openjdk.org/jdk/pull/9129
> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved
> flags is used
Thiago Henrique Hüpner has updated the pull request incrementally with one
additional commit since the last revision:
Fix copyright year
-
Changes:
- all:
There are many instanceof checks in the sun.reflection.annotation code; these
would be improved by using pattern matching for instanceof.
-
Commit messages:
- JDK-8288227: Refactor annotation implementation to use pattern matching for
instanceo
Changes:
On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes wrote:
> Expired Flags in 20:
>
> - FilterSpuriousWakeups
> - MinInliningThreshold
> - PrefetchFieldsAhead
>
> No remaining usages in code or tests.
>
> - UseHeavyMonitors (expired in PRODUCT ONLY)
>
> As this flag now only exists for debug
On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken wrote:
> When trying to construct an LdapURL object with a bad input string (in this
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run
> into the
On Fri, 10 Jun 2022 13:41:48 GMT, Matthias Baesken wrote:
> Hi Alan , sure we could use something like the already existing hostInfo of
> property jdk.includeInException private static final boolean
> enhancedExceptionText = SecurityProperties.includedInExceptions("hostInfo");
> and make the
On Fri, 10 Jun 2022 13:15:11 GMT, Alan Bateman wrote:
> We have to be cautious about leaking security sensitive configuration in
> exception messages. Can you look at the security property
> jdk.includeInException (conf/security/java.security) and usages in the JDK
> for ideas on how this
Expired Flags in 20:
- FilterSpuriousWakeups
- MinInliningThreshold
- PrefetchFieldsAhead
No remaining usages in code or tests.
- UseHeavyMonitors (expired in PRODUCT ONLY)
As this flag now only exists for debug builds it has to be a "develop" flag
rather than product. There are then changes
1 - 100 of 84465 matches
Mail list logo
