From jlahoda at openjdk.org  Wed Feb  1 12:07:39 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 1 Feb 2023 12:07:39 GMT
Subject: RFR: 8301580: Error recovery does not clear returnResult
Message-ID: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>

Considering code like:

class C {
    void m
    {
        return;
    }
}


`void m` is wrapped in an erroneous tree (which is good), and if/when `Attr` is processing it in `visitErroneous`, it will create a new `Env` to attribute the erroneous part.

But, `Attr` will set a `returnResult` into the `Env`'s info - and that info is shared with the outter `Env`, so there will be a `returnResult` set after `visitErroneous`. `{ return ; }` is interpreted as an initializer, and there should be an error for the `return` there, but this error is missing, due to the set `returnResult`. This will then fail later in `Flow` with an exception:


$ javac -XDshould-stop.at=FLOW -XDdev /tmp/C.java

-------------

Commit messages:
 - 8301580: Error recovery does not clear returnResult

Changes: https://git.openjdk.org/jdk/pull/12361/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12361&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301580
  Stats: 115 lines in 3 files changed: 109 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12361.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12361/head:pull/12361

PR: https://git.openjdk.org/jdk/pull/12361

From vromero at openjdk.org  Fri Feb  3 12:30:52 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 3 Feb 2023 12:30:52 GMT
Subject: RFR: 8301580: Error recovery does not clear returnResult
In-Reply-To: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
References: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
Message-ID: <XUakmFsBzo6aVQvNDofynHmF49j-caTdfkAb_zUxHYk=.ee9a129c-7286-4274-96b5-2a6cbf9dd46e@github.com>

On Wed, 1 Feb 2023 12:00:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
> class C {
>     void m
>     {
>         return;
>     }
> }
> 
> 
> `void m` is wrapped in an erroneous tree (which is good), and if/when `Attr` is processing it in `visitErroneous`, it will create a new `Env` to attribute the erroneous part.
> 
> But, `Attr` will set a `returnResult` into the `Env`'s info - and that info is shared with the outter `Env`, so there will be a `returnResult` set after `visitErroneous`. `{ return ; }` is interpreted as an initializer, and there should be an error for the `return` there, but this error is missing, due to the set `returnResult`. This will then fail later in `Flow` with an exception:
> 
> 
> $ javac -XDshould-stop.at=FLOW -XDdev /tmp/C.java

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5222:

