On the one hand, I am very opposed to using the name ` SequencedCollection
`. In the JVM ecosystem, several widely used libraries are using the term
Seq,
Typical examples are Scala and kotlin's standard libraries, Scala uses
`Seq` as a similar correspondence to a `List`, while Kotlin's `Sequence`
On Mon, 14 Feb 2022 22:47:53 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
>>
How about `OrderedCollection`? The meaning of "order" has been defined in
the Stream API, so I think the 'ordered' may be a better choice.
Stuart Marks 于2022年2月15日周二 14:45写道：
>
>
> On 2/11/22 7:24 PM, Tagir Valeev wrote:
> > Of course, I strongly support this initiative and am happy that my
>
On Wed, 9 Feb 2022 18:51:22 GMT, Andrey Turbanov wrote:
> At start of method `b` is already checked for null.
>
> https://github.com/openjdk/jdk/blob/178b962e01cc6c150442bf41dc6bd199caff0042/src/java.base/share/classes/java/io/LineNumberInputStream.java#L129-L131
>
> Found by IntelliJ IDEA
>
On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann wrote:
> We observed several failures on macosx aarch64 after integration of
> [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could
> reliably reproduce
> [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with
On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann wrote:
> We observed several failures on macosx aarch64 after integration of
> [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could
> reliably reproduce
> [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with
On Mon, 14 Feb 2022 22:47:53 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 2/11/22 7:24 PM, Tagir Valeev wrote:
Of course, I strongly support this initiative and am happy that my proposal got some
love and is moving forward. In general, I like the JEP in the way it is. I have only
two slight concerns:
1. I'm not sure that having addition methods (addFirst,
> A number of modules declare that the "provide" ToolProvider.
>
> These modules now specify the "name" of the argument used by
> `ToolProvider.findFirst` to access an instance of the tool provider within
> the description part of a `@provides` API tag.
Christian Stein has updated the pull
On Sun, 13 Feb 2022 05:18:34 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch implements the unsigned upcast intrinsics in x86, which are used
>> in vector lane-wise reinterpreting operations.
>>
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one
Hi Joe,
On 15/02/2022 11:22 am, Joe Darcy wrote:
Retrofitting of Parameter to implement Member, an interface already implemented
by similar reflective modeling classes.
But a parameter is not a Member!
David
Since Parameter is final, there is little compatibility impact from adding a
new
Here is the first sentence of the javadoc for java.util.List "An ordered collection
(also known as a sequence)."
And the first paragraph of java.util.RandomAccess "Marker interface used by List
implementations to indicate that they support fast (generally constant time) random
access. The
> A number of modules declare that the "provide" ToolProvider.
>
> These modules now specify the "name" of the argument used by
> `ToolProvider.findFirst` to access an instance of the tool provider within
> the description part of a `@provides` API tag.
Christian Stein has updated the pull
On Tue, 15 Feb 2022 03:45:19 GMT, Stuart Marks wrote:
> > A test will fail if not change codes there. Every pr should pass ci, so I
> > have no choice.
>
> Hm, yes I recall in the preliminary email that there was some mention of a
> test. However, the test seemed to use the same (incorrect)
On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8281634?
>
> The commit introduces the missing `err.invalid.filters` key in the jdeps
> resource bundle. I have
On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8281634?
>
> The commit introduces the missing `err.invalid.filters` key in the jdeps
> resource bundle. I have
On Tue, 15 Feb 2022 02:12:48 GMT, XenoAmess wrote:
> A test will fail if not change codes there. Every pr should pass ci, so I
> have no choice.
Hm, yes I recall in the preliminary email that there was some mention of a
test. However, the test seemed to use the same (incorrect) calculation,
> This patch removes the restriction in the raw library loading mechanism that
> does not allow mix-n-match of loading a library as a JNI library and as a raw
> library.
>
> The raw library loading mechanism is designed for panama to load native
> library essentially equivalent to
On Tue, 15 Feb 2022 02:00:35 GMT, Stuart Marks wrote:
> The changes to j.l.Class and the EnumConstantDirectory test don't belong here
> -- these are _uses_ of HashMap. This bug and fix should focus on HashMap
> itself, to ensure that the cases in question allocate a table of the right
> size.
On Sun, 13 Feb 2022 05:18:34 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch implements the unsigned upcast intrinsics in x86, which are used
>> in vector lane-wise reinterpreting operations.
>>
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one
On Fri, 11 Feb 2022 19:32:48 GMT, XenoAmess wrote:
>> 8281631: HashMap.putAll can cause redundant space waste
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 9072610: HashMap.putAll can cause redundant space waste
OK. The
Retrofitting of Parameter to implement Member, an interface already implemented
by similar reflective modeling classes.
Since Parameter is final, there is little compatibility impact from adding a
new method.
Please also review the corresponding CSR:
On Fri, 11 Feb 2022 22:11:44 GMT, Alexey Semenyuk wrote:
>> Alexander Matveev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8279995: jpackage --add-launcher option should allow overriding
>> description [v2]
>
>
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
Tim Prinzing has updated the pull request incrementally with one additional
commit since the last revision:
remove excess description
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7447/files
- new:
> Added ability to override description for additional launchers via
> "description" property.
Alexander Matveev has updated the pull request incrementally with one
additional commit since the last revision:
8279995: jpackage --add-launcher option should allow overriding description
[v3]
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
Tim Prinzing has updated the pull request incrementally with one additional
commit since the last revision:
missing dot
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7447/files
- new:
> 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 Mon, 14 Feb 2022 21:12:51 GMT, Mandy Chung wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Respond to review feedback explicitly stating returned sets are immutable.
>
>
On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann wrote:
> We observed several failures on macosx aarch64 after integration of
> [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could
> reliably reproduce
> [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
Tim Prinzing has updated the pull request incrementally with one additional
commit since the last revision:
Changes from feedback.
- Improved javadoc.
- Single copyright date in new files.
- Informative string in
On Mon, 14 Feb 2022 22:07:24 GMT, Joe Darcy wrote:
>> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 146:
>>
>>> 144: */
>>> 145: SYNTHETIC(0x1000, false,
>>> 146: Set.of(TYPE, FIELD, METHOD, CONSTRUCTOR,
>>> ElementType.MODULE, PARAMETER)),
>>
On Mon, 14 Feb 2022 21:10:22 GMT, Mandy Chung 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 three additional commits
>>
On Mon, 14 Feb 2022 20:52:28 GMT, Joe Darcy wrote:
>> Thanks for catching the typo Adam; I'll fix it in the next push.
>
>> Looks promising, some comments:
>>
>> The terminology in the JVMS is about modifiers; can the class name include
>> the word Modifier, perhaps ModifierFlag(s)? Several of
On Mon, 14 Feb 2022 20:02:50 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 Mon, 14 Feb 2022 21:00:45 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 Mon, 14 Feb 2022 21:00:45 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 Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann wrote:
> We observed several failures on macosx aarch64 after integration of
> [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could
> reliably reproduce
> [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with
On Mon, 14 Feb 2022 18:12:13 GMT, Joe Darcy wrote:
>> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 206:
>>
>>> 204: * modifier in the Java programming language}
>>> 205: */
>>> 206: public boolean sourceModifer() {
>>
>> probably a typo - should be
> 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
Fixing a bug in `NFCCharProperty` where code falling through an if-statement
can prematurely set the matcher's `hitEnd` field to true.
-
Commit messages:
- Catching erronious setting of matcher.hitEnd
Changes: https://git.openjdk.java.net/jdk/pull/7466/files
Webrev:
Fixing an issue in `CompactNumberFormat` which was caused by
BigDecimal.divide() that incremented the number in the resulting format string.
Also fixing some typos by taking this opportunity.
-
Commit messages:
- 8281317: CompactNumberFormat displays 4-digit values when rounding
On Sun, 13 Feb 2022 05:14:47 GMT, Quan Anh Mai wrote:
>> Observing the following failures on CPUs with
>> "Intel_R__Xeon_R__Gold_6354_CPU___3.00GHz" with HotSpot flags:
>>
>> -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100
>> -XX:+UnlockExperimentalVMOptions -server
On Sun, 13 Feb 2022 05:18:34 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch implements the unsigned upcast intrinsics in x86, which are used
>> in vector lane-wise reinterpreting operations.
>>
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one
On Mon, 14 Feb 2022 18:20:19 GMT, Christian Stein wrote:
> I think Jon's latest proposal combines all requirements with using better
> wording than my initial text.
>
> Do you agree, @AlanBateman and @LanceAndersen?
Yes, I think that sounds good
-
PR:
On Mon, 14 Feb 2022 18:10:37 GMT, Alan Bateman wrote:
>> `MethodHandles::publicLookup` can be called instead to get a public Lookup
>> to invoke a method with a Lookup parameter. The dilemma here is whether
>> the API should be made null-caller friendly or using a proper API
>>
On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote:
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
Marked as reviewed by jrose (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7447
On Mon, 14 Feb 2022 18:28:09 GMT, Mandy Chung wrote:
>> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121:
>
>> 119: Class c = Reflection.getCallerClass();
>> 120: if (c == null) {
>>
On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote:
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
This needs a CSR and the spec needs update.
The test name could be shortened to
`s/exeNullCallerMethodHandlesLookup/exeNullCallerLookup/`.
On Thu, 10 Feb 2022 17:24:17 GMT, Jonathan Gibbons wrote:
>>> Perhaps like this?
>>>
>>> ```java
>>> /**
>>> * ...
>>> * @provides java.util.spi.ToolProvider
>>> * Module {@code jdk.jartool} provides a tool named {@code "jar"}.
>>> * Invoke {@link
On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote:
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
test/jdk/java/lang/invoke/MethodHandles/exeNullCallerMethodHandlesLookup/NullCallerMethodHandlesLookupTest.java
line 2:
> 1: /*
> 2: * Copyright (c) 2019, 2022, Oracle
On Mon, 14 Feb 2022 18:03:45 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121:
>>
>>> 119: Class c = Reflection.getCallerClass();
>>> 120: if (c == null) {
>>> 121: throw new IllegalCallerException();
>>
>> Throwing
On Mon, 14 Feb 2022 16:29:36 GMT, Adam Sotona 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 Mon, 14 Feb 2022 11:56:16 GMT, Alan Bateman wrote:
>> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121:
>
>> 119: Class c = Reflection.getCallerClass();
>> 120: if (c == null) {
>>
On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8281634?
>
> The commit introduces the missing `err.invalid.filters` key in the jdeps
> resource bundle. I have
On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8281634?
>
> The commit introduces the missing `err.invalid.filters` key in the jdeps
> resource bundle. I have
On Mon, 14 Feb 2022 08:01:38 GMT, Peter Levart wrote:
>> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line
>> 620:
>>
>>> 618: * The configurations exist as an object to avoid race conditions.
>>> 619: * See bug 8261407. The object methods backed by indy
On Mon, 14 Feb 2022 09:12:54 GMT, Andrew Haley wrote:
>>> What does this do? Comment, even pseudo code, would be nice.
>>
>> Thanks @theRealAph , I shall append the comments over the routine.
>> BTW, entire rounding algorithm can also be implemented using Vector API
>> which can perform
On Fri, 11 Feb 2022 18:31:57 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 Fri, 11 Feb 2022 18:31:57 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 Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote:
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
Build changes are OK
-
Marked as reviewed by ihse (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7447
On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing wrote:
> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is
> null
Build changes LGTM.
-
Marked as reviewed by ihse (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7448
On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth wrote:
>> Remove unused imports under test/lib and jtreg/gc. They create lots of
>> warnings if editing using an IDE. Tests in hotspot_gc passed.
>
> Leo Korinth has updated the pull request incrementally with one additional
> commit since the last
On Thu, 10 Feb 2022 15:39:53 GMT, Leo Korinth wrote:
> Remove unused imports under test/lib and jtreg/gc. They create lots of
> warnings if editing using an IDE. Tests in hotspot_gc passed.
This pull request has now been integrated.
Changeset: 2604a88f
Author:Leo Korinth
URL:
On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote:
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null
src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121:
> 119: Class c = Reflection.getCallerClass();
> 120: if (c == null) {
> 121:
On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8281634?
>
> The commit introduces the missing `err.invalid.filters` key in the jdeps
> resource bundle. I have
On Wed, 9 Feb 2022 18:51:22 GMT, Andrey Turbanov wrote:
> At start of method `b` is already checked for null.
>
> https://github.com/openjdk/jdk/blob/178b962e01cc6c150442bf41dc6bd199caff0042/src/java.base/share/classes/java/io/LineNumberInputStream.java#L129-L131
Looks good. The surrounding
We observed several failures on macosx aarch64 after integration of
[JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could
reliably reproduce
[JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with JDK 18
b25-1665 (the first build with
On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8281634?
>
> The commit introduces the missing `err.invalid.filters` key in the jdeps
> resource bundle. I have
At start of method `b` is already checked for null.
https://github.com/openjdk/jdk/blob/178b962e01cc6c150442bf41dc6bd199caff0042/src/java.base/share/classes/java/io/LineNumberInputStream.java#L129-L131
-
Commit messages:
- [PATCH] Remove redundant null check in
On Sun, 13 Feb 2022 13:12:35 GMT, Jatin Bhateja wrote:
>>> Hi, IIRC for evex encoding you can embed the RC control bit directly in the
>>> evex prefix, removing the need to rely on global MXCSR register. Thanks.
>>
>> Hi @merykitty , You are correct, we can embed RC mode in instruction
>>
On Fri, 11 Feb 2022 21:44:04 GMT, Mandy Chung wrote:
> Note that the object methods of this Config record are called via indy which
> is
> available to use after initPhase1. We can workaround that limitation by
> implementing the object methods.
"Note that the object methods of this Config
72 matches
Mail list logo
