Re: [jdk17] RFR: 8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available"
On Mon, 5 Jul 2021 11:21:39 GMT, Daniel Fuchs wrote: > Please find here a trivial fix for: > > 8269772: [macos-aarch64] test compilation failed with "SocketException: No > buffer space available" > > Running several of the websocket tests concurrently on some of the CI > machines is causing resource exhaustion, because resources are only freed > after the TIMED_WAIT delay has expired once the tests have finished. > The proposed solution is to run these tests in exclusive dir mode. Marked as reviewed by vtewari (Committer). - PR: https://git.openjdk.java.net/jdk17/pull/210
Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v10]
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex > by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in > the whole JDK codebase. Yi Yang has updated the pull request incrementally with two additional commits since the last revision: - restore code format - restore code format - Changes: - all: https://git.openjdk.java.net/jdk/pull/4507/files - new: https://git.openjdk.java.net/jdk/pull/4507/files/f43ffc3a..903f0305 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4507=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4507=08-09 Stats: 36 lines in 2 files changed: 0 ins; 6 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/4507.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507 PR: https://git.openjdk.java.net/jdk/pull/4507
Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v8]
On Tue, 6 Jul 2021 19:06:43 GMT, Mandy Chung wrote: >> Yi Yang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> tests rely on IOOBE exception message > > test/jdk/java/lang/StringBuffer/Exceptions.java line 73: > >> 71: new StringBuffer(); >> 72: } >> 73: }); > > Nit: The above formatting (line 70-97) is inconsistent with the formatting in > line 110-124. It'd be good to use the same formatting. Hi Mandy, thanks for reviewing this. > I suggest to separate the client changes (both src and test) in a separate PR > for the client review. Does "client changes" means changes involving src/java.desktop and test/java/awt? > src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java > needs to be updated in JSR 166 upstream repo. Better to file a separate issue > for this change to ensure that gets fixed in the upstream project. Can you please paste a link for that? I'm not sure where I can find JSR 166 upstream repo.. > Nit: The above formatting (line 70-97) is inconsistent with the formatting in > line 110-124. It'd be good to use the same formatting. Restored. - PR: https://git.openjdk.java.net/jdk/pull/4507
Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v9]
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex > by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in > the whole JDK codebase. Yi Yang has updated the pull request incrementally with four additional commits since the last revision: - restore code format - restore code format - restore code format - restore code format - Changes: - all: https://git.openjdk.java.net/jdk/pull/4507/files - new: https://git.openjdk.java.net/jdk/pull/4507/files/ab1b509d..f43ffc3a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4507=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4507=07-08 Stats: 58 lines in 2 files changed: 0 ins; 10 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/4507.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507 PR: https://git.openjdk.java.net/jdk/pull/4507
Withdrawn: 8266578: Disambiguate BigDecimal description of scale
On Fri, 9 Oct 2020 16:14:59 GMT, Ignasi Marimon-Clos wrote: > The API Docs for `BigDecimal` introduce the meaning of `scale`. The current > writeup can be missleading when presenting the meaning of a `scale` value > that's negative. Hopefully, with this PR, the sentence is more clear. > > The ambiguity is on this sentence: > >> If negative, the unscaled value of the number is ... > > Instead, I suggest the more verbose: > >> If the scale is negative, the unscaled value of the number is ... > > To keep symmetry, I've also reviewed the positive case from: > >> If zero or positive, the scale is the number of digits ... > > to: > >> If the scale is zero or positive, the scale is the number of digits ... This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/582
Integrated: 8266407: remove jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES
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 safely removed > it. This is the intention of this patch. > > TIA, > Vicente This pull request has now been integrated. Changeset: 01c29d8f Author:Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/01c29d8f2c865009c0d5379ba2e2cd4d3015f018 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod 8266407: remove jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES Reviewed-by: jlahoda - PR: https://git.openjdk.java.net/jdk/pull/4578
Re: RFR: Merge jdk17 [v2]
> Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 164 commits: - Merge - 8269935: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on windows Reviewed-by: jjg - 8269917: Insert missing commas in copyrights in java.net Reviewed-by: chegar, dfuchs - 8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation Reviewed-by: alanb, dfuchs, chegar - 8269692: sun.net.httpserver.ServerImpl::createContext should throw IAE Reviewed-by: dfuchs - 8269697: JNI_GetPrimitiveArrayCritical() should not accept object array Reviewed-by: kbarrett, dholmes - 8266310: deadlock between System.loadLibrary and JNI FindClass loading another class Reviewed-by: dholmes, plevart, chegar, mchung - 8269882: stack-use-after-scope in NewObjectA Reviewed-by: kbarrett - 8269672: C1: Remove unaligned move on all architectures Co-authored-by: Martin Doerr Reviewed-by: thartmann - 8267956: C1 code cleanup Reviewed-by: thartmann - ... and 154 more: https://git.openjdk.java.net/jdk/compare/0d1cd3a7...b68ba015 - Changes: https://git.openjdk.java.net/jdk/pull/4698/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4698=01 Stats: 46385 lines in 833 files changed: 20688 ins; 22823 del; 2874 mod Patch: https://git.openjdk.java.net/jdk/pull/4698.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4698/head:pull/4698 PR: https://git.openjdk.java.net/jdk/pull/4698
Integrated: Merge jdk17
On Tue, 6 Jul 2021 22:16:07 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 7a4f08ae Author:Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/7a4f08ae32ede32beb05f6e5e0a266943b91b1ee Stats: 3666 lines in 51 files changed: 2827 ins; 351 del; 488 mod Merge - PR: https://git.openjdk.java.net/jdk/pull/4698
RFR: Merge jdk17
Forwardport JDK 17 -> JDK 18 - Commit messages: - Merge - 8269825: [TESTBUG] Missing testing for x86 KNL platforms - 8269955: ProblemList compiler/vectorapi/VectorCastShape[64|128]Test.java tests on x86 - 8268966: AArch64: 'bad AD file' in some vector conversion tests - 8225667: Clarify the behavior of System::gc w.r.t. reference processing - 8269568: JVM crashes when running VectorMask query tests - 8269661: JNI_GetStringCritical does not lock char array - 8269575: C2: assert(false) failed: graph should be schedulable after JDK-8252372 - 8268883: C2: assert(false) failed: unscheduable graph - 8268369: SIGSEGV in PhaseCFG::implicit_null_check due to missing null check The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk=4698=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk=4698=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4698/files Stats: 3666 lines in 51 files changed: 2827 ins; 351 del; 488 mod Patch: https://git.openjdk.java.net/jdk/pull/4698.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4698/head:pull/4698 PR: https://git.openjdk.java.net/jdk/pull/4698
Withdrawn: 8266013: Unexpected replacement character handling on stateful CharsetEncoder
On Tue, 27 Apr 2021 16:49:08 GMT, Ichiroh Takiguchi wrote: > When an invalid character is converted by getBytes() method, the character is > converted to replacement byte data. > Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset. > EBCDIC Mix charset encoder is stateful encoder. > Shift code should be added by switching character set. > On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", > but "\x0E\x40\x40\x6F\x0F" > SI is not in right place. > > Also ISO2022 related charsets use escape sequence to switch character set. > But same kind of issue is there. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/3719
Re: RFR: 8266407: remove jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES
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 safely removed > it. This is the intention of this patch. > > TIA, > Vicente lgtm - Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4578
Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v8]
On Wed, 23 Jun 2021 03:54:55 GMT, Yi Yang wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of >> checkIndex by >> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in >> the whole JDK codebase. > > Yi Yang has updated the pull request incrementally with one additional commit > since the last revision: > > tests rely on IOOBE exception message I suggest to separate the client changes (both src and test) in a separate PR for the client review. I review the rest of the files, which looks okay to me. I will take another pass carefully. src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo.Better to file a separate issue for this change to ensure that gets fixed in the upstream project. test/jdk/java/lang/StringBuffer/Exceptions.java line 73: > 71: new StringBuffer(); > 72: } > 73: }); Nit: The above formatting (line 70-97) is inconsistent with the formatting in line 110-124. It'd be good to use the same formatting. test/jdk/java/lang/StringBuilder/Exceptions.java line 73: > 71: new StringBuilder(); > 72: } > 73: }); Nit: it'd be good to make the formatting of all calls to tryCatch method consistent. - PR: https://git.openjdk.java.net/jdk/pull/4507
Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible
On Mon, 5 Jul 2021 06:29:58 GMT, David Holmes wrote: >> @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest >> version? Thanks. > > @kelthuzadx I did not see any response to my query about the change in > initialization (not load) order. I also remain concerned about introducing > cross dependencies between core classes (e.g. String now uses Precondition, > so does that impact Precondition using String?) But these are things for the > core-libs folk to be concerned about, or not. > > Cheers, > David > @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest > version? Thanks. Alan and Paul are currently on vacation. I'm reviewing it. - PR: https://git.openjdk.java.net/jdk/pull/4507
Re: [jdk17] RFR: 8269185: Directories in /opt/runtimepackagetest and /path/to/jdk-17 are different
On Sat, 3 Jul 2021 00:03:55 GMT, Alexander Matveev wrote: >> Disable stripping to prevent rpmbuild from modifying executables > > Marked as reviewed by almatvee (Reviewer). @sashamatveev @herrick please review - PR: https://git.openjdk.java.net/jdk17/pull/207
Re: RFR: 8214761: Bug in parallel Kahan summation implementation
On Fri, 2 Jul 2021 21:30:56 GMT, stefan-zobel wrote: >> 8214761: Bug in parallel Kahan summation implementation > > src/java.base/share/classes/java/util/DoubleSummaryStatistics.java line 161: > >> 159: >> 160: //Negating this value because low-order bits are in negated form >> 161: sumWithCompensation(-other.sumCompensation); > > Wouldn't that be `double tmp = sum - sumCompensation;` in getSum() in line > 246 too? Good catch will review and make the change. - PR: https://git.openjdk.java.net/jdk/pull/4674
Re: RFR: 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available [v5]
> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found
> out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like
> `baseName.replace('.', '/') + '/' + name` are not compiled into
> `invokedynamic`-based code, but into one using `StringBuilder`. This happens
> due to some bootstraping issues.
>
> However the code like
>
> private String getSimpleName0() {
> if (isArray()) {
> return getComponentType().getSimpleName() + "[]";
> }
> //...
> }
>
> can be improved via replacement of `+` with `String.concat()` call.
>
> I've used this benchmark to measure impact:
>
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassMethodsBenchmark {
> private final Class arrayClass = Object[].class;
> private Method descriptorString;
>
> @Setup
> public void setUp() throws NoSuchMethodException {
> //fore some reason compiler doesn't allow me to call
> Class.descriptorString() directly
> descriptorString = Class.class.getDeclaredMethod("descriptorString");
> }
>
> @Benchmark
> public Object descriptorString() throws Exception {
> return descriptorString.invoke(arrayClass);
> }
>
> @Benchmark
> public Object typeName() {
> return arrayClass.getTypeName();
> }
> }
>
> and got those results
>
>Mode Cnt Score
> Error Units
> descriptorString avgt 6091.480 ±
> 1.839 ns/op
> descriptorString:·gc.alloc.rate.norm avgt 60 404.008 ±
> 4.033B/op
> descriptorString:·gc.churn.G1_Eden_Space avgt 60 2791.866 ±
> 181.589 MB/sec
> descriptorString:·gc.churn.G1_Eden_Space.norm avgt 60 401.702 ±
> 26.047B/op
> descriptorString:·gc.churn.G1_Survivor_Space avgt 60 0.003 ±
> 0.001 MB/sec
> descriptorString:·gc.churn.G1_Survivor_Space.norm avgt 60≈ 10⁻³
> B/op
> descriptorString:·gc.count avgt 60 205.000
> counts
> descriptorString:·gc.time avgt 60 216.000
> ms
>
> patched
>Mode Cnt Score
> Error Units
> descriptorString avgt 6065.016 ±
> 3.446 ns/op
> descriptorString:·gc.alloc.rateavgt 60 2844.240 ±
> 115.719 MB/sec
> descriptorString:·gc.alloc.rate.norm avgt 60 288.006 ±
> 0.001B/op
> descriptorString:·gc.churn.G1_Eden_Space avgt 60 2832.996 ±
> 206.939 MB/sec
> descriptorString:·gc.churn.G1_Eden_Space.norm avgt 60 286.955 ±
> 17.853B/op
> descriptorString:·gc.churn.G1_Survivor_Space avgt 60 0.003 ±
> 0.001 MB/sec
> descriptorString:·gc.churn.G1_Survivor_Space.norm avgt 60≈ 10⁻³
> B/op
> descriptorString:·gc.count avgt 60 208.000
> counts
> descriptorString:·gc.time avgt 60 228.000
> ms
> -
> typeName avgt 6034.273 ±
> 0.480 ns/op
> typeName:·gc.alloc.rateavgt 60 3265.356 ±
> 45.113 MB/sec
> typeName:·gc.alloc.rate.norm avgt 60 176.004 ±
> 0.001B/op
> typeName:·gc.churn.G1_Eden_Space avgt 60 3268.454 ±
> 134.458 MB/sec
> typeName:·gc.churn.G1_Eden_Space.norm avgt 60 176.109 ±
> 6.595B/op
> typeName:·gc.churn.G1_Survivor_Space avgt 60 0.003 ±
> 0.001 MB/sec
> typeName:·gc.churn.G1_Survivor_Space.norm avgt 60≈ 10⁻⁴
> B/op
> typeName:·gc.count avgt 60 240.000
> counts
> typeName:·gc.time avgt 60 255.000
> ms
>
> patched
>
> typeName avgt 6015.787 ±
> 0.214 ns/op
> typeName:·gc.alloc.rateavgt 60 2577.554 ±
> 32.339 MB/sec
> typeName:·gc.alloc.rate.norm avgt 6064.001 ±
> 0.001B/op
> typeName:·gc.churn.G1_Eden_Space avgt 60 2574.039 ±
> 147.774 MB/sec
> typeName:·gc.churn.G1_Eden_Space.norm avgt 6063.895 ±
> 3.511B/op
> typeName:·gc.churn.G1_Survivor_Space avgt 60 0.003 ±
> 0.001 MB/sec
> typeName:·gc.churn.G1_Survivor_Space.norm avgt 60≈ 10⁻⁴
> B/op
> typeName:·gc.count avgt 60 189.000
> counts
> typeName:·gc.time avgt 60 199.000
> ms
>
> I think this patch is likely to improve
[jdk17] Integrated: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing
On Wed, 30 Jun 2021 18:24:24 GMT, Mandy Chung wrote: > This spec clarification is a follow-up to > [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) > w.r.t. reference processing. Since there is no guarantee for any memory > reclamation by the invocation of `System::gc`, the spec should also clarify > that there is no guarantee in determining the change of reachability of any > objects or any particular number of `Reference` objects be enqueued and > cleared. > > CSR: >https://bugs.openjdk.java.net/browse/JDK-8269690 This pull request has now been integrated. Changeset: 3a690240 Author:Mandy Chung URL: https://git.openjdk.java.net/jdk17/commit/3a690240336bda8582a15ca52f4dcb78be323dcd Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod 8225667: Clarify the behavior of System::gc w.r.t. reference processing Reviewed-by: rriggs, kbarrett, tschatzl - PR: https://git.openjdk.java.net/jdk17/pull/183
Re: RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError
Hello, I should be able to look at this within the next week or two; thanks, -Joe On 7/6/2021 1:22 AM, Sergei Ustimenko wrote: On Wed, 30 Jun 2021 20:08:27 GMT, Sergei Ustimenko wrote: Change #3294 helps to avoid `AnnotaionFormatException` in `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. While it fixes the case with e.g. `Runnable` that generates the synthetic method without parameters, validation still fails on synthetic methods that have parameters e.g. `Function`, `BiFunction`, etc. This change removes the restriction on parameters count to be zero i.e. lambdas with parameters would be skipped from validation. Hi, I would appreciate if anyone could take a look and let me know their opinion. Removing the `parameters count == 0` condition from the sun.reflect.annotation.AnnotationInvocationHandler:507 fixes the problem, though I'm not entirely sure if it brings some risks with it. - PR: https://git.openjdk.java.net/jdk/pull/4642
Integrated: 8266310: deadlock between System.loadLibrary and JNI FindClass loading another class
On Tue, 11 May 2021 13:10:30 GMT, Aleksei Voitylov wrote: > Please review this PR which fixes the deadlock in ClassLoader between the two > lock objects - a lock object associated with the class being loaded, and the > ClassLoader.loadedLibraryNames hash map, locked during the native library > load operation. > > Problem being fixed: > > The initial reproducer demonstrated a deadlock between the JarFile/ZipFile > and the hash map. That deadlock exists even when the ZipFile/JarFile lock is > removed because there's another lock object in the class loader, associated > with the name of the class being loaded. Such objects are stored in > ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads > exactly the same class, whose signature is being verified in another thread. > > Proposed fix: > > The proposed patch suggests to get rid of locking loadedLibraryNames hash map > and synchronize on each entry name, as it's done with class names in see > ClassLoader.getClassLoadingLock(name) method. > > The patch introduces nativeLibraryLockMap which holds the lock objects for > each library name, and the getNativeLibraryLock() private method is used to > lazily initialize the corresponding lock object. nativeLibraryContext was > changed to ThreadLocal, so that in any concurrent thread it would have a > NativeLibrary object on top of the stack, that's being currently > loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of > all native libraries loaded - in line with class loading code, it is not > explicitly cleared. > > Testing: jtreg and jck testing with no regressions. A new regression test > was developed. This pull request has now been integrated. Changeset: e47803a8 Author:Aleksei Voitylov Committer: Alexander Scherbatiy URL: https://git.openjdk.java.net/jdk/commit/e47803a84feb6d831c6c6158708d29b4fffc99c9 Stats: 913 lines in 10 files changed: 894 ins; 1 del; 18 mod 8266310: deadlock between System.loadLibrary and JNI FindClass loading another class Reviewed-by: dholmes, plevart, chegar, mchung - PR: https://git.openjdk.java.net/jdk/pull/3976
Re: [jdk17] RFR: 8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available"
On Mon, 5 Jul 2021 11:21:39 GMT, Daniel Fuchs wrote: > Please find here a trivial fix for: > > 8269772: [macos-aarch64] test compilation failed with "SocketException: No > buffer space available" > > Running several of the websocket tests concurrently on some of the CI > machines is causing resource exhaustion, because resources are only freed > after the TIMED_WAIT delay has expired once the tests have finished. > The proposed solution is to run these tests in exclusive dir mode. Marked as reviewed by chegar (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/210
Re: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v6]
On Wed, 30 Jun 2021 10:23:32 GMT, Jan Lahoda wrote:
>> Currently, an enum switch with patterns is desugared in a very non-standard,
>> and potentially slow, way. It would be better to use the standard
>> `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs
>> to accept enum constants as labels in order to allow this. A complication is
>> that if an enum constant is missing, that is not an incompatible change for
>> the switch, and the switch should simply work as if the case for the missing
>> constant didn't exist. So, the proposed solution is to have a new bootstrap
>> `enumSwitch` that accepts `String`s in place of the enum constants, and will
>> internally convert them to the appropriate enum constants, and then it will
>> find the proper case similarly to `typeSwitch`.
>>
>> How does this look?
>
> Jan Lahoda has updated the pull request with a new target base due to a merge
> or a rebase. The pull request now contains ten commits:
>
> - Reflecting review comments.
> - Merge branch 'master' into JDK-8268766
> - Improving javadoc.
> - Updating javadoc, as suggested.
> - Updating javadoc, code and tests as suggested.
> - Creating a new bootstrap method for (pattern matching) enum switches, as
> suggested.
> - Adding and fixing test.
> - Merging master.
> - 8268766: Desugaring of pattern matching enum switch should be improved
Looks good - added minor cosmetic comments
src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 205:
> 203: *
> 204: * @param lookup Represents a lookup context with the accessibility
> 205: * privileges of the caller. When used with {@code
> invokedynamic},
Suggestion:
* privileges of the caller. When used with {@code
invokedynamic},
src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 216:
> 214: * @throws NullPointerException if any argument is {@code null}
> 215: * @throws IllegalArgumentException if any element in the labels
> array is null, if the
> 216: * invocation type is not a method type of first parameter of an
> enum type,
Suggestion:
* invocation type is not a method type whose first parameter type is an
enum type,
src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 217:
> 215: * @throws IllegalArgumentException if any element in the labels
> array is null, if the
> 216: * invocation type is not a method type of first parameter of an
> enum type,
> 217: * second parameter of type {@code int} and with {@code int} as its
> return type,
Suggestion:
* second parameter of type {@code int} and whose return type is {@code
int},
-
Marked as reviewed by mcimadamore (Reviewer).
PR: https://git.openjdk.java.net/jdk17/pull/81
Re: RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError
On Wed, 30 Jun 2021 20:08:27 GMT, Sergei Ustimenko wrote: > Change #3294 helps to avoid `AnnotaionFormatException` in > `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. > While it fixes the case with e.g. `Runnable` that generates the synthetic > method without parameters, validation still fails on synthetic methods that > have parameters e.g. `Function`, `BiFunction`, etc. > > This change removes the restriction on parameters count to be zero i.e. > lambdas with parameters > would be skipped from validation. Hi, I would appreciate if anyone could take a look and let me know their opinion. Removing the `parameters count == 0` condition from the sun.reflect.annotation.AnnotationInvocationHandler:507 fixes the problem, though I'm not entirely sure if it brings some risks with it. - PR: https://git.openjdk.java.net/jdk/pull/4642