> 5220:     public void visitErroneous(JCErroneous tree) {
> 5221:         if (tree.errs != null) {
> 5222:             Env<AttrContext> errEnv = env.dup(env.tree);

question: shouldn't we do: `env.dup(node, env.info.dup());` instead, that way both env's won't share the info?

-------------

PR: https://git.openjdk.org/jdk/pull/12361

From duke at openjdk.org  Fri Feb  3 17:41:31 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 3 Feb 2023 17:41:31 GMT
Subject: RFR: 8221580: Confusing diagnostic for assigning a static final field
 in a constructor
Message-ID: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>

When a program attempts to assign a value to a final field, javac reports `cannot assign a value to final variable x`.

If the field is `static`, the exact same error message is used, which can be confusing, because no mention is made of the field's `static`ness.

This change does two things:
* Refactor the error message so that arbitrary modifiers can be included, instead of hard-wiring `final`
* Include both `static final` in the error message in the case of `static final` variables.

So for a `static final` field the error is now `cannot assign a value to static final variable x`.

-------------

Commit messages:
 - Distinguish static fields in "can't assign to final variable" error message.
 - Refactor error message to display arbitrary modifiers, not just 'final'.

Changes: https://git.openjdk.org/jdk/pull/12411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12411&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8221580
  Stats: 25 lines in 11 files changed: 10 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/12411.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12411/head:pull/12411

PR: https://git.openjdk.org/jdk/pull/12411

From jlahoda at openjdk.org  Fri Feb  3 19:08:25 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 3 Feb 2023 19:08:25 GMT
Subject: RFR: 8301580: Error recovery does not clear returnResult [v2]
In-Reply-To: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
References: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
Message-ID: <_Mvu0bE4c3YmXhXRILWiywi-WJ8Hl2Cz-3n8rqCZjSU=.9d740933-ce65-4888-9532-dc1c237c4d25@github.com>

> Considering code like:
> 
> class C {
>     void m
>     {
>         return;
>     }
> }
> 
> 
> `void m` is wrapped in an erroneous tree (which is good), and if/when `Attr` is processing it in `visitErroneous`, it will create a new `Env` to attribute the erroneous part.
> 
> But, `Attr` will set a `returnResult` into the `Env`'s info - and that info is shared with the outter `Env`, so there will be a `returnResult` set after `visitErroneous`. `{ return ; }` is interpreted as an initializer, and there should be an error for the `return` there, but this error is missing, due to the set `returnResult`. This will then fail later in `Flow` with an exception:
> 
> 
> $ javac -XDshould-stop.at=FLOW -XDdev /tmp/C.java

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Using info.dup(), as suggested.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12361/files
  - new: https://git.openjdk.org/jdk/pull/12361/files/4acb0d43..06a70c81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12361&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12361&range=00-01

  Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12361.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12361/head:pull/12361

PR: https://git.openjdk.org/jdk/pull/12361

From jlahoda at openjdk.org  Fri Feb  3 19:08:25 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 3 Feb 2023 19:08:25 GMT
Subject: RFR: 8301580: Error recovery does not clear returnResult [v2]
In-Reply-To: <XUakmFsBzo6aVQvNDofynHmF49j-caTdfkAb_zUxHYk=.ee9a129c-7286-4274-96b5-2a6cbf9dd46e@github.com>
References: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
 <XUakmFsBzo6aVQvNDofynHmF49j-caTdfkAb_zUxHYk=.ee9a129c-7286-4274-96b5-2a6cbf9dd46e@github.com>
Message-ID: <HhFWK098JEwzi6K8pag1k3nxUi4HYyHHdXWhAhW5-Cc=.1d2bbed9-8900-4341-bb77-80a71b471272@github.com>

On Fri, 3 Feb 2023 12:26:16 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Using info.dup(), as suggested.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5222:
> 
>> 5220:     public void visitErroneous(JCErroneous tree) {
>> 5221:         if (tree.errs != null) {
>> 5222:             Env<AttrContext> errEnv = env.dup(env.tree);
> 
> question: shouldn't we do: `env.dup(node, env.info.dup());` instead, that way both env's won't share the info?

I was a little bit on the fence on this, as some code, like `Attr.attribClass` stores and re-sets the result, while other dupes the info. Let's dupe the info then. Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/12361

From vromero at openjdk.org  Fri Feb  3 20:19:50 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 3 Feb 2023 20:19:50 GMT
Subject: RFR: 8301580: Error recovery does not clear returnResult [v2]
In-Reply-To: <_Mvu0bE4c3YmXhXRILWiywi-WJ8Hl2Cz-3n8rqCZjSU=.9d740933-ce65-4888-9532-dc1c237c4d25@github.com>
References: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
 <_Mvu0bE4c3YmXhXRILWiywi-WJ8Hl2Cz-3n8rqCZjSU=.9d740933-ce65-4888-9532-dc1c237c4d25@github.com>
Message-ID: <9AHoBbCuzl4uNd4YEM5sqQQmgMoCq3uqD7-0P97OHVw=.2e3a401a-1d30-4013-afd0-15b590c5dd34@github.com>

On Fri, 3 Feb 2023 19:08:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Considering code like:
>> 
>> class C {
>>     void m
>>     {
>>         return;
>>     }
>> }
>> 
>> 
>> `void m` is wrapped in an erroneous tree (which is good), and if/when `Attr` is processing it in `visitErroneous`, it will create a new `Env` to attribute the erroneous part.
>> 
>> But, `Attr` will set a `returnResult` into the `Env`'s info - and that info is shared with the outter `Env`, so there will be a `returnResult` set after `visitErroneous`. `{ return ; }` is interpreted as an initializer, and there should be an error for the `return` there, but this error is missing, due to the set `returnResult`. This will then fail later in `Flow` with an exception:
>> 
>> 
>> $ javac -XDshould-stop.at=FLOW -XDdev /tmp/C.java
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using info.dup(), as suggested.

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12361

From vromero at openjdk.org  Fri Feb  3 20:19:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 3 Feb 2023 20:19:53 GMT
Subject: RFR: 8301580: Error recovery does not clear returnResult [v2]
In-Reply-To: <HhFWK098JEwzi6K8pag1k3nxUi4HYyHHdXWhAhW5-Cc=.1d2bbed9-8900-4341-bb77-80a71b471272@github.com>
References: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
 <XUakmFsBzo6aVQvNDofynHmF49j-caTdfkAb_zUxHYk=.ee9a129c-7286-4274-96b5-2a6cbf9dd46e@github.com>
 <HhFWK098JEwzi6K8pag1k3nxUi4HYyHHdXWhAhW5-Cc=.1d2bbed9-8900-4341-bb77-80a71b471272@github.com>
Message-ID: <JqM8SEPAqqXvmVqQULxoUkOEeqiCRQ6eqZjBM56dmJQ=.7d69ee01-7d61-4ec1-abd5-a686e96f869a@github.com>

On Fri, 3 Feb 2023 19:04:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5222:
>> 
>>> 5220:     public void visitErroneous(JCErroneous tree) {
>>> 5221:         if (tree.errs != null) {
>>> 5222:             Env<AttrContext> errEnv = env.dup(env.tree);
>> 
>> question: shouldn't we do: `env.dup(node, env.info.dup());` instead, that way both env's won't share the info?
>
> I was a little bit on the fence on this, as some code, like `Attr.attribClass` stores and re-sets the result, while other dupes the info. Let's dupe the info then. Thanks!

I see, I didn't realize of the other pattern, not duping the info, we should probably standardize what we do at some point

-------------

PR: https://git.openjdk.org/jdk/pull/12361

From vromero at openjdk.org  Mon Feb  6 04:20:50 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 6 Feb 2023 04:20:50 GMT
Subject: RFR: 8221580: Confusing diagnostic for assigning a static final
 field in a constructor
In-Reply-To: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>
References: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>
Message-ID: <RhysduexLGdOB-3Tpc_OaJr_gSQjuUw6DrdG7oLkD8E=.6352d82b-0593-4a54-affa-a67fc28b88c5@github.com>

On Fri, 3 Feb 2023 17:33:34 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> When a program attempts to assign a value to a final field, javac reports `cannot assign a value to final variable x`.
> 
> If the field is `static`, the exact same error message is used, which can be confusing, because no mention is made of the field's `static`ness.
> 
> This change does two things:
> * Refactor the error message so that arbitrary modifiers can be included, instead of hard-wiring `final`
> * Include both `static final` in the error message in the case of `static final` variables.
> 
> So for a `static final` field the error is now `cannot assign a value to static final variable x`.

looks good to me

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12411

From jlahoda at openjdk.org  Mon Feb  6 12:28:02 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 Feb 2023 12:28:02 GMT
Subject: Integrated: 8301580: Error recovery does not clear returnResult
In-Reply-To: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
References: <5pitppiKIdloYWKA9MOQpJWhSlMuKYbMOU4h1sJ-eqQ=.2b7c84f4-227c-4608-b60f-ac0d11a1ed1b@github.com>
Message-ID: <u0SbWMbgnorFs9dZcrOMflGF_RTf6sHeEWb1R84Z4oQ=.41011cc1-f239-4827-a30e-da41d77f5b4c@github.com>

On Wed, 1 Feb 2023 12:00:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
> class C {
>     void m
>     {
>         return;
>     }
> }
> 
> 
> `void m` is wrapped in an erroneous tree (which is good), and if/when `Attr` is processing it in `visitErroneous`, it will create a new `Env` to attribute the erroneous part.
> 
> But, `Attr` will set a `returnResult` into the `Env`'s info - and that info is shared with the outter `Env`, so there will be a `returnResult` set after `visitErroneous`. `{ return ; }` is interpreted as an initializer, and there should be an error for the `return` there, but this error is missing, due to the set `returnResult`. This will then fail later in `Flow` with an exception:
> 
> 
> $ javac -XDshould-stop.at=FLOW -XDdev /tmp/C.java

This pull request has now been integrated.

Changeset: 522fa132
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/522fa1327422e49eaa172d43185b3d85b2561036
Stats:     108 lines in 3 files changed: 104 ins; 0 del; 4 mod

8301580: Error recovery does not clear returnResult

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/12361

From duke at openjdk.org  Mon Feb  6 15:02:51 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 6 Feb 2023 15:02:51 GMT
Subject: RFR: 8221580: Confusing diagnostic for assigning a static final
 field in a constructor
In-Reply-To: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>
References: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>
Message-ID: <Pvri8Y1N1-58sAR2pzagg0GmozG1giiY84YXuhCM99c=.a896219d-8120-459e-b497-99cd6641ddd6@github.com>

On Fri, 3 Feb 2023 17:33:34 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> When a program attempts to assign a value to a final field, javac reports `cannot assign a value to final variable x`.
> 
> If the field is `static`, the exact same error message is used, which can be confusing, because no mention is made of the field's `static`ness.
> 
> This change does two things:
> * Refactor the error message so that arbitrary modifiers can be included, instead of hard-wiring `final`
> * Include both `static final` in the error message in the case of `static final` variables.
> 
> So for a `static final` field the error is now `cannot assign a value to static final variable x`.

Thanks for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/12411

From duke at openjdk.org  Mon Feb  6 18:26:00 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 6 Feb 2023 18:26:00 GMT
Subject: Integrated: 8221580: Confusing diagnostic for assigning a static final
 field in a constructor
In-Reply-To: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>
References: <VOJv0zjPJ5ubKy7RKH6Ekesk4PqDYR5ls4hmeLL2kqs=.1d1cf673-47bb-4bde-aaf0-702008c68dfd@github.com>
Message-ID: <o40v1e9WeruhMu1-dD_BkwtKiaMDIhxxbvmO0x5nfdM=.262b8830-6be2-49cb-986d-5716cba231ad@github.com>

On Fri, 3 Feb 2023 17:33:34 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> When a program attempts to assign a value to a final field, javac reports `cannot assign a value to final variable x`.
> 
> If the field is `static`, the exact same error message is used, which can be confusing, because no mention is made of the field's `static`ness.
> 
> This change does two things:
> * Refactor the error message so that arbitrary modifiers can be included, instead of hard-wiring `final`
> * Include both `static final` in the error message in the case of `static final` variables.
> 
> So for a `static final` field the error is now `cannot assign a value to static final variable x`.

This pull request has now been integrated.

Changeset: 8c01b6e6
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c01b6e66b1ce9f9df5a1d12c8717a9e3322948a
Stats:     25 lines in 11 files changed: 10 ins; 0 del; 15 mod

8221580: Confusing diagnostic for assigning a static final field in a constructor

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/12411

From jlaskey at openjdk.org  Fri Feb 10 13:37:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 13:37:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v35]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <qigcd9_Ho_hqmU70v4acg_P88mhLEFg3F95h8YcLEOM=.0fc23f0f-9fbb-4533-a25c-a26e9d3b9a07@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:

 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - Update @since
 - Requested changes #12
 - Seal Digits
 - Requested changes #11
 - Typo
 - ... and 40 more: https://git.openjdk.org/jdk/compare/c8ace482...264120a9

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=34
  Stats: 9519 lines in 81 files changed: 9356 ins; 28 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Feb 10 14:27:17 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 14:27:17 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v36]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <c3fzYf65-ppnmsSbC41mQMcksftq44h6USI6Jio0KSI=.2ba0037e-8a70-4420-8810-606b823e40bd@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Bring up to date

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/264120a9..665cded9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=34-35

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Feb 10 17:07:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 17:07:24 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v37]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <3Cffq9T2VOO7KsFUbANnyixAkxi4Ztlojk9voEvmF1I=.2ed8c2bf-e704-4661-9185-102ac3f15e7a@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  CSR review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/665cded9..8f5ad0a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=35-36

  Stats: 65 lines in 6 files changed: 55 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Feb 10 17:09:18 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 17:09:18 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v38]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <eezyAvzaM0LdNnfM45CuWMrKf7UHrz2pihbMsQeGL3Q=.9ae6c576-ddcb-4129-ab33-2019ebbadbf3@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:

 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - Update @since
 - Requested changes #12
 - ... and 43 more: https://git.openjdk.org/jdk/compare/4539899c...5fab46c1

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=37
  Stats: 9576 lines in 81 files changed: 9411 ins; 28 del; 137 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Feb 10 17:32:00 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 17:32:00 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v39]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <tspvAWdHSt6tqlq1TtiLVEO2YywIAJaJWd19gMYsIm4=.6cf6fe32-6d09-46c9-af60-fb334f6cfdb7@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Minor correction to javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/5fab46c1..5a031bda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=37-38

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Sat Feb 11 17:49:49 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 11 Feb 2023 17:49:49 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v40]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <rQog4uNSJmI3BjY7WzAKDkZPttL5RWlJDPPcKwec9aE=.3d2799ca-a8d2-4401-9b05-e6560da18cac@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:

 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - ... and 45 more: https://git.openjdk.org/jdk/compare/6f9f2b5d...95d219af

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=39
  Stats: 9492 lines in 81 files changed: 9394 ins; 28 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlahoda at openjdk.org  Fri Feb 17 10:36:56 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 17 Feb 2023 10:36:56 GMT
