From amaembo at gmail.com  Thu Jul  6 08:20:20 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Thu, 6 Jul 2023 10:20:20 +0200
Subject: Qualified enum constants in switch?
Message-ID: <CAE+3fjaRF5j3r4tuQ0-cG4GjRYHkmHux3jaR7MDmD2iJuJv6oQ@mail.gmail.com>

Hello!

We are working on Java 21 support in our IDE, and stumbled the following issue.
Previous draft of spec [1] said:

Every case constant must be either (1) the null literal, (2) a
constant expression (15.29), or (3) the (simple or qualified) name of
an enum constant (8.9.1); otherwise a compile-time error occurs. A
single null case constant may also be paired with the default keyword.

Now, it says [2]

Every case constant must be either a constant expression (15.29), or
the name of an enum constant (8.9.1), or a compile-time error occurs.

So, now it doesn't mention the qualified names. Still JEP 441 [3]
still mentions that qualified enum constants are allowed. Could you
please tell me whether the intent is to keep this part of
specification, or it was decided to drop it?

With best regards,
Tagir Valeev.

[1] https://cr.openjdk.org/~gbierman/jep440+441/jep440+441-20230524/specs/patterns-switch-record-patterns-jls.html
[2] https://cr.openjdk.org/~gbierman/jep440%2B441/jep440+441-20230612/specs/patterns-switch-record-patterns-jls.html
[3] https://openjdk.org/jeps/441

From gavin.bierman at oracle.com  Wed Jul 12 22:06:17 2023
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Wed, 12 Jul 2023 22:06:17 +0000
Subject: Qualified enum constants in switch?
In-Reply-To: <CAE+3fjaRF5j3r4tuQ0-cG4GjRYHkmHux3jaR7MDmD2iJuJv6oQ@mail.gmail.com>
References: <CAE+3fjaRF5j3r4tuQ0-cG4GjRYHkmHux3jaR7MDmD2iJuJv6oQ@mail.gmail.com>
Message-ID: <9DA87864-0EEA-4FBF-B90F-31F8C5429B57@oracle.com>

Yes, they are allowed - we just tweaked the language in the spec.

Gavin

> On 6 Jul 2023, at 09:20, Tagir Valeev <amaembo at gmail.com> wrote:
> 
> Hello!
> 
> We are working on Java 21 support in our IDE, and stumbled the following issue.
> Previous draft of spec [1] said:
> 
> Every case constant must be either (1) the null literal, (2) a
> constant expression (15.29), or (3) the (simple or qualified) name of
> an enum constant (8.9.1); otherwise a compile-time error occurs. A
> single null case constant may also be paired with the default keyword.
> 
> Now, it says [2]
> 
> Every case constant must be either a constant expression (15.29), or
> the name of an enum constant (8.9.1), or a compile-time error occurs.
> 
> So, now it doesn't mention the qualified names. Still JEP 441 [3]
> still mentions that qualified enum constants are allowed. Could you
> please tell me whether the intent is to keep this part of
> specification, or it was decided to drop it?
> 
> With best regards,
> Tagir Valeev.
> 
> [1] https://cr.openjdk.org/~gbierman/jep440+441/jep440+441-20230524/specs/patterns-switch-record-patterns-jls.html
> [2] https://cr.openjdk.org/~gbierman/jep440%2B441/jep440+441-20230612/specs/patterns-switch-record-patterns-jls.html
> [3] https://openjdk.org/jeps/441


From amaembo at gmail.com  Thu Jul 20 09:17:03 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Thu, 20 Jul 2023 11:17:03 +0200
Subject: Native methods in unnamed classes
Message-ID: <CAE+3fjbhSwTQR_mcnqkewp6uB1mM-p4fC5aECkSoVq7UxJqiTA@mail.gmail.com>

Hello!

A quick question about unnamed classes specification draft [1]. I
don't see that native methods are explicitly forbidden inside unnamed
classes. If they are allowed, it's not quite clear how to define the
name of the corresponding method in the native library according to
[2], as the binary name of an unnamed class can be arbitrarily defined
by java compiler (JLS 13.1). Or is this not a problem?

