On Wed, 8 Jun 2022 18:24:35 GMT, Paul Sandoz wrote:
>> Allow JDK modules that use preview features (preview language features or
>> preview API features from dependent modules) to participate without the need
>> to compile with `--enable-preview`.
>>
>> It's difficult to enable participation
On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona wrote:
>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its
>> dependencies
>> fails to run java source launcher correctly (for example when --source N is
>> specified).
>> Failing source
On Tue, 3 May 2022 12:07:50 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/~gbie
rns is very
> straightforward - effectivelly the record patterns are desugared into
> guards/conditions. This will likely be improved in some future version/preview
>
> `MatchException` has been extended to cover additional cases related to
> record patterns.
Jan Lahoda has update
On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona wrote:
>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its
>> dependencies
>> fails to run java source launcher correctly (for example when --source N is
>> specified).
>> Failing source
On Fri, 20 May 2022 09:51:24 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> Patch adds the planned support for new vector operations and APIs targeted
>> for [JEP 426: Vector API (Fourth
>> Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>>
>> Following is the brief summary of
rns is very
> straightforward - effectivelly the record patterns are desugared into
> guards/conditions. This will likely be improved in some future version/preview
>
> `MatchException` has been extended to cover additional cases related to
> record patterns.
Jan Lahoda has update
On Mon, 11 Apr 2022 16:37:03 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/PatternSwitchPlu
f a switch has `case
> null`, it is used, otherwise a NPE is thrown), rather than on pattern
> matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is
> exhaustive (due to sealed types) at compile-time, but not
f a switch has `case
> null`, it is used, otherwise a NPE is thrown), rather than on pattern
> matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is
> exhaustive (due to sealed types) at compile-time, but not
On Fri, 13 May 2022 09:29:20 GMT, Maurizio Cimadamore
wrote:
>> Jan Lahoda has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Updating naming to more closely follow the spec: total patterns are
>> ren
f a switch has `case
> null`, it is used, otherwise a NPE is thrown), rather than on pattern
> matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is
> exhaustive (due to sealed types) at compile-time, but not
rns is very
> straightforward - effectivelly the record patterns are desugared into
> guards/conditions. This will likely be improved in some future version/preview
>
> `MatchException` has been extended to cover additional cases related to
> record patterns.
Jan Lahoda has up
On Mon, 9 May 2022 20:52:15 GMT, Vicente Romero wrote:
> I've noticed that this code:
>
> ```
> class Test {
> String e(E e) {
> return switch (e) {
> case A -> "42";
> };
> }
>
> enum E {
> A, B;
> }
> }
> ```
>
> fails with:
>
> ```
>
rns is very
> straightforward - effectivelly the record patterns are desugared into
> guards/conditions. This will likely be improved in some future version/preview
>
> `MatchException` has been extended to cover additional cases related to
> record patterns.
Jan Lahoda has update
f a switch has `case
> null`, it is used, otherwise a NPE is thrown), rather than on pattern
> matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is
> exhaustive (due to sealed types) at compile-time, but not
rns is very
> straightforward - effectivelly the record patterns are desugared into
> guards/conditions. This will likely be improved in some future version/preview
>
> `MatchException` has been extended to cover additional cases related to
> record patterns.
Jan Lahoda has up
On Fri, 6 May 2022 14:30:10 GMT, Maurizio Cimadamore
wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflecting review feedback.
>
> src/jdk.compiler/share/classes/com/sun/tools
On Thu, 5 May 2022 18:11:54 GMT, Vicente Romero wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflecting review feedback.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/A
On Fri, 6 May 2022 15:44:22 GMT, Gavin Bierman wrote:
> > From the JLS specdiff
> > > If the type R names a generic record class then it is a compile-time
> > > error if R is not a parameterized type.
> >
> >
> > The following snippet raises a `MatchException`. Shouldn't it be a
> >
rns is very
> straightforward - effectivelly the record patterns are desugared into
> guards/conditions. This will likely be improved in some future version/preview
>
> `MatchException` has been extended to cover additional cases related to
> record patterns.
Jan Lahoda has up
On Wed, 4 May 2022 10:03:13 GMT, Maurizio Cimadamore
wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4180:
>>
>>> 4178: type = attribTree(tree.var.vartype, env, varInfo);
>>> 4179: } else {
>>> 4180: type = resultInfo.pt;
>>
>>
On Thu, 5 May 2022 15:17:11 GMT, Maurizio Cimadamore
wrote:
>> You are right. It is the ii) which iteratively checks the component pattern
>> list L.
>
> I now believe that the check is needed to properly classify patterns based on
> the type of the i-th component. That said, not sure this
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/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
f a switch has `case
> null`, it is used, otherwise a NPE is thrown), rather than on pattern
> matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is
> exhaustive (due to sealed types) at compile-time, but not
f a switch has `case
> null`, it is used, otherwise a NPE is thrown), rather than on pattern
> matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is
> exhaustive (due to sealed types) at compile-time, but not
f a switch has `case
> null`, it is used, otherwise a NPE is thrown), rather than on pattern
> matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is
> exhaustive (due to sealed types) at compile-time, but not
f a switch has `case
> null`, it is used, otherwise a NPE is thrown), rather than on pattern
> matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is
> exhaustive (due to sealed types) at compile-time, but not
On Wed, 20 Apr 2022 14:50:42 GMT, Vicente Romero wrote:
> nit: just ran langtools tests as part of my routine and these seem to be
> failing, `CheckExamples.java` due to:
>
> ```
> test/langtools/tools/javac/diags/examples/FeatureTotalPatternsInInstanceof.java
> and
>
f a switch has `case
> null`, it is used, otherwise a NPE is thrown), rather than on pattern
> matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is
> exhaustive (due to sealed types) at compile-time, but not
On Fri, 15 Apr 2022 15:36:35 GMT, Vicente Romero 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/comp/A
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/P
f a switch has `case
> null`, it is used, otherwise a NPE is thrown), rather than on pattern
> matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is
> exhaustive (due to sealed types) at compile-time, but not
f a switch has `case
> null`, it is used, otherwise a NPE is thrown), rather than on pattern
> matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is
> exhaustive (due to sealed types) at compile-time, but not
f a switch has `case
> null`, it is used, otherwise a NPE is thrown), rather than on pattern
> matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is
> exhaustive (due to sealed types) at compile-time, but not
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/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
The
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, there are only
On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead,
>> please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in
On Thu, 23 Sep 2021 14:43:21 GMT, Jan Lahoda wrote:
> I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt
> terminal (see JDK-8270943), and to generally use a newer version of the
> library. This patch is basically a application of relevant parts of the diff
> b
On Thu, 23 Sep 2021 15:43:08 GMT, Athijegannathan Sundararajan
wrote:
>> I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt
>> terminal (see JDK-8270943), and to generally use a newer version of the
>> library. This patch is basically a application of relevant parts of the
On Mon, 4 Oct 2021 08:47:26 GMT, Ichiroh Takiguchi
wrote:
>> The encoding used in `Log.java` should first check whether it is run within
>> console or not. If `System.console()` returns the console, its `.charset()`
>> should be used instead of `native.encoding` value.
>> As to the jshell
On Fri, 1 Oct 2021 11:56:03 GMT, Jan Lahoda wrote:
> Regarding javac, the patch to `Log.java` seems to be in a reasonable
> direction: the write is to the physical `System.out/err` which should be
> done(?) using the native encoding. The order of the changed lines should be
&g
On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi
wrote:
> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled
> on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.
I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt terminal
(see JDK-8270943), and to generally use a newer version of the library. This
patch is basically a application of relevant parts of the diff between JLine
3.14.0 and 3.20.0, with merge fixes as needed.
Thanks!
On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev wrote:
> This is a GUI test, and it should be `@headful`.
>
> Additional testing:
> - [x] Test still runs in default, and does not run with `!headful`
Marked as reviewed by jlahoda (Reviewer).
-
PR:
On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev wrote:
> This is a GUI test, and it should be `@headful`.
>
> Additional testing:
> - [x] Test still runs in default, and does not run with `!headful`
Marking the test headful if OK - but should `headful` also be added to the keys
in
On Thu, 15 Jul 2021 12:07:42 GMT, Jan Lahoda wrote:
> Removing unnecessary `@SuppressWarnings("exports")`. The reason for the
> suppress warnings was, as far as I can tell, removed by
> https://bugs.openjdk.java.net/browse/JDK-8265137.
This pull request has now been int
Removing unnecessary `@SuppressWarnings("exports")`. The reason for the
suppress warnings was, as far as I can tell, removed by
https://bugs.openjdk.java.net/browse/JDK-8265137.
-
Commit messages:
- 8270547: java.util.Random contains unnecessary @SuppressWarnings("exports")
On Wed, 16 Jun 2021 15:15:25 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
>
cepts `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 incrementally with one additional
commi
On Wed, 7 Jul 2021 12:10:16 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 n
cepts `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 incrementally with one additi
cepts `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 incrementally with one additional
comm
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
cepts `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 merg
s the enum constant name to the enum constant,
> returning `null`, if the constant does not exist. It delegates to
> `ConstantBootstraps.enumConstant` to do the actual conversion. And
> `typeSwitch` accepts `null`s as padding.
>
> How does this look?
Jan Lahoda has updated
On Tue, 22 Jun 2021 20:43:03 GMT, Maurizio Cimadamore
wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updating javadoc, as suggested.
>
> src/java.base/share/classes/java/lang/runtime/
s the enum constant name to the enum constant,
> returning `null`, if the constant does not exist. It delegates to
> `ConstantBootstraps.enumConstant` to do the actual conversion. And
> `typeSwitch` accepts `null`s as padding.
>
> How does this look?
Jan Lahoda has updated
On Fri, 18 Jun 2021 14:35:42 GMT, Maurizio Cimadamore
wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updating javadoc, code and tests as suggested.
>
> src/java.base/s
s the enum constant name to the enum constant,
> returning `null`, if the constant does not exist. It delegates to
> `ConstantBootstraps.enumConstant` to do the actual conversion. And
> `typeSwitch` accepts `null`s as padding.
>
> How does this look?
Jan Lahoda has updated
On Thu, 17 Jun 2021 21:21:14 GMT, Maurizio Cimadamore
wrote:
> Very good piece of work. I like all the code that can be removed because of
> this.
Thanks!
>
> I assume that the new code only kicks in if there's at least a pattern in the
> switch, otherwise we fallback to legacy translation
On Thu, 17 Jun 2021 21:56:21 GMT, Rémi Forax wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Creating a new bootstrap method for (pattern matching) enum switches, as
>> suggested.
&
On Thu, 17 Jun 2021 21:03:58 GMT, Maurizio Cimadamore
wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Creating a new bootstrap method for (pattern matching) enum switches, as
>> sugg
s the enum constant name to the enum constant,
> returning `null`, if the constant does not exist. It delegates to
> `ConstantBootstraps.enumConstant` to do the actual conversion. And
> `typeSwitch` accepts `null`s as padding.
>
> How does this look?
Jan Lahoda has updated
On Wed, 16 Jun 2021 15:15:25 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
>
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
Thanks for the report, Remi.
I believe the specification currently allows this (default does not have
to be last, and does not dominate anything), so javac should be able to
handle this code. I've filled:
https://bugs.openjdk.java.net/browse/JDK-8268333
Jan
On 07. 06. 21 11:54, Remi
Hi Remi,
Thanks. I've filled:
https://bugs.openjdk.java.net/browse/JDK-8268320
FWIW, I think compiler-dev is a better place for reports like this.
Jan
On 07. 06. 21 11:03, Remi Forax wrote:
Hi all,
with this code
sealed interface Vehicle {}
record Car(String owner, String color)
On Tue, 4 May 2021 16:41:44 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.ne
On Fri, 4 Jun 2021 18:23:28 GMT, Vicente Romero wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixing typo.
>
> test/langtools/tools/javac/patterns/SealedTypeChanges.java line 71:
>
null`/`case null, String s`/`case
> null: case String s:`/`case String s: case null:`, handling of these required
> a few tricks in `Attr`, `Flow` and `TransPatterns`.
>
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdi
On Fri, 4 Jun 2021 15:46:32 GMT, Paul Sandoz wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixing typo.
>
> test/langtools/tools/javac/patterns/DisambiguateParenthesizedPat
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:
>>
null`/`case null, String s`/`case
> null: case String s:`/`case String s: case null:`, handling of these required
> a few tricks in `Attr`, `Flow` and `TransPatterns`.
>
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdi
null`/`case null, String s`/`case
> null: case String s:`/`case String s: case null:`, handling of these required
> a few tricks in `Attr`, `Flow` and `TransPatterns`.
>
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdi
null`/`case null, String s`/`case
> null: case String s:`/`case String s: case null:`, handling of these required
> a few tricks in `Attr`, `Flow` and `TransPatterns`.
>
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.p
null`/`case null, String s`/`case
> null: case String s:`/`case String s: case null:`, handling of these required
> a few tricks in `Attr`, `Flow` and `TransPatterns`.
>
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdi
null`/`case null, String s`/`case
> null: case String s:`/`case String s: case null:`, handling of these required
> a few tricks in `Attr`, `Flow` and `TransPatterns`.
>
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdi
null`/`case null, String s`/`case
> null: case String s:`/`case String s: case null:`, handling of these required
> a few tricks in `Attr`, `Flow` and `TransPatterns`.
>
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff
On Thu, 27 May 2021 10:38:08 GMT, Maurizio Cimadamore
wrote:
>> Jan Lahoda has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 12 commits:
>>
>> - Post-merge fix - need to include jdk.internal.javac in the l
null`/`case null, String s`/`case
> null: case String s:`/`case String s: case null:`, handling of these required
> a few tricks in `Attr`, `Flow` and `TransPatterns`.
>
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdi
On Thu, 27 May 2021 18:28:13 GMT, Evgeny Mandrikov wrote:
>>> > I've updated the code to produce better/more useful LineNumberTable for
>>> > rule switches.
>>>
>>> @lahodaj I re-tested previous example and tested few others. Now everything
>>> seems to be good with `LineNumberTable` entries
On Wed, 26 May 2021 17:52:36 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:
>>
null`/`case null, String s`/`case
> null: case String s:`/`case String s: case null:`, handling of these required
> a few tricks in `Attr`, `Flow` and `TransPatterns`.
>
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.p
On Tue, 25 May 2021 16:00:43 GMT, Rémi Forax wrote:
> > The reason for this integer (which is not a constant in the case of this
> > switch) is to restart the matching in case guards fail to "match".
> > Considering the example here:
> > ```
> > class Example {
> > void example(Object
On Tue, 25 May 2021 14:13:55 GMT, Rémi Forax wrote:
> > Thanks Evgeny, I'll take a look.
> > @forax, do you mean why there is "0" in:
> > 11: invokedynamic #13, 0
> > ?
>
> Not this one, the one on the stack.
>
> 7: iconst_0 < this zero
> 8: istore_3
> 9: aload_2
> 10: iload_3
> 11:
On Wed, 19 May 2021 08:00:12 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:
>>
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
Looks good.
-
null`/`case null, String s`/`case
> null: case String s:`/`case String s: case null:`, handling of these required
> a few tricks in `Attr`, `Flow` and `TransPatterns`.
>
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdi
null`/`case null, String s`/`case
> null: case String s:`/`case String s: case null:`, handling of these required
> a few tricks in `Attr`, `Flow` and `TransPatterns`.
>
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdi
null`/`case null, String s`/`case
> null: case String s:`/`case String s: case null:`, handling of these required
> a few tricks in `Attr`, `Flow` and `TransPatterns`.
>
> The specdiff for the change is here (to be updated):
> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff
On Tue, 4 May 2021 20:48:34 GMT, Maurizio Cimadamore
wrote:
>> Jan Lahoda has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Reflecting recent spec changes.
>> - Reflecting review comments.
&g
On Tue, 4 May 2021 20:48:34 GMT, Maurizio Cimadamore
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:
>>
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/jep406/jep406-20210430/specs/patterns-switch-jls.html
A summary of
On Wed, 5 May 2021 05:26:47 GMT, Srikanth Adayapalam
wrote:
>> 8244146: javac changes for JEP 306
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line
> 1704:
>
>> 1702: if (Feature.REDUNDANT_STRICTFP.allowedInSource(source))
>> 1703: result =
On Sat, 1 May 2021 23:00:05 GMT, Joe Darcy wrote:
> 8244146: javac changes for JEP 306
src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java line 170:
> 168:
> 169: allOptions.add("--should-stop=at=FLOW");
> 170: allOptions.add("-Xlint:unchecked,-strictfp");
I wonder if
On Sun, 2 May 2021 02:10:26 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 removing preview
>>
On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti
wrote:
> Hello,
>
> here's a PR for a patch submitted on March 2020
> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a
> thing.
>
> The patch has been edited to adhere to OpenJDK code conventions about
>
On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti
wrote:
> Hello,
>
> here's a PR for a patch submitted on March 2020
> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a
> thing.
>
> The patch has been edited to adhere to OpenJDK code conventions about
>
On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti
wrote:
> Hello,
>
> here's a PR for a patch submitted on March 2020
> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a
> thing.
>
> The patch has been edited to adhere to OpenJDK code conventions about
>
1 - 100 of 267 matches
Mail list logo