Subject: RFR: 8297587: Upgrade JLine to 3.22.0
Message-ID: <Y2xdMkQ3uIpXOWBKdAlVyEiGEmDF4YsAWqV0Tf_dp9A=.200485d2-cc87-41bf-86dc-ad85c25d4f0e@github.com>

This is a proposal to upgrade the JLine inside JDK to 3.22.0. It was done by:
-for shared/classes, taking a diff between JLine 3.20.0 and the existing JDK version, copying the JLine 3.22.0 into the JDK, repackaing, re-appling the patch (including trailing space removal, UTF-8 characters replacement, addition of inputStreamWrapper), and adjusting TerminalProvider
-for Windows, mostly copying the JLine 3.22.0 code into the JDK, and adjusting based on old changes

-------------

Commit messages:
 - 8297587: Upgrade JLine to 3.22.0

Changes: https://git.openjdk.org/jdk/pull/12614/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297587
  Stats: 1763 lines in 54 files changed: 1055 ins; 452 del; 256 mod
  Patch: https://git.openjdk.org/jdk/pull/12614.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12614/head:pull/12614

PR: https://git.openjdk.org/jdk/pull/12614

From jwaters at openjdk.org  Mon Feb 20 07:53:11 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 20 Feb 2023 07:53:11 GMT
Subject: RFR: 8302837: Kernel32.cpp array memory release invokes undefined
 behaviour