With best regards,
Tagir Valeev

[1] https://cr.openjdk.org/~gbierman/jep445/jep445-20230524/specs/unnamed-classes-instance-main-methods-jls.html
[2] https://docs.oracle.com/en/java/javase/20/docs/specs/jni/design.html#resolving-native-method-names

From amaembo at gmail.com  Thu Jul 20 09:17:03 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Thu, 20 Jul 2023 11:17:03 +0200
Subject: Native methods in unnamed classes
Message-ID: <CAE+3fjbhSwTQR_mcnqkewp6uB1mM-p4fC5aECkSoVq7UxJqiTA@mail.gmail.com>

Hello!

A quick question about unnamed classes specification draft [1]. I
don't see that native methods are explicitly forbidden inside unnamed
classes. If they are allowed, it's not quite clear how to define the
name of the corresponding method in the native library according to
[2], as the binary name of an unnamed class can be arbitrarily defined
by java compiler (JLS 13.1). Or is this not a problem?

With best regards,
Tagir Valeev

[1] https://cr.openjdk.org/~gbierman/jep445/jep445-20230524/specs/unnamed-classes-instance-main-methods-jls.html
[2] https://docs.oracle.com/en/java/javase/20/docs/specs/jni/design.html#resolving-native-method-names

From maurizio.cimadamore at oracle.com  Thu Jul 20 09:20:45 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 10:20:45 +0100
Subject: Native methods in unnamed classes
In-Reply-To: <CAE+3fjbhSwTQR_mcnqkewp6uB1mM-p4fC5aECkSoVq7UxJqiTA@mail.gmail.com>
References: <CAE+3fjbhSwTQR_mcnqkewp6uB1mM-p4fC5aECkSoVq7UxJqiTA@mail.gmail.com>
Message-ID: <8a0150e0-0eb8-17f5-f7f1-2c464c274079@oracle.com>

Good point Tagir.

