On Tue, 10 May 2022 09:57:48 GMT, Jan Lahoda wrote:
>> 8262889: Compiler implementation for Record Patterns
>>
>> A first version of a patch that introduces record patterns into javac as a
>> preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/
On Mon, 9 May 2022 14:37:35 GMT, Jan Lahoda wrote:
>> 8262889: Compiler implementation for Record Patterns
>>
>> A first version of a patch that introduces record patterns into javac as a
>> preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/j
On Mon, 9 May 2022 14:37:35 GMT, Jan Lahoda wrote:
>> 8262889: Compiler implementation for Record Patterns
>>
>> A first version of a patch that introduces record patterns into javac as a
>> preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/j
On Fri, 6 May 2022 17:40:25 GMT, Jan Lahoda wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4217:
>>
>>> 4215: }
>>> 4216: ListBuffer outBindings = new ListBuffer<>();
>>> 4217: List recordTypes = expectedRecordTypes;
>>
>> nit: probably
On Fri, 6 May 2022 14:09:24 GMT, Jan Lahoda wrote:
>> 8262889: Compiler implementation for Record Patterns
>>
>> A first version of a patch that introduces record patterns into javac as a
>> preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/j
On Thu, 5 May 2022 15:21:49 GMT, Maurizio Cimadamore
wrote:
>> 8262889: Compiler implementation for Record Patterns
>>
>> A first version of a patch that introduces record patterns into javac as a
>> preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/je
On Tue, 19 Apr 2022 18:47:16 GMT, Jan Lahoda wrote:
>> This is a (preliminary) patch for javac implementation for the third preview
>> of pattern matching for switch (type patterns in switches).
>>
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwit
On Tue, 19 Apr 2022 18:47:16 GMT, Jan Lahoda wrote:
>> This is a (preliminary) patch for javac implementation for the third preview
>> of pattern matching for switch (type patterns in switches).
>>
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwit
On Tue, 19 Apr 2022 18:47:16 GMT, Jan Lahoda wrote:
>> This is a (preliminary) patch for javac implementation for the third preview
>> of pattern matching for switch (type patterns in switches).
>>
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwit
On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda wrote:
>> This is a (preliminary) patch for javac implementation for the third preview
>> of pattern matching for switch (type patterns in switches).
>>
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwit
On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda wrote:
>> This is a (preliminary) patch for javac implementation for the third preview
>> of pattern matching for switch (type patterns in switches).
>>
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwit
On Thu, 14 Apr 2022 08:46:50 GMT, Aggelos Biboudis
wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Cleanup.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line
> 1377:
>
>> 1375:
On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda wrote:
>> This is a (preliminary) patch for javac implementation for the third preview
>> of pattern matching for switch (type patterns in switches).
>>
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwit
On Thu, 7 Apr 2022 03:33:02 GMT, Vicente Romero wrote:
> We recently updated our ASM version to 9.2 and just this week version 9.3 was
> announced with support for JDK19 so it makes sense to update to this last
> version.
>
> Thanks in advance for the reviews,
> Vicente
Thi
On Fri, 8 Apr 2022 16:44:15 GMT, Mandy Chung wrote:
>> We recently updated our ASM version to 9.2 and just this week version 9.3
>> was announced with support for JDK19 so it makes sense to update to this
>> last version.
>>
>> Thanks in advance for the reviews,
>> Vicente
>
> Looks okay. Mo
We recently updated our ASM version to 9.2 and just this week version 9.3 was
announced with support for JDK19 so it makes sense to update to this last
version.
Thanks in advance for the reviews,
Vicente
-
Commit messages:
- updating test ValidateJarWithSealedAndRecord
- adaptati
On Wed, 30 Mar 2022 02:56:41 GMT, Vicente Romero wrote:
>> Please review this PR which is updating the ASM included in the JDK to ASM
>> 9.2. This version should be included in JDK19. There are basically two
>> commits here, one that was automatically generated and that mostl
mons.RemappingMethodAdapter
> jdk.internal.org.objectweb.asm.commons.RemappingAnnotationAdapter
>
> This is because package: `jdk.jfr.internal.instrument` needs them.
>
> TIA
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revision:
fixing files missing new line at the e
On Mon, 28 Mar 2022 17:08:12 GMT, Lance Andersen wrote:
> With this fix, I believe
> [JDK-8282446](https://bugs.openjdk.java.net/browse/JDK-8282446) should also
> be addressed.
Thanks for mentioning this. I have uploaded another commit
[41ae618e3a5ce696e3400a8654d98801226d7c1b](https://github
mons.RemappingMethodAdapter
> jdk.internal.org.objectweb.asm.commons.RemappingAnnotationAdapter
>
> This is because package: `jdk.jfr.internal.instrument` needs them.
>
> TIA
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revision:
addressing review commen
On Mon, 28 Mar 2022 17:50:25 GMT, Rémi Forax wrote:
> I suppose that you are raising commons.RemappingMethodAdapter and
> commons.RemappingAnnotationAdapter from the dead because you want to fix the
> code in jdk.jfr.internal.instrument later ?
correct, I would prefer the team maintaining jdk.
Please review this PR which is updating the ASM included in the JDK to ASM 9.2.
This version should be included in JDK19.
TIA
-
Commit messages:
- additional adaptations after the automatic conversion
- 8282508: Updating ASM to 9.2 for JDK 19
Changes: https://git.openjdk.java.net
On Mon, 14 Mar 2022 21:27:29 GMT, Joe Darcy wrote:
>> Improving the exception messages for out-of-supported-range array types.
>>
>> I'll update copyrights before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respo
On Mon, 14 Mar 2022 19:56:17 GMT, Joe Darcy wrote:
> Improving the exception messages for out-of-supported-range array types.
>
> I'll update copyrights before pushing.
src/java.base/share/classes/java/lang/constant/ClassDesc.java line 186:
> 184: if (rank <= 0 || netRank >
> Constant
On Thu, 16 Dec 2021 17:44:04 GMT, Vicente Romero wrote:
> Hi,
>
> Please review this change that is fixing a bug in reflection in particular in
> `sun.reflect.annotation.TypeAnnotationParser::buildAnnotatedTypes` the
> current code is assuming that for inner class constructors,
On Fri, 21 Jan 2022 12:41:37 GMT, Jan Lahoda wrote:
> To me, looks good.
thanks
-
PR: https://git.openjdk.java.net/jdk/pull/6869
On Thu, 16 Dec 2021 18:01:54 GMT, Joe Darcy wrote:
> Hi Vicente.
>
> Please file a CSR for the behavioral change.
sure, thanks
-
PR: https://git.openjdk.java.net/jdk/pull/6869
Hi,
Please review this change that is fixing a bug in reflection in particular in
`sun.reflect.annotation.TypeAnnotationParser::buildAnnotatedTypes` the current
code is assuming that for inner class constructors it is always working on type
annotations on parameters, but it is also invoked to e
On Tue, 23 Nov 2021 15:09:53 GMT, Claes Redestad wrote:
> Thanks for adding the comment and fixing typos.
sure, thanks to you
-
PR: https://git.openjdk.java.net/jdk/pull/6403
On Tue, 23 Nov 2021 15:05:47 GMT, Vicente Romero wrote:
>> Please review this PR which aims to optimize the implementation of the
>> `toString` method we provide for records. A benchmark comparing the
>> implementation we are providing for records with lombok found out that
5.718 ± 4.633 ns/op
> MyBenchmark.record_hash_code avgt4 4.628 ± 4.368 ns/op
> MyBenchmark.record_to_string avgt4 26.791 ± 1.817 ns/op
> <--- After
> MyBenchmark.value_class_to_string avgt 4 35.473 ± 2.626 ns/op
> MyBenchmark.value_
5.718 ± 4.633 ns/op
> MyBenchmark.record_hash_code avgt4 4.628 ± 4.368 ns/op
> MyBenchmark.record_to_string avgt4 26.791 ± 1.817 ns/op
> <--- After
> MyBenchmark.value_class_to_string avgt 4 35.473 ± 2.626 ns/op
> MyBenchmark.value_
On Mon, 22 Nov 2021 15:53:53 GMT, Claes Redestad wrote:
> FWIW I did a few experiments trying to move the chunking to `SCF`. Most made
> things worse, but this is getting close:
> https://github.com/openjdk/jdk/compare/master...cl4es:scf_split?expand=1
>
> The threshold for when the JIT fails
On Sat, 20 Nov 2021 12:10:40 GMT, Jim Laskey wrote:
>> @stuart-marks yes, a general purpose splitting logic moved into the
>> `StringConcatFactory` would be able to get rid of the arbitrary 200 slot
>> limit (we would hit a harder but less arbitrary limit at around 253 instead).
>>
>> @JimLask
On Sun, 21 Nov 2021 00:29:46 GMT, Vicente Romero wrote:
>> Please review this PR which aims to optimize the implementation of the
>> `toString` method we provide for records. A benchmark comparing the
>> implementation we are providing for records with lombok found out that
5.718 ± 4.633 ns/op
> MyBenchmark.record_hash_code avgt4 4.628 ± 4.368 ns/op
> MyBenchmark.record_to_string avgt4 26.791 ± 1.817 ns/op
> <--- After
> MyBenchmark.value_class_to_string avgt 4 35.473 ± 2.626 ns/op
> MyBenchmark.value_
On Fri, 19 Nov 2021 05:07:23 GMT, Vicente Romero wrote:
>> Please review this PR which aims to optimize the implementation of the
>> `toString` method we provide for records. A benchmark comparing the
>> implementation we are providing for records with lombok found out that
On Fri, 19 Nov 2021 05:28:10 GMT, Guoxiong Li wrote:
> FYI: this patch also seems to solve
> [JDK-8265747](https://bugs.openjdk.java.net/browse/JDK-8265747).
yep, although I prefer to keep
[JDK-8265747](https://bugs.openjdk.java.net/browse/JDK-8265747) because it is
also referring to the hash
On Fri, 19 Nov 2021 05:07:23 GMT, Vicente Romero wrote:
>> Please review this PR which aims to optimize the implementation of the
>> `toString` method we provide for records. A benchmark comparing the
>> implementation we are providing for records with lombok found out that
5.718 ± 4.633 ns/op
> MyBenchmark.record_hash_code avgt4 4.628 ± 4.368 ns/op
> MyBenchmark.record_to_string avgt4 26.791 ± 1.817 ns/op
> <--- After
> MyBenchmark.value_class_to_string avgt 4 35.473 ± 2.626 ns/op
> MyBenchmark.value_
On Wed, 17 Nov 2021 22:00:30 GMT, Vicente Romero wrote:
>> Please review this PR which aims to optimize the implementation of the
>> `toString` method we provide for records. A benchmark comparing the
>> implementation we are providing for records with lombok found out that
5.718 ± 4.633 ns/op
> MyBenchmark.record_hash_code avgt4 4.628 ± 4.368 ns/op
> MyBenchmark.record_to_string avgt4 26.791 ± 1.817 ns/op
> <--- After
> MyBenchmark.value_class_to_string avgt 4 35.473 ± 2.626 ns/op
> MyBenchmark.value_
On Tue, 16 Nov 2021 05:24:38 GMT, Vicente Romero wrote:
> Please review this PR which aims to optimize the implementation of the
> `toString` method we provide for records. A benchmark comparing the
> implementation we are providing for records with lombok found out that lombok
Please review this PR which aims to optimize the implementation of the
`toString` method we provide for records. A benchmark comparing the
implementation we are providing for records with lombok found out that lombok
is much faster mainly because our implementation uses `String::format`. This
f
On Mon, 23 Aug 2021 18:08:02 GMT, Vicente Romero wrote:
> Please review this simple PR along with the associated CSR. The PR is
> basically adding a line the the specification of method
> `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a
> NPE wi
://bugs.openjdk.java.net/browse/JDK-8272852)
Vicente Romero 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 five additional
commits since the last re
On Mon, 30 Aug 2021 01:45:49 GMT, Mandy Chung wrote:
>> Vicente Romero has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> clarifying that the names parameter is ignored in some cases
>
> src/java.base/s
://bugs.openjdk.java.net/browse/JDK-8272852)
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revision:
clarifying that the names parameter is ignored in some cases
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5
On 8/25/21 4:45 PM, Mandy Chung wrote:
On 8/25/21 12:08 PM, Vicente Romero wrote:
On Wed, 25 Aug 2021 02:17:12 GMT, Mandy Chung wrote:
Hi Mandy, I have changed the implementation of the method to explicitly require
all arguments but lookup to be non-null as suggested by Brian. I have
On Wed, 25 Aug 2021 02:17:12 GMT, Mandy Chung wrote:
>> Hi Mandy, I have changed the implementation of the method to explicitly
>> require all arguments but lookup to be non-null as suggested by Brian. I
>> have also covered, I think, all the missing test cases in test
>> `ObjectMethodsTest`,
On Mon, 23 Aug 2021 23:13:58 GMT, Mandy Chung wrote:
>> Vicente Romero has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> addressing review comments
>
> src/java.base/share/classes/java/lang/runtime/ObjectMe
://bugs.openjdk.java.net/browse/JDK-8272852)
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revision:
addressing review comments
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5226/files
- new: https://git.openjdk.java
(type);
requireNonNull(recordClass);
requireNonNull(names);
requireNonNull(getters);
will do, thanks,
Vicente
On 8/23/2021 4:04 PM, Brian Goetz wrote:
+1
On 8/23/2021 2:22 PM, Vicente Romero wrote:
Please review this simple PR along with the associated CSR. The PR
is basically adding a line the
Please review this simple PR along with the associated CSR. The PR is basically
adding a line the the specification of method
`java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a
NPE will be thrown.
TIA
link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852)
On Sat, 10 Jul 2021 19:03:36 GMT, Vicente Romero wrote:
> Please review this PR that is fixing a mismatch between the implementation
> for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its
> implementation. I made a mistake while working on a recent CSR
> [JDK-82
On Mon, 12 Jul 2021 18:06:30 GMT, Vicente Romero wrote:
>> Please review this PR that is fixing a mismatch between the implementation
>> for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its
>> implementation. I made a mistake while working on a recent CS
nvoking. So it didn't make sense for the API of one method
> to be more restrictive than the other. Please review also the accompanying
> CSR.
>
> Thanks,
> Vicente
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revis
nvoking. So it didn't make sense for the API of one method
> to be more restrictive than the other. Please review also the accompanying
> CSR.
>
> Thanks,
> Vicente
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revisio
On Mon, 12 Jul 2021 17:11:01 GMT, Mandy Chung wrote:
>> Please review this PR that is fixing a mismatch between the implementation
>> for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its
>> implementation. I made a mistake while working on a recent CSR
>> [JDK-8224985](https:/
Please review this PR that is fixing a mismatch between the implementation for
method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its
implementation. I made a mistake while working on a recent CSR
[JDK-8224985](https://bugs.openjdk.java.net/browse/JDK-8224985) and fixed the
API but m
On Wed, 23 Jun 2021 20:57:24 GMT, Vicente Romero wrote:
> Enum constant: jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES was
> not removed when Sealed Classes were made final because the build was failing
> without it. Now that the feature is final we should be able to safel
Enum constant: jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES was not
removed when Sealed Classes were made final because the build was failing
without it. Now that the feature is final we should be able to safely removed
it. This is the intention of this patch.
TIA,
Vicente
On Fri, 11 Jun 2021 15:01:20 GMT, Vicente Romero wrote:
> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416)
> which was intended to openjdk/jdk.
>
> Please review this PR which is syncing the implementation of
> `DirectMethodHandleDesc.Kind.va
On Tue, 22 Jun 2021 00:45:36 GMT, Mandy Chung wrote:
>> Vicente Romero has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updating after review comments
>
> test/jdk/java/lang/constant/MethodHandleDes
is invoked with false
> regardless of the value of the refKind parameter
>
> TIA
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revision:
addressing review comments
-
Changes:
- all: https://git.openjdk
is invoked with false
> regardless of the value of the refKind parameter
>
> TIA
Vicente Romero 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 conta
On Fri, 11 Jun 2021 18:17:10 GMT, Vicente Romero wrote:
>> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416)
>> which was intended to openjdk/jdk.
>>
>> Please review this PR which is syncing the implementation of
>> `DirectMethodHan
is invoked with false
> regardless of the value of the refKind parameter
>
> TIA
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revision:
updating after review comments
-
Changes:
- all: https://git.openjdk
On Fri, 11 Jun 2021 15:15:12 GMT, Vicente Romero wrote:
>> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416)
>> which was intended to openjdk/jdk.
>>
>> Please review this PR which is syncing the implementation of
>> `DirectMethodHan
On Fri, 11 Jun 2021 15:01:20 GMT, Vicente Romero wrote:
> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416)
> which was intended to openjdk/jdk.
>
> Please review this PR which is syncing the implementation of
> `DirectMethodHandleDesc.Kind.va
On Thu, 10 Jun 2021 23:26:21 GMT, Vicente Romero wrote:
>> Please review this PR which is just syncing the implementation of
>> DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the
>> method's spec is that if the value of the
On Tue, 8 Jun 2021 16:46:36 GMT, Vicente Romero wrote:
> Please review this PR which is just syncing the implementation of
> DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the
> method's spec is that if the value of the `refKind
This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) which
was intended to openjdk/jdk.
Please review this PR which is syncing the implementation of
`DirectMethodHandleDesc.Kind.valueOf(int)` and
`DirectMethodHandleDesc.Kind.valueOf(int, boolean)` with its spec. My reading
On Wed, 9 Jun 2021 17:22:30 GMT, Mandy Chung wrote:
>> Vicente Romero has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> addressing review changes
>
> test/jdk/java/lang/constant/MethodHandleDescTest.java l
dleDesc.Kind.valueOf(int, boolean) should be called with a
> value of `true` for its second argument, currently it is invoked with `false`
> regardless of the value of the `refKind` parameter
>
> TIA
Vicente Romero has updated the pull request incrementally with one additional
On Wed, 9 Jun 2021 17:22:30 GMT, Mandy Chung wrote:
> Looks like the test does not verify the cases specified by `valueOf(int
> refKind, boolean isInterface)`.
> i.e. For most values of refKind, there is an exact match regardless of the
> value of isInterface except `REF_invokeStatic` and `REF_
Please review this PR which is just syncing the implementation of
DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the
method's spec is that if the value of the `refKind` parameter is:
MethodHandleInfo.REF_invokeInterface, then
DirectMethodHandleDesc.Kind.valueOf(int, boole
On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote:
>> This is a preview of a patch implementing JEP 406: Pattern Matching for
>> switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>>
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/je
On Mon, 17 May 2021 16:53:24 GMT, Vicente Romero wrote:
> This is a very small patch that is just rewording the spec for
> DynamicCallSiteDesc::withArgs. Basically adding that NPE can also be thrown
> if the content of the argument is `null`
>
> TIA for the review
This pull
On Mon, 17 May 2021 16:53:24 GMT, Vicente Romero wrote:
> This is a very small patch that is just rewording the spec for
> DynamicCallSiteDesc::withArgs. Basically adding that NPE can also be thrown
> if the content of the argument is `null`
>
> TIA for the review
any rev
On Fri, 21 May 2021 08:53:51 GMT, Gavin Bierman wrote:
>> Hi all,
>>
>> Please review this patch to make the ConstantDesc hierarchy `sealed`, as was
>> promised in its Javadoc, now that sealed classes are finalising in JDK 17.
>>
>> Thanks,
>> Gavin
>
> Gavin Bierman has updated the pull requ
On Fri, 16 Apr 2021 01:08:57 GMT, Vicente Romero wrote:
> Please review this PR that intents to make sealed classes a final feature in
> Java. This PR contains compiler and VM changes. In line with similar PRs,
> which has made preview features final, this one is mostly removin
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull reques
On Mon, 17 May 2021 16:53:24 GMT, Vicente Romero wrote:
> This is a very small patch that is just rewording the spec for
> DynamicCallSiteDesc::withArgs. Basically adding that NPE can also be thrown
> if the content of the argument is `null`
>
> TIA for the review
ping
--
This is a very small patch that is just rewording the spec for
DynamicCallSiteDesc::withArgs. Basically adding that NPE can also be thrown if
the content of the argument is `null`
TIA for the review
-
Commit messages:
- 8224158: assertion related to NPE at DynamicCallSiteDesc::wit
On Mon, 17 May 2021 13:11:56 GMT, Adam Sotona wrote:
> Actual javap implementation reacts on corrupted TABLESWITCH or LOOKUPSWITCH
> bytecode instructions resulting to negative array allocation with
> NegativeArraySizeException, which is reported to user with stack trace and as
> serious inter
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull reques
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull request
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull reques
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull reques
On Wed, 21 Apr 2021 14:42:39 GMT, Maurizio Cimadamore
wrote:
> Compiler changes look good (I have not checked SymbolGenerator).
>
> Why were some tests removed?
thanks for the review. The removed tests were already covered in langtools
regression tests, so I only removed duplicated tests
---
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull request
On Fri, 16 Apr 2021 02:10:05 GMT, David Holmes wrote:
> Hi Vicente,
>
> Hotspot and hotspot tests all look fine. One query: why was this test removed?
>
> test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java
>
> is that functionality tested elsewhere? (The other deleted test seemed
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull request
Please review this PR that intents to make sealed classes a final feature in
Java. This PR contains compiler and VM changes. In line with similar PRs, which
has made preview features final, this one is mostly removing preview related
comments from APIs plus options in test cases.
Thanks
--
On Thu, 25 Feb 2021 13:01:30 GMT, Adam Sotona wrote:
> Please review javap fix to handle java.lang.IllegalStateException for classes
> with invalid Signature attribute.
> New test (T8260403) parsing class with invalid Signature attribute (as
> described in the bug) is included.
> Fix wraps java
Please review this simple fix that is removing the RECORDS enum constant from
the PreviewFeature.Feature enum, now that RECORDS are final in 16 this constant
can be safely removed.
Thanks,
Vicente
-
Commit messages:
- 8260959: remove RECORDS from PreviewFeature.Feature enum
Chang
On Thu, 17 Dec 2020 10:07:13 GMT, Joel Borggrén-Franck
wrote:
>> The fix for JDK-8256693 too often produces a ParameterizedType as the result
>> of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary
>> only when this type or any of its transitive owner types has type
>> p
On Wed, 16 Dec 2020 19:57:32 GMT, Joel Borggrén-Franck
wrote:
> Yes, not great, but at least it isn't brittle when running the test, only
> when changing it. I'd like to take a separate pass over the tests for 17 if
> possible.
what about declaring a static final field for that value instead
On Wed, 16 Dec 2020 09:41:47 GMT, Joel Borggrén-Franck
wrote:
> The fix for JDK-8256693 too often produces a ParameterizedType as the result
> of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary
> only when this type or any of its transitive owner types has type paramete
1 - 100 of 348 matches
Mail list logo