Message-ID: <nEynMcPLzcsO1XnFAhZTcf5w3dUf4OGW8oleKjy0ij8=.0d3fc5af-f062-4aed-b755-a52cae54d3b3@github.com>

When several arrays are allocated with the new operator in Kernel32, they use the wrong set of delete operators when freeing the allocated memory. In C++ this is undefined behaviour and they should be converted to use the correct operators

-------------

Commit messages:
 - Kernel32.cpp

Changes: https://git.openjdk.org/jdk/pull/12649/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12649&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302837
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12649.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12649/head:pull/12649

PR: https://git.openjdk.org/jdk/pull/12649

From jlahoda at openjdk.org  Tue Feb 21 00:05:09 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 21 Feb 2023 00:05:09 GMT
Subject: RFR: 8299902: Support for MarkDown javadoc in JShell [v2]
In-Reply-To: <KuNsxDHHZPIsM0BeE6Au2Bc82b5OJEbC0UREsEYNFsE=.c7467a58-b510-464d-97a9-173510a85e2f@github.com>
References: <KuNsxDHHZPIsM0BeE6Au2Bc82b5OJEbC0UREsEYNFsE=.c7467a58-b510-464d-97a9-173510a85e2f@github.com>
Message-ID: <AjkClVS-xY-G2vLIJU0dMlCNUYnOURWntb01j_47GE8=.d4074837-a5f1-4db5-beee-6e697d5c8bb1@github.com>