IMHO this is something that needs to be looked at. While it's true that 
the compiler will have to come up with a name for the class, there's no 
guarantee anywhere that such a name will be stable. E.g. perhaps the 
Java compiler can change the name of the class depending on the contents 
it saw at the time of compiling (we don't do this, but JLS doesn't say 
it can't be done). Which then would leave you with a set of *unstable* 
native methods.

Maurizio

On 20/07/2023 10:17, Tagir Valeev wrote:
> Hello!
>
> A quick question about unnamed classes specification draft [1]. I
> don't see that native methods are explicitly forbidden inside unnamed
> classes. If they are allowed, it's not quite clear how to define the
> name of the corresponding method in the native library according to
> [2], as the binary name of an unnamed class can be arbitrarily defined
> by java compiler (JLS 13.1). Or is this not a problem?
>
> With best regards,
> Tagir Valeev
>
> [1] https://cr.openjdk.org/~gbierman/jep445/jep445-20230524/specs/unnamed-classes-instance-main-methods-jls.html
> [2] https://docs.oracle.com/en/java/javase/20/docs/specs/jni/design.html#resolving-native-method-names

From maurizio.cimadamore at oracle.com  Thu Jul 20 09:20:45 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 20 Jul 2023 10:20:45 +0100
Subject: Native methods in unnamed classes
In-Reply-To: <CAE+3fjbhSwTQR_mcnqkewp6uB1mM-p4fC5aECkSoVq7UxJqiTA@mail.gmail.com>
References: <CAE+3fjbhSwTQR_mcnqkewp6uB1mM-p4fC5aECkSoVq7UxJqiTA@mail.gmail.com>
Message-ID: <8a0150e0-0eb8-17f5-f7f1-2c464c274079@oracle.com>

Good point Tagir.

IMHO this is something that needs to be looked at. While it's true that 
the compiler will have to come up with a name for the class, there's no 
guarantee anywhere that such a name will be stable. E.g. perhaps the 
Java compiler can change the name of the class depending on the contents 
it saw at the time of compiling (we don't do this, but JLS doesn't say 
it can't be done). Which then would leave you with a set of *unstable* 
native methods.

Maurizio

On 20/07/2023 10:17, Tagir Valeev wrote:
> Hello!
>
> A quick question about unnamed classes specification draft [1]. I
> don't see that native methods are explicitly forbidden inside unnamed
> classes. If they are allowed, it's not quite clear how to define the
> name of the corresponding method in the native library according to
> [2], as the binary name of an unnamed class can be arbitrarily defined
> by java compiler (JLS 13.1). Or is this not a problem?
>
> With best regards,
> Tagir Valeev
>
> [1] https://cr.openjdk.org/~gbierman/jep445/jep445-20230524/specs/unnamed-classes-instance-main-methods-jls.html
> [2] https://docs.oracle.com/en/java/javase/20/docs/specs/jni/design.html#resolving-native-method-names

From james.laskey at oracle.com  Thu Jul 20 09:34:04 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 20 Jul 2023 09:34:04 +0000
Subject: Native methods in unnamed classes
In-Reply-To: <8a0150e0-0eb8-17f5-f7f1-2c464c274079@oracle.com>
References: <CAE+3fjbhSwTQR_mcnqkewp6uB1mM-p4fC5aECkSoVq7UxJqiTA@mail.gmail.com>
 <8a0150e0-0eb8-17f5-f7f1-2c464c274079@oracle.com>
Message-ID: <F9EDBE28-9A97-4C5A-B165-5C44AD5DE416@oracle.com>

I think we will be moving toward stabilizing the class name (based on source file name) in the next round. 

?

> On Jul 20, 2023, at 6:20 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> ?Good point Tagir.
> 
> IMHO this is something that needs to be looked at. While it's true that the compiler will have to come up with a name for the class, there's no guarantee anywhere that such a name will be stable. E.g. perhaps the Java compiler can change the name of the class depending on the contents it saw at the time of compiling (we don't do this, but JLS doesn't say it can't be done). Which then would leave you with a set of *unstable* native methods.
> 
> Maurizio
> 
>> On 20/07/2023 10:17, Tagir Valeev wrote:
>> Hello!
>> 
>> A quick question about unnamed classes specification draft [1]. I
>> don't see that native methods are explicitly forbidden inside unnamed
>> classes. If they are allowed, it's not quite clear how to define the
>> name of the corresponding method in the native library according to
>> [2], as the binary name of an unnamed class can be arbitrarily defined
>> by java compiler (JLS 13.1). Or is this not a problem?
>> 
>> With best regards,
>> Tagir Valeev
>> 
>> [1] https://cr.openjdk.org/~gbierman/jep445/jep445-20230524/specs/unnamed-classes-instance-main-methods-jls.html
>> [2] https://docs.oracle.com/en/java/javase/20/docs/specs/jni/design.html#resolving-native-method-names

From james.laskey at oracle.com  Thu Jul 20 09:34:04 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 20 Jul 2023 09:34:04 +0000
Subject: Native methods in unnamed classes
In-Reply-To: <8a0150e0-0eb8-17f5-f7f1-2c464c274079@oracle.com>
References: <CAE+3fjbhSwTQR_mcnqkewp6uB1mM-p4fC5aECkSoVq7UxJqiTA@mail.gmail.com>
 <8a0150e0-0eb8-17f5-f7f1-2c464c274079@oracle.com>
Message-ID: <F9EDBE28-9A97-4C5A-B165-5C44AD5DE416@oracle.com>

I think we will be moving toward stabilizing the class name (based on source file name) in the next round. 

?

> On Jul 20, 2023, at 6:20 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> ?Good point Tagir.
> 
> IMHO this is something that needs to be looked at. While it's true that the compiler will have to come up with a name for the class, there's no guarantee anywhere that such a name will be stable. E.g. perhaps the Java compiler can change the name of the class depending on the contents it saw at the time of compiling (we don't do this, but JLS doesn't say it can't be done). Which then would leave you with a set of *unstable* native methods.
> 
> Maurizio
> 
>> On 20/07/2023 10:17, Tagir Valeev wrote:
>> Hello!
>> 
>> A quick question about unnamed classes specification draft [1]. I
>> don't see that native methods are explicitly forbidden inside unnamed
>> classes. If they are allowed, it's not quite clear how to define the
>> name of the corresponding method in the native library according to
>> [2], as the binary name of an unnamed class can be arbitrarily defined
>> by java compiler (JLS 13.1). Or is this not a problem?
>> 
>> With best regards,
>> Tagir Valeev
>> 
>> [1] https://cr.openjdk.org/~gbierman/jep445/jep445-20230524/specs/unnamed-classes-instance-main-methods-jls.html
>> [2] https://docs.oracle.com/en/java/javase/20/docs/specs/jni/design.html#resolving-native-method-names

From forax at univ-mlv.fr  Thu Jul 20 09:59:34 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 20 Jul 2023 11:59:34 +0200 (CEST)
Subject: Native methods in unnamed classes
In-Reply-To: <F9EDBE28-9A97-4C5A-B165-5C44AD5DE416@oracle.com>
References: <CAE+3fjbhSwTQR_mcnqkewp6uB1mM-p4fC5aECkSoVq7UxJqiTA@mail.gmail.com>
 <8a0150e0-0eb8-17f5-f7f1-2c464c274079@oracle.com>
 <F9EDBE28-9A97-4C5A-B165-5C44AD5DE416@oracle.com>
Message-ID: <1078626873.152529.1689847174432.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Jim Laskey" <james.laskey at oracle.com>
> To: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "Tagir Valeev" <amaembo at gmail.com>, "amber-spec-experts" <amber-spec-experts at openjdk.org>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Sent: Thursday, July 20, 2023 11:34:04 AM
> Subject: Re: Native methods in unnamed classes

> I think we will be moving toward stabilizing the class name (based on source
> file name) in the next round.
> 
> ?


+1

R?mi

> 
>> On Jul 20, 2023, at 6:20 AM, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>> 
>> ?Good point Tagir.
>> 
>> IMHO this is something that needs to be looked at. While it's true that the
>> compiler will have to come up with a name for the class, there's no guarantee
>> anywhere that such a name will be stable. E.g. perhaps the Java compiler can
>> change the name of the class depending on the contents it saw at the time of
>> compiling (we don't do this, but JLS doesn't say it can't be done). Which then
>> would leave you with a set of *unstable* native methods.
>> 
>> Maurizio
>> 
>>> On 20/07/2023 10:17, Tagir Valeev wrote:
>>> Hello!
>>> 
>>> A quick question about unnamed classes specification draft [1]. I
>>> don't see that native methods are explicitly forbidden inside unnamed
>>> classes. If they are allowed, it's not quite clear how to define the
>>> name of the corresponding method in the native library according to
>>> [2], as the binary name of an unnamed class can be arbitrarily defined
>>> by java compiler (JLS 13.1). Or is this not a problem?
>>> 
>>> With best regards,
>>> Tagir Valeev
>>> 
>>> [1]
>>> https://cr.openjdk.org/~gbierman/jep445/jep445-20230524/specs/unnamed-classes-instance-main-methods-jls.html
>>> [2]
> >> https://docs.oracle.com/en/java/javase/20/docs/specs/jni/design.html#resolving-native-method-names

From amaembo at gmail.com  Tue Jul 25 08:52:04 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 25 Jul 2023 10:52:04 +0200
Subject: [string-templates] Template expression in expression statement?
Message-ID: <CAE+3fjau09YU0CU-HYozoZ0VRJRWdM9z2MEd_0Fg+Fye=zF1pw@mail.gmail.com>

Hello!

It looks like, the latest javac (build 22-ea+7-489) accepts string
templates as expression statements:

public class Demo {
    public static void main(String[] args) {
        STR."hello";
    }
}

The expression statement spec (JLS 14.8, [1]) states that only
'StatementExpression' productions are allowed inside expression
statements. This is a closed list of expressions, and it was not
updated in the latest spec draft for JEP 430 [2] to include 15.8.6
Template Expressions. I'm not sure what the latest consensus is. On
one hand, template expression is essentially a method call that may
produce a side effect (e.g. logging :D). On the other hand, such kind
of usage is probably discouraged. In any case I see the discrepancy
here: either spec or javac implementation should be updated.

With best regards,
Tagir Valeev.

[1] https://docs.oracle.com/javase/specs/jls/se20/html/jls-14.html#jls-14.8
[2] https://cr.openjdk.org/~gbierman/jep430/jep430-20230526/specs/string-templates-jls.html

From forax at univ-mlv.fr  Tue Jul 25 09:07:42 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 25 Jul 2023 11:07:42 +0200 (CEST)
Subject: [string-templates] Template expression in expression statement?
In-Reply-To: <CAE+3fjau09YU0CU-HYozoZ0VRJRWdM9z2MEd_0Fg+Fye=zF1pw@mail.gmail.com>
References: <CAE+3fjau09YU0CU-HYozoZ0VRJRWdM9z2MEd_0Fg+Fye=zF1pw@mail.gmail.com>
Message-ID: <583004285.3159442.1690276062316.JavaMail.zimbra@univ-eiffel.fr>



----- Original Message -----
> From: "Tagir Valeev" <amaembo at gmail.com>
> To: "amber-spec-experts" <amber-spec-experts at openjdk.org>
> Sent: Tuesday, July 25, 2023 10:52:04 AM
> Subject: [string-templates] Template expression in expression statement?

> Hello!
> 
> It looks like, the latest javac (build 22-ea+7-489) accepts string
> templates as expression statements:
> 
> public class Demo {
>    public static void main(String[] args) {
>        STR."hello";
>    }
> }
> 
> The expression statement spec (JLS 14.8, [1]) states that only
> 'StatementExpression' productions are allowed inside expression
> statements. This is a closed list of expressions, and it was not
> updated in the latest spec draft for JEP 430 [2] to include 15.8.6
> Template Expressions. I'm not sure what the latest consensus is. On
> one hand, template expression is essentially a method call that may
> produce a side effect (e.g. logging :D). On the other hand, such kind
> of usage is probably discouraged. In any case I see the discrepancy
> here: either spec or javac implementation should be updated.

The JEP contains these sentences
"However, it is unwise for a template processor to trigger potentially long-running actions in order to compose a result. It is also unwise to embark upon actions that can have side effects, such as updating a database. The authors of template processors are strongly advised to focus on validating their input and on composing a result that gives maximum flexibility to the client."

so I believe the spec needs to be updated.

> 
> With best regards,
> Tagir Valeev.

R?mi

> 
> [1] https://docs.oracle.com/javase/specs/jls/se20/html/jls-14.html#jls-14.8
> [2]
> https://cr.openjdk.org/~gbierman/jep430/jep430-20230526/specs/string-templates-jls.html

From forax at univ-mlv.fr  Tue Jul 25 09:38:05 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 25 Jul 2023 11:38:05 +0200 (CEST)
Subject: STR behavior
Message-ID: <1303622728.3170499.1690277885527.JavaMail.zimbra@univ-eiffel.fr>

Currently javac uses a trick to rewrite STR."" template to more or less the string concatenation equivalent, by passing the call to the bootstrap method of the string template runtime.

But this rewriting 
- has a side effect at runtime, the class StringTemplate is not loaded.
- exact behavior is slightly different from the string concatenation, constant strings are not pre-computed, so the exact behavior is not an existing behavior.
- only works with the unqualified STR (where STR is a static import implicit or explicit) but not with a qualified reference to StringTemplate.STR.

I think we need something in the spec saying that this is a valid source code transformation specific to STR, that it works in the qualified and unqualified case and that the transformations should be the same as with the string concatenation. 

regards,
R?mi



From alex.buckley at oracle.com  Tue Jul 25 15:51:39 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 25 Jul 2023 08:51:39 -0700
Subject: [string-templates] Template expression in expression statement?
In-Reply-To: <583004285.3159442.1690276062316.JavaMail.zimbra@univ-eiffel.fr>
References: <CAE+3fjau09YU0CU-HYozoZ0VRJRWdM9z2MEd_0Fg+Fye=zF1pw@mail.gmail.com>
 <583004285.3159442.1690276062316.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <75288ca9-ee7d-fcf7-d4b9-591c06da6dd6@oracle.com>

On 7/25/2023 2:07 AM, Remi Forax wrote:
> ----- Original Message -----
>> From: "Tagir Valeev" <amaembo at gmail.com>
>> To: "amber-spec-experts" <amber-spec-experts at openjdk.org>
>> Sent: Tuesday, July 25, 2023 10:52:04 AM
>> Subject: [string-templates] Template expression in expression statement?
> 
>> Hello!
>>
>> It looks like, the latest javac (build 22-ea+7-489) accepts string
>> templates as expression statements:
>>
>> public class Demo {
>>     public static void main(String[] args) {
>>         STR."hello";
>>     }
>> }
>>
>> The expression statement spec (JLS 14.8, [1]) states that only
>> 'StatementExpression' productions are allowed inside expression
>> statements. This is a closed list of expressions, and it was not
>> updated in the latest spec draft for JEP 430 [2] to include 15.8.6
>> Template Expressions. I'm not sure what the latest consensus is. On
>> one hand, template expression is essentially a method call that may
>> produce a side effect (e.g. logging :D). On the other hand, such kind
>> of usage is probably discouraged. In any case I see the discrepancy
>> here: either spec or javac implementation should be updated.
> 
> The JEP contains these sentences
> "However, it is unwise for a template processor to trigger potentially long-running actions in order to compose a result. It is also unwise to embark upon actions that can have side effects, such as updating a database. The authors of template processors are strongly advised to focus on validating their input and on composing a result that gives maximum flexibility to the client."
> 
> so I believe the spec needs to be updated.

The quoted text focuses on results, not side effects. (In line with 
Brian's "The spirit here is that the template processor is a *function*, 
taking some template-shaped ingredients and turning it into a useful 
*thing*, that you can then further use or manipulate.")

In contrast, expression statements are all about side effects, not 
results (which are discarded).

So, it's odd to read the quoted text and conclude that the _spec_ should 
be updated to make template expressions be expression statements. It's 
javac that should be updated to make template expressions _not_ be 
expression statements. I don't have any reason to think that JLS 14.8 is 
erroneous.

Alex

From forax at univ-mlv.fr  Tue Jul 25 16:24:51 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 25 Jul 2023 18:24:51 +0200 (CEST)
Subject: [string-templates] Template expression in expression statement?
In-Reply-To: <75288ca9-ee7d-fcf7-d4b9-591c06da6dd6@oracle.com>
References: <CAE+3fjau09YU0CU-HYozoZ0VRJRWdM9z2MEd_0Fg+Fye=zF1pw@mail.gmail.com>
 <583004285.3159442.1690276062316.JavaMail.zimbra@univ-eiffel.fr>
 <75288ca9-ee7d-fcf7-d4b9-591c06da6dd6@oracle.com>
Message-ID: <401459897.3316902.1690302291920.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Alex Buckley" <alex.buckley at oracle.com>
> To: "amber-spec-experts" <amber-spec-experts at openjdk.org>
> Sent: Tuesday, July 25, 2023 5:51:39 PM
> Subject: Re: [string-templates] Template expression in expression statement?

> On 7/25/2023 2:07 AM, Remi Forax wrote:
>> ----- Original Message -----
>>> From: "Tagir Valeev" <amaembo at gmail.com>
>>> To: "amber-spec-experts" <amber-spec-experts at openjdk.org>
>>> Sent: Tuesday, July 25, 2023 10:52:04 AM
>>> Subject: [string-templates] Template expression in expression statement?
>> 
>>> Hello!
>>>
>>> It looks like, the latest javac (build 22-ea+7-489) accepts string
>>> templates as expression statements:
>>>
>>> public class Demo {
>>>     public static void main(String[] args) {
>>>         STR."hello";
>>>     }
>>> }
>>>
>>> The expression statement spec (JLS 14.8, [1]) states that only
>>> 'StatementExpression' productions are allowed inside expression
>>> statements. This is a closed list of expressions, and it was not
>>> updated in the latest spec draft for JEP 430 [2] to include 15.8.6
>>> Template Expressions. I'm not sure what the latest consensus is. On
>>> one hand, template expression is essentially a method call that may
>>> produce a side effect (e.g. logging :D). On the other hand, such kind
>>> of usage is probably discouraged. In any case I see the discrepancy
>>> here: either spec or javac implementation should be updated.
>> 
>> The JEP contains these sentences
>> "However, it is unwise for a template processor to trigger potentially
>> long-running actions in order to compose a result. It is also unwise to embark
>> upon actions that can have side effects, such as updating a database. The
>> authors of template processors are strongly advised to focus on validating
>> their input and on composing a result that gives maximum flexibility to the
>> client."
>> 
>> so I believe the spec needs to be updated.
> 
> The quoted text focuses on results, not side effects. (In line with
> Brian's "The spirit here is that the template processor is a *function*,
> taking some template-shaped ingredients and turning it into a useful
> *thing*, that you can then further use or manipulate.")
> 
> In contrast, expression statements are all about side effects, not
> results (which are discarded).
> 
> So, it's odd to read the quoted text and conclude that the _spec_ should
> be updated to make template expressions be expression statements. It's
> javac that should be updated to make template expressions _not_ be
> expression statements. I don't have any reason to think that JLS 14.8 is
> erroneous.

I'm in the camp of the less it is different from a method call the better.

The JLS is the law. This paragraph of the JEP was added recently (in June) and I see it more as the letter of the law, that's why i've quoted it.

> 
> Alex

R?mi

From alex.buckley at oracle.com  Tue Jul 25 18:36:01 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 25 Jul 2023 11:36:01 -0700
Subject: STR behavior
In-Reply-To: <1303622728.3170499.1690277885527.JavaMail.zimbra@univ-eiffel.fr>
References: <1303622728.3170499.1690277885527.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <3fd0ee43-853f-0a71-4f0b-a09f6d6bf37d@oracle.com>

Looking at the API spec of STR [1], which will be extremely widely read, 
I agree that more normative text is needed about the form of the result 
string. A single example-led mention of an "interleaving concatenation" 
is insufficient, and the example's use of arithmetic + in the string 
template is confusing given that everyone will be thinking about Java's 
concatenating +. (The 10+20 example is already shown in the 
interface-level javadoc anyway.)

I also have some sympathy with the complaint that a reference to the 
field STR in a template expression is not being compiled in line with 
JLS 13.1 (item 4), which demands a symbolic reference to StringTemplate 
and thus predicts that the interface will be loaded. 13.1 doesn't 
specify how every construct is compiled, so it's legitimate for a 
compiler to implement a template expression without the JLS having to 
define "string template runtime" ... but it would be best for 13.1 to 
carve out some fields (STR, RAW) from the usual rules.

Alex

[1] 
https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/StringTemplate.html#STR 
-- I note that the field STR is basically unfindable with javadoc 
search, despite being omnipresent (auto-imported) in new Java programs.

On 7/25/2023 2:38 AM, Remi Forax wrote:
> Currently javac uses a trick to rewrite STR."" template to more or less the string concatenation equivalent, by passing the call to the bootstrap method of the string template runtime.
> 
> But this rewriting
> - has a side effect at runtime, the class StringTemplate is not loaded.
> - exact behavior is slightly different from the string concatenation, constant strings are not pre-computed, so the exact behavior is not an existing behavior.
> - only works with the unqualified STR (where STR is a static import implicit or explicit) but not with a qualified reference to StringTemplate.STR.
> 
> I think we need something in the spec saying that this is a valid source code transformation specific to STR, that it works in the qualified and unqualified case and that the transformations should be the same as with the string concatenation.
> 
> regards,
> R?mi
> 
>