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.
src/jdk.jpackage/share/classes/jdk/jpackage/in
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.
src/jdk.jpackage/share/classes/jdk/jpackage/in
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: https://webrevs.openjdk.java.net/?repo=jd
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
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
Webre
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
>> dis
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
>> dis
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 exce
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 exce
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 i
> 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;
>
> S
specific for such
general parsing rules.
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von
Matthias Baesken
Gesendet: Tuesday, June 14, 2022 1:36:36 PM
An: core-libs-dev@openjdk.java.net ;
security-...@openjdk.java.net
Betreff: Re: RFR: JDK
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 exce
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 exce
> 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;
>
> S
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 exceptio
> 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;
>
> S
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 t
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 inclu
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
>
> Actua
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:
>
>> 298
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.
>
> `ACC_SU
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
>> dis
> 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
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
Webrev
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: https://git.openjdk.org/jdk/pul
> 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 ar
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 return
> 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 a
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 its
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 hard-codin
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
>>
>>
>> @Warmup
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 a
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 ROU
> 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 a
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 hard-codin
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`.
> https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f
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` m
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 synchron
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 for
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 buil
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 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 ad
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`). This
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: https://git.openjdk.org/jd
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 buil
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 ad
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 exceptio
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 infrastructur
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 jdk.interna
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:
>
> Ren
> 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: https://git.openjdk.org/jdk
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:
>
> Fix
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 10.1
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: https://git.openjdk.org/jdk/
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: https://git.openjdk.org/jdk
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 buil
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 exceptio
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 e
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 migh
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
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 exceptio
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;
String url = "lda
On Fri, 10 Jun 2022 06:45:00 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/jdk/internal/misc/Signal.java line 180:
>>
>>> 178: if (newH == 2) {
>>> 179: handlers.put(sig, handler);
>>> 180: }
>>
>> If you made this change instead:
>>
>> Suggest
> 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 `remove`,
> It results in cleaner and a bit faster code.
Andre
On Fri, 10 Jun 2022 10:49:25 GMT, Martin Doerr wrote:
> LGTM and sounds feasible.
Hi Martin, thanks for the review.
-
PR: https://git.openjdk.org/jdk/pull/9105
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 ad
> The test
> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java`
> verifies different failure modes of resource bundles. One of the failures is
> that the runner class, `MissingResourceCauseTestRun.java`, creates a file
> `UnreadableRB`, and runs `chmod 000` on it, to mak
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`.
> https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f
This fixes a bug introduced with JDK-8202449.
-
Commit messages:
- 8288173: JDK-8202449 fix causes conformance test failure
Changes: https://git.openjdk.org/jdk/pull/9120/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9120&range=00
Issue: https://bugs.openjdk.org/bro
On Fri, 10 Jun 2022 08:26:02 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which addresses
>> https://bugs.openjdk.java.net/browse/JDK-8285405?
>>
>> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the
>> existing `test/jdk/java/util/LinkedHashMap/Basic.
> Can I please get a review of this change which addresses
> https://bugs.openjdk.java.net/browse/JDK-8285405?
>
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing
> `test/jdk/java/util/LinkedHashMap/Basic.java` since that test has tests for
> various APIs of this c
> Can I please get a review of this change which addresses
> https://bugs.openjdk.java.net/browse/JDK-8285405?
>
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing
> `test/jdk/java/util/LinkedHashMap/Basic.java` since that test has tests for
> various APIs of this c
On Thu, 9 Jun 2022 21:11:55 GMT, David M. Lloyd 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 `r
On Mon, 6 Jun 2022 06:57:23 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which addresses
> https://bugs.openjdk.java.net/browse/JDK-8285405?
>
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing
> `test/jdk/java/util/LinkedHashMap/Basic.java`
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 include the upd
On Wed, 8 Jun 2022 09:39:04 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using
>> the same approach as the JVM does for long and floating-point comparisons.
>> This allows efficient and reliable usage of unsigned comparison in Java,
On Mon, 6 Jun 2022 06:57:23 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which addresses
> https://bugs.openjdk.java.net/browse/JDK-8285405?
>
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing
> `test/jdk/java/util/LinkedHashMap/Basic.java`
1 - 100 of 24997 matches
Mail list logo