> Adding support for MarkDown javadoc in the JShell

Jan Lahoda 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 eight additional commits since the last revision:

 - Cleanup.
 - Post-merge updates.
 - Merge branch '8298405.doclet-markdown' into markdown-in-jshell
 - Update copyright years
 - Rename FFFC variable
   Share Markdown parser and renderer in instance of MarkdownHandler
 - Move CommonMark to new internal module.
   Add legal header to imported CommonMark source files
   Always use Text nodes inside AttributeTree values
   Unwrap <p> from "simple" paragraphs
 - Always use Text nodes inside AttributeTree values
 - Update to CommonMark 0.21.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11936/files
  - new: https://git.openjdk.org/jdk/pull/11936/files/89f51aa6..89f51aa6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11936&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11936&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11936.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11936/head:pull/11936

PR: https://git.openjdk.org/jdk/pull/11936

From jlahoda at openjdk.org  Tue Feb 21 11:43:24 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 21 Feb 2023 11:43:24 GMT
Subject: RFR: 8302837: Kernel32.cpp array memory release invokes undefined
 behaviour
In-Reply-To: <nEynMcPLzcsO1XnFAhZTcf5w3dUf4OGW8oleKjy0ij8=.0d3fc5af-f062-4aed-b755-a52cae54d3b3@github.com>
References: <nEynMcPLzcsO1XnFAhZTcf5w3dUf4OGW8oleKjy0ij8=.0d3fc5af-f062-4aed-b755-a52cae54d3b3@github.com>
Message-ID: <Mc6EWcHAetkADiksJXrwoXgKFnUw2lV1petek_9P1kg=.2a7453f1-cd2c-48ad-9672-d495c9919469@github.com>

On Mon, 20 Feb 2023 07:47:48 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> When several arrays are allocated with the new operator in Kernel32, they use the wrong set of delete operators when freeing the allocated memory. In C++ this is undefined behaviour and they should be converted to use the correct operators

Looks sensible to me. Thanks!

-------------

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12649

From jwaters at openjdk.org  Tue Feb 21 12:01:44 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Feb 2023 12:01:44 GMT
Subject: RFR: 8302837: Kernel32.cpp array memory release invokes undefined
 behaviour
In-Reply-To: <nEynMcPLzcsO1XnFAhZTcf5w3dUf4OGW8oleKjy0ij8=.0d3fc5af-f062-4aed-b755-a52cae54d3b3@github.com>
References: <nEynMcPLzcsO1XnFAhZTcf5w3dUf4OGW8oleKjy0ij8=.0d3fc5af-f062-4aed-b755-a52cae54d3b3@github.com>
Message-ID: <fM6yEuVccNm1YAcnLcX9k_h10C5ku5mbJSrs8xhqPSY=.bff896e5-aac5-4671-8f26-978ec2d405d2@github.com>

On Mon, 20 Feb 2023 07:47:48 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> When several arrays are allocated with the new operator in Kernel32, they use the wrong set of delete operators when freeing the allocated memory. In C++ this is undefined behaviour and they should be converted to use the correct operators

Thanks for the review! :D

-------------

PR: https://git.openjdk.org/jdk/pull/12649

From jwaters at openjdk.org  Tue Feb 21 12:01:44 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Feb 2023 12:01:44 GMT
Subject: Integrated: 8302837: Kernel32.cpp array memory release invokes
 undefined behaviour
In-Reply-To: <nEynMcPLzcsO1XnFAhZTcf5w3dUf4OGW8oleKjy0ij8=.0d3fc5af-f062-4aed-b755-a52cae54d3b3@github.com>
References: <nEynMcPLzcsO1XnFAhZTcf5w3dUf4OGW8oleKjy0ij8=.0d3fc5af-f062-4aed-b755-a52cae54d3b3@github.com>
Message-ID: <tp_4dF6vgYbu4DhnVWznNTYDVd-36xyKXZRDKTMFn9o=.6d996529-e55b-464c-ba02-5e923d7bee90@github.com>

On Mon, 20 Feb 2023 07:47:48 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> When several arrays are allocated with the new operator in Kernel32, they use the wrong set of delete operators when freeing the allocated memory. In C++ this is undefined behaviour and they should be converted to use the correct operators

This pull request has now been integrated.

Changeset: 644fe0a9
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/644fe0a9943e22654673265341ad922e51a78fe0
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8302837: Kernel32.cpp array memory release invokes undefined behaviour

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/12649

From jlaskey at openjdk.org  Thu Feb 23 20:08:21 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Feb 2023 20:08:21 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v41]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <8acQaVjcsJLZjZv02chxRMODQ1wJnJ6zvb5IkaIGH2w=.94b6a788-b129-4623-bd4e-ecaaeb4bce37@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits:

 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - ... and 46 more: https://git.openjdk.org/jdk/compare/6b24b4a7...89806d49

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=40
  Stats: 9494 lines in 81 files changed: 9395 ins; 29 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Feb 27 12:47:03 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Feb 2023 12:47:03 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v42]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Tighten up reporting of string template errors (fewer messages)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/89806d49..85cc7efc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=40-41

  Stats: 52 lines in 5 files changed: 27 ins; 7 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From vromero at openjdk.org  Tue Feb 28 22:31:04 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 28 Feb 2023 22:31:04 GMT
Subject: RFR: 8297587: Upgrade JLine to 3.22.0
In-Reply-To: <Y2xdMkQ3uIpXOWBKdAlVyEiGEmDF4YsAWqV0Tf_dp9A=.200485d2-cc87-41bf-86dc-ad85c25d4f0e@github.com>
References: <Y2xdMkQ3uIpXOWBKdAlVyEiGEmDF4YsAWqV0Tf_dp9A=.200485d2-cc87-41bf-86dc-ad85c25d4f0e@github.com>
Message-ID: <JFReixI_VejP9NtDVIc6O67eLUxCMW6OCfQAeHGi6ns=.5babe1a6-6cbe-47f7-9897-8f46bb297255@github.com>

On Fri, 17 Feb 2023 10:20:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a proposal to upgrade the JLine inside JDK to 3.22.0. It was done by:
> -for shared/classes, taking a diff between JLine 3.20.0 and the existing JDK version, copying the JLine 3.22.0 into the JDK, repackaing, re-appling the patch (including trailing space removal, UTF-8 characters replacement, addition of inputStreamWrapper), and adjusting TerminalProvider
> -for Windows, mostly copying the JLine 3.22.0 code into the JDK, and adjusting based on old changes

some nit comments for your consideration, approved

src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/LineReaderImpl.java line 5086:

> 5084:         if (groupName) {
> 5085:             Comparator<String> groupComparator = getGroupComparator();
> 5086:             Map<String, Map<Object, Candidate>> sorted;

Candidate and String both implement Comparable, probably that could be used to provide a more specific common supertype

src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlocking.java line 147:

> 145:             this.input = input;
> 146:             this.decoder = decoder;
> 147:             this.bytes = ByteBuffer.allocate(2048);

wow, big difference in allocation size

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12614