From bsrbnd at gmail.com  Sat Jul  1 08:43:45 2017
From: bsrbnd at gmail.com (B. Blaser)
Date: Sat, 1 Jul 2017 10:43:45 +0200
Subject: JDK 10: Refactoring of LetExpr to allow more than one statement
In-Reply-To: <9419157b-1296-33db-544c-db0c7cda6598@oracle.com>
References: <CAEgw74AcP_J6xq3_iqXmgUhde+16LMO88Y-UR1SMM49OYqQgkQ@mail.gmail.com>
 <9419157b-1296-33db-544c-db0c7cda6598@oracle.com>
Message-ID: <CAEgw74D2+FkbGvQvp4fp75KRdMVa1g=GnmUBiU8eX98nx-9D9Q@mail.gmail.com>

Hi,

On 10 May 2017 at 23:00, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> Hi,
> I think that we're I'd like to see things moving is more in the direction of
> block expressions, which allow even more freedom. That is, a list of
> statements (maybe var decls, but maybe not), followed by an expression
> (which is the expression value). I think this could be a powerful tool that
> could come handy for some of the features discussed under the Amber
> umbrella. So, I agree with you that LetExpr should be improved, but I guess
> I'm in for a more radical overhaul ;-)

Should I create a JBS issue only for the optimization of
Lower.makeComma(), not to forget it once LetExpr will be updated?

Thanks,
Bernard

> Maurizio
>
>
>
> On 10/05/17 21:14, B. Blaser wrote:
>>
>> Hi,
>>
>> I've suggested some time ago a refactoring of LetExpr to generate a
>> more optimized code in some cases, see [1].
>>
>> The key idea is to allow LetExpr to have more than one statement in
>> addition to multiple variable declarations. This would lead to a more
>> optimal translation of comma-expressions, see [1].
>>
>> This suggestion refers to let-expressions in Lisp which allow more
>> than one statement in addition to multiple variable declarations, see
>> [2].
>>
>> Are you interested in such a feature? Should I create a JBS issue for
>> that to be integrated in JDK 10?
>>
>> Regards,
>> Bernard
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010531.html
>> [2) http://www.lispworks.com/documentation/HyperSpec/Body/s_let_l.htm
>
>

From bsrbnd at gmail.com  Sat Jul  1 08:58:47 2017
From: bsrbnd at gmail.com (B. Blaser)
Date: Sat, 1 Jul 2017 10:58:47 +0200
Subject: RFR 8035271: Incorrect code attribute indentation
Message-ID: <CAEgw74DCEizmQscqqOwfb5yhWFTFUELFd1EgaSecvhEbZA4g8A@mail.gmail.com>

Jon,

Is this the right time to consider pushing the following patch to JDK 10?
Or should I update the JBS issue to "in progress/fix understood" not
to forget it?

Thanks,
Bernard

On 6 February 2017 at 15:02, B. Blaser <bsrbnd at gmail.com> wrote:
> Jonathan,
>
> 2017-02-02 18:41 GMT+01:00 Jonathan Gibbons <jonathan.gibbons at oracle.com>:
>> Bernard,
>>
>> In other tests with significant amounts of golden text, we have found it
>> more
>> readable to use \n in the golden strings, and use a single .replaceAll
>> on the string to change the \n to the platform newline character. This
>> avoids having to use + LS + at the end of each line.
>>
>> I will look at your changeset in full context, but comments like
>> "// Same as CodeWriter.write()" may be meaningful now, but may be less
>> relevant a year or two down the road, prompting questions like "why does
>> this need to be stated?".
>>
>> Separately, I note that the window of opportunity for fixes like this in JDK
>> 9
>> is rapidly closing, and at some point, we will have to push such fixes to
>> the
>> JDK 10 repos that were recently opened.
>>
>> -- Jon
>
> Thanks for your answer, I agree with your comments.
> Please, find next the updated patch.
>
> Bernard
>
>> On 02/02/2017 09:05 AM, B. Blaser wrote:
>>>
>>> Hi,
>>>
>>> Next is a small fix to preserve the same code attribute indentation
>>> for all javap options (issue 8035271), along with a test.
>>>
>>> Bernard
>
> diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
> b/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
> --- a/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
> +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
> @@ -571,13 +571,17 @@
>          } else if (code != null) {
>              if (options.showDisassembled) {
>                  println("Code:");
> +                indent(+1);
>                  codeWriter.writeInstrs(code);
>                  codeWriter.writeExceptionTable(code);
> +                indent(-1);
>              }
>
>              if (options.showLineAndLocalVariableTables) {
> +                indent(+1);
>                  attrWriter.write(code,
> code.attributes.get(Attribute.LineNumberTable), constant_pool);
>                  attrWriter.write(code,
> code.attributes.get(Attribute.LocalVariableTable), constant_pool);
> +                indent(-1);
>              }
>          }
>
> diff --git a/test/tools/javap/CodeAttributeIndentation.java
> b/test/tools/javap/CodeAttributeIndentation.java
> new file mode 100644
> --- /dev/null
> +++ b/test/tools/javap/CodeAttributeIndentation.java
> @@ -0,0 +1,65 @@
> +/*
> + * @test
> + * @bug 8035271
> + * @summary Same code attribute indentation for all options.
> + * @library /tools/lib
> + * @modules jdk.compiler/com.sun.tools.javac.api
> + *          jdk.compiler/com.sun.tools.javac.main
> + *          jdk.jdeps/com.sun.tools.javap
> + * @build toolbox.ToolBox toolbox.JavacTask toolbox.JavapTask
> + * @run main CodeAttributeIndentation
> + */
> +
> +import toolbox.ToolBox;
> +import toolbox.JavacTask;
> +import toolbox.JavapTask;
> +import toolbox.Task.OutputKind;
> +
> +public class CodeAttributeIndentation {
> +    public static void main(String... args) {
> +        String LS = System.getProperty("line.separator");
> +
> +        String src = (
> +            "public class A {\n" +
> +            "    public void a() {}\n" +
> +            "}"
> +            ).replaceAll("\n", LS);
> +
> +        String expected = (
> +            "Compiled from \"A.java\"\n" +
> +            "public class A {\n" +
> +            "  public A();\n" +
> +            "    Code:\n" +
> +            "         0: aload_0\n" +
> +            "         1: invokespecial #1                  " +
> +            "// Method java/lang/Object.\"<init>\":()V\n" +
> +            "         4: return\n" +
> +            "      LineNumberTable:\n" +
> +            "        line 1: 0\n" +
> +            "      LocalVariableTable:\n" +
> +            "        Start  Length  Slot  Name   Signature\n" +
> +            "            0       5     0  this   LA;\n" +
> +            "\n" +
> +            "  public void a();\n" +
> +            "    Code:\n" +
> +            "         0: return\n" +
> +            "      LineNumberTable:\n" +
> +            "        line 2: 0\n" +
> +            "      LocalVariableTable:\n" +
> +            "        Start  Length  Slot  Name   Signature\n" +
> +            "            0       1     0  this   LA;\n" +
> +            "}\n"
> +            ).replaceAll("\n", LS);
> +
> +        ToolBox tb = new ToolBox();
> +
> +        new JavacTask(tb).options("-g").sources(src).run();
> +
> +        String actual = new JavapTask(tb).options("-c",
> "-l").classes("A.class")
> +                .run().getOutput(OutputKind.DIRECT);
> +
> +        if (!actual.equals(expected))
> +            throw new AssertionError("Incorrect code attribute indentation: " +
> +                    LS + actual);
> +    }
> +}

From jonathan.gibbons at oracle.com  Sat Jul  1 20:46:39 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sat, 1 Jul 2017 13:46:39 -0700
Subject: RFR 8035271: Incorrect code attribute indentation
In-Reply-To: <CAEgw74DCEizmQscqqOwfb5yhWFTFUELFd1EgaSecvhEbZA4g8A@mail.gmail.com>
References: <CAEgw74DCEizmQscqqOwfb5yhWFTFUELFd1EgaSecvhEbZA4g8A@mail.gmail.com>
Message-ID: <2267cee8-0e71-4a84-f20e-631f0bfcafd1@oracle.com>

Now would be a good time to make progress on this issue.

-- Jon


On 7/1/17 1:58 AM, B. Blaser wrote:
> Jon,
>
> Is this the right time to consider pushing the following patch to JDK 10?
> Or should I update the JBS issue to "in progress/fix understood" not
> to forget it?
>
> Thanks,
> Bernard
>
> On 6 February 2017 at 15:02, B. Blaser <bsrbnd at gmail.com> wrote:
>> Jonathan,
>>
>> 2017-02-02 18:41 GMT+01:00 Jonathan Gibbons <jonathan.gibbons at oracle.com>:
>>> Bernard,
>>>
>>> In other tests with significant amounts of golden text, we have found it
>>> more
>>> readable to use \n in the golden strings, and use a single .replaceAll
>>> on the string to change the \n to the platform newline character. This
>>> avoids having to use + LS + at the end of each line.
>>>
>>> I will look at your changeset in full context, but comments like
>>> "// Same as CodeWriter.write()" may be meaningful now, but may be less
>>> relevant a year or two down the road, prompting questions like "why does
>>> this need to be stated?".
>>>
>>> Separately, I note that the window of opportunity for fixes like this in JDK
>>> 9
>>> is rapidly closing, and at some point, we will have to push such fixes to
>>> the
>>> JDK 10 repos that were recently opened.
>>>
>>> -- Jon
>> Thanks for your answer, I agree with your comments.
>> Please, find next the updated patch.
>>
>> Bernard
>>
>>> On 02/02/2017 09:05 AM, B. Blaser wrote:
>>>> Hi,
>>>>
>>>> Next is a small fix to preserve the same code attribute indentation
>>>> for all javap options (issue 8035271), along with a test.
>>>>
>>>> Bernard
>> diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
>> b/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
>> --- a/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
>> +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
>> @@ -571,13 +571,17 @@
>>           } else if (code != null) {
>>               if (options.showDisassembled) {
>>                   println("Code:");
>> +                indent(+1);
>>                   codeWriter.writeInstrs(code);
>>                   codeWriter.writeExceptionTable(code);
>> +                indent(-1);
>>               }
>>
>>               if (options.showLineAndLocalVariableTables) {
>> +                indent(+1);
>>                   attrWriter.write(code,
>> code.attributes.get(Attribute.LineNumberTable), constant_pool);
>>                   attrWriter.write(code,
>> code.attributes.get(Attribute.LocalVariableTable), constant_pool);
>> +                indent(-1);
>>               }
>>           }
>>
>> diff --git a/test/tools/javap/CodeAttributeIndentation.java
>> b/test/tools/javap/CodeAttributeIndentation.java
>> new file mode 100644
>> --- /dev/null
>> +++ b/test/tools/javap/CodeAttributeIndentation.java
>> @@ -0,0 +1,65 @@
>> +/*
>> + * @test
>> + * @bug 8035271
>> + * @summary Same code attribute indentation for all options.
>> + * @library /tools/lib
>> + * @modules jdk.compiler/com.sun.tools.javac.api
>> + *          jdk.compiler/com.sun.tools.javac.main
>> + *          jdk.jdeps/com.sun.tools.javap
>> + * @build toolbox.ToolBox toolbox.JavacTask toolbox.JavapTask
>> + * @run main CodeAttributeIndentation
>> + */
>> +
>> +import toolbox.ToolBox;
>> +import toolbox.JavacTask;
>> +import toolbox.JavapTask;
>> +import toolbox.Task.OutputKind;
>> +
>> +public class CodeAttributeIndentation {
>> +    public static void main(String... args) {
>> +        String LS = System.getProperty("line.separator");
>> +
>> +        String src = (
>> +            "public class A {\n" +
>> +            "    public void a() {}\n" +
>> +            "}"
>> +            ).replaceAll("\n", LS);
>> +
>> +        String expected = (
>> +            "Compiled from \"A.java\"\n" +
>> +            "public class A {\n" +
>> +            "  public A();\n" +
>> +            "    Code:\n" +
>> +            "         0: aload_0\n" +
>> +            "         1: invokespecial #1                  " +
>> +            "// Method java/lang/Object.\"<init>\":()V\n" +
>> +            "         4: return\n" +
>> +            "      LineNumberTable:\n" +
>> +            "        line 1: 0\n" +
>> +            "      LocalVariableTable:\n" +
>> +            "        Start  Length  Slot  Name   Signature\n" +
>> +            "            0       5     0  this   LA;\n" +
>> +            "\n" +
>> +            "  public void a();\n" +
>> +            "    Code:\n" +
>> +            "         0: return\n" +
>> +            "      LineNumberTable:\n" +
>> +            "        line 2: 0\n" +
>> +            "      LocalVariableTable:\n" +
>> +            "        Start  Length  Slot  Name   Signature\n" +
>> +            "            0       1     0  this   LA;\n" +
>> +            "}\n"
>> +            ).replaceAll("\n", LS);
>> +
>> +        ToolBox tb = new ToolBox();
>> +
>> +        new JavacTask(tb).options("-g").sources(src).run();
>> +
>> +        String actual = new JavapTask(tb).options("-c",
>> "-l").classes("A.class")
>> +                .run().getOutput(OutputKind.DIRECT);
>> +
>> +        if (!actual.equals(expected))
>> +            throw new AssertionError("Incorrect code attribute indentation: " +
>> +                    LS + actual);
>> +    }
>> +}


From maurizio.cimadamore at oracle.com  Sat Jul  1 21:17:23 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sat, 1 Jul 2017 22:17:23 +0100
Subject: JDK 10: Refactoring of LetExpr to allow more than one statement
In-Reply-To: <CAEgw74D2+FkbGvQvp4fp75KRdMVa1g=GnmUBiU8eX98nx-9D9Q@mail.gmail.com>
References: <CAEgw74AcP_J6xq3_iqXmgUhde+16LMO88Y-UR1SMM49OYqQgkQ@mail.gmail.com>
 <9419157b-1296-33db-544c-db0c7cda6598@oracle.com>
 <CAEgw74D2+FkbGvQvp4fp75KRdMVa1g=GnmUBiU8eX98nx-9D9Q@mail.gmail.com>
Message-ID: <01a6703b-2f73-ccb8-152a-864c607cdca6@oracle.com>

Sure - go ahead, thanks!

Maurizio


On 01/07/17 09:43, B. Blaser wrote:
> Hi,
>
> On 10 May 2017 at 23:00, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> Hi,
>> I think that we're I'd like to see things moving is more in the direction of
>> block expressions, which allow even more freedom. That is, a list of
>> statements (maybe var decls, but maybe not), followed by an expression
>> (which is the expression value). I think this could be a powerful tool that
>> could come handy for some of the features discussed under the Amber
>> umbrella. So, I agree with you that LetExpr should be improved, but I guess
>> I'm in for a more radical overhaul ;-)
> Should I create a JBS issue only for the optimization of
> Lower.makeComma(), not to forget it once LetExpr will be updated?
>
> Thanks,
> Bernard
>
>> Maurizio
>>
>>
>>
>> On 10/05/17 21:14, B. Blaser wrote:
>>> Hi,
>>>
>>> I've suggested some time ago a refactoring of LetExpr to generate a
>>> more optimized code in some cases, see [1].
>>>
>>> The key idea is to allow LetExpr to have more than one statement in
>>> addition to multiple variable declarations. This would lead to a more
>>> optimal translation of comma-expressions, see [1].
>>>
>>> This suggestion refers to let-expressions in Lisp which allow more
>>> than one statement in addition to multiple variable declarations, see
>>> [2].
>>>
>>> Are you interested in such a feature? Should I create a JBS issue for
>>> that to be integrated in JDK 10?
>>>
>>> Regards,
>>> Bernard
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010531.html
>>> [2) http://www.lispworks.com/documentation/HyperSpec/Body/s_let_l.htm
>>


From jonathan.gibbons at oracle.com  Mon Jul  3 20:36:27 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 03 Jul 2017 13:36:27 -0700
Subject: RFR: 8183505: Update langtools tests to allow for unique test classes
 directory
Message-ID: <595AAACB.2010605@oracle.com>

jtreg has been updated via CODETOOLS-7902003 [1] to use a unique 
test.classes directory. This is part of improving the reliability when 
running tests concurrently. The change exposes issues in a small number 
of tests in the hotspot, jdk, and langtools repos and these issues will 
need to be fixed before the requiredVersion can be bumped to use a 
promoted jtreg with this change.

The few changes are all related to deriving the path for the library 
classes from test.class.path, instead of assuming a fixed relationship 
to the test's classes.

I'd like to push these to jdk10/jdk10 so that they can meet up with 
changes coming for related issues in the jdk and hotspot repos.

JBS: https://bugs.openjdk.java.net/browse/JDK-8183505
Webrev: http://cr.openjdk.java.net/~jjg/8183505/webrev.00/

-- Jon

From steff.nicolas at gmail.com  Tue Jul  4 01:19:46 2017
From: steff.nicolas at gmail.com (=?UTF-8?Q?St=C3=A9phane_NICOLAS?=)
Date: Mon, 3 Jul 2017 18:19:46 -0700
Subject: How to serialize elements (or lookup elements efficiently) ?
Message-ID: <CALo37o6nNUEjvRi8GTFcgUQyWg4YwLeSKf15KU3Q3YEwGEYcvg@mail.gmail.com>

I am looking for a way to serialize elements between builds,
or, as it looks no such mechanism exists out of the box, I am looking for a
way to encode their location and being able to retrieve the new element in
the new build using this location.

What would be the best way to do this ?

Thx in advance,
 S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170703/ebb0e675/attachment.html>

From Alan.Bateman at oracle.com  Tue Jul  4 09:06:33 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 4 Jul 2017 10:06:33 +0100
Subject: RFR: 8183505: Update langtools tests to allow for unique test
 classes directory
In-Reply-To: <595AAACB.2010605@oracle.com>
References: <595AAACB.2010605@oracle.com>
Message-ID: <fd724f39-737e-3ada-c7a8-df56c42c956b@oracle.com>

On 03/07/2017 21:36, Jonathan Gibbons wrote:
> jtreg has been updated via CODETOOLS-7902003 [1] to use a unique 
> test.classes directory. This is part of improving the reliability when 
> running tests concurrently. The change exposes issues in a small 
> number of tests in the hotspot, jdk, and langtools repos and these 
> issues will need to be fixed before the requiredVersion can be bumped 
> to use a promoted jtreg with this change.
>
> The few changes are all related to deriving the path for the library 
> classes from test.class.path, instead of assuming a fixed relationship 
> to the test's classes.
Looks okay although some tests using endsWith whereas others use 
getFileName().toString(). Either is fine of course.

-Alan

From jonathan.gibbons at oracle.com  Tue Jul  4 13:23:02 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 4 Jul 2017 06:23:02 -0700
Subject: RFR: 8183505: Update langtools tests to allow for unique test
 classes directory
In-Reply-To: <fd724f39-737e-3ada-c7a8-df56c42c956b@oracle.com>
References: <595AAACB.2010605@oracle.com>
 <fd724f39-737e-3ada-c7a8-df56c42c956b@oracle.com>
Message-ID: <2b50bd49-0010-c1b1-194a-b1ff77a61885@oracle.com>



On 7/4/17 2:06 AM, Alan Bateman wrote:
> On 03/07/2017 21:36, Jonathan Gibbons wrote:
>> jtreg has been updated via CODETOOLS-7902003 [1] to use a unique 
>> test.classes directory. This is part of improving the reliability 
>> when running tests concurrently. The change exposes issues in a small 
>> number of tests in the hotspot, jdk, and langtools repos and these 
>> issues will need to be fixed before the requiredVersion can be bumped 
>> to use a promoted jtreg with this change.
>>
>> The few changes are all related to deriving the path for the library 
>> classes from test.class.path, instead of assuming a fixed 
>> relationship to the test's classes.
> Looks okay although some tests using endsWith whereas others use 
> getFileName().toString(). Either is fine of course.
>
> -Alan
Noted.   The tests using .endsWith were using Strings, the tests using 
getFileName().toString() were using Path ... but I see I can clean those 
up to use Path.endsWith as well.

-- Jon

From bsrbnd at gmail.com  Tue Jul  4 17:10:38 2017
From: bsrbnd at gmail.com (B. Blaser)
Date: Tue, 4 Jul 2017 19:10:38 +0200
Subject: JDK 10: Refactoring of LetExpr to allow more than one statement
In-Reply-To: <01a6703b-2f73-ccb8-152a-864c607cdca6@oracle.com>
References: <CAEgw74AcP_J6xq3_iqXmgUhde+16LMO88Y-UR1SMM49OYqQgkQ@mail.gmail.com>
 <9419157b-1296-33db-544c-db0c7cda6598@oracle.com>
 <CAEgw74D2+FkbGvQvp4fp75KRdMVa1g=GnmUBiU8eX98nx-9D9Q@mail.gmail.com>
 <01a6703b-2f73-ccb8-152a-864c607cdca6@oracle.com>
Message-ID: <CAEgw74B0zhHTQvHSyVetXhGHrtjQ7nY_F982sLAvCvscJpOs7w@mail.gmail.com>

Done: https://bugs.openjdk.java.net/browse/JDK-8183548

Bernard

On 1 July 2017 at 23:17, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> Sure - go ahead, thanks!
>
> Maurizio
>
>
>
> On 01/07/17 09:43, B. Blaser wrote:
>>
>> Hi,
>>
>> On 10 May 2017 at 23:00, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>>
>>> Hi,
>>> I think that we're I'd like to see things moving is more in the direction
>>> of
>>> block expressions, which allow even more freedom. That is, a list of
>>> statements (maybe var decls, but maybe not), followed by an expression
>>> (which is the expression value). I think this could be a powerful tool
>>> that
>>> could come handy for some of the features discussed under the Amber
>>> umbrella. So, I agree with you that LetExpr should be improved, but I
>>> guess
>>> I'm in for a more radical overhaul ;-)
>>
>> Should I create a JBS issue only for the optimization of
>> Lower.makeComma(), not to forget it once LetExpr will be updated?
>>
>> Thanks,
>> Bernard
>>
>>> Maurizio
>>>
>>>
>>>
>>> On 10/05/17 21:14, B. Blaser wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've suggested some time ago a refactoring of LetExpr to generate a
>>>> more optimized code in some cases, see [1].
>>>>
>>>> The key idea is to allow LetExpr to have more than one statement in
>>>> addition to multiple variable declarations. This would lead to a more
>>>> optimal translation of comma-expressions, see [1].
>>>>
>>>> This suggestion refers to let-expressions in Lisp which allow more
>>>> than one statement in addition to multiple variable declarations, see
>>>> [2].
>>>>
>>>> Are you interested in such a feature? Should I create a JBS issue for
>>>> that to be integrated in JDK 10?
>>>>
>>>> Regards,
>>>> Bernard
>>>>
>>>> [1]
>>>>
>>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010531.html
>>>> [2) http://www.lispworks.com/documentation/HyperSpec/Body/s_let_l.htm
>>>
>>>
>

From maurizio.cimadamore at oracle.com  Tue Jul  4 20:46:39 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 4 Jul 2017 21:46:39 +0100
Subject: JDK 10: Refactoring of LetExpr to allow more than one statement
In-Reply-To: <CAEgw74B0zhHTQvHSyVetXhGHrtjQ7nY_F982sLAvCvscJpOs7w@mail.gmail.com>
References: <CAEgw74AcP_J6xq3_iqXmgUhde+16LMO88Y-UR1SMM49OYqQgkQ@mail.gmail.com>
 <9419157b-1296-33db-544c-db0c7cda6598@oracle.com>
 <CAEgw74D2+FkbGvQvp4fp75KRdMVa1g=GnmUBiU8eX98nx-9D9Q@mail.gmail.com>
 <01a6703b-2f73-ccb8-152a-864c607cdca6@oracle.com>
 <CAEgw74B0zhHTQvHSyVetXhGHrtjQ7nY_F982sLAvCvscJpOs7w@mail.gmail.com>
Message-ID: <1d5c2822-92f8-4b1b-416d-07d67545d3b5@oracle.com>

Thanks!

Maurizio


On 04/07/17 18:10, B. Blaser wrote:
> Done: https://bugs.openjdk.java.net/browse/JDK-8183548
>
> Bernard
>
> On 1 July 2017 at 23:17, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> Sure - go ahead, thanks!
>>
>> Maurizio
>>
>>
>>
>> On 01/07/17 09:43, B. Blaser wrote:
>>> Hi,
>>>
>>> On 10 May 2017 at 23:00, Maurizio Cimadamore
>>> <maurizio.cimadamore at oracle.com> wrote:
>>>> Hi,
>>>> I think that we're I'd like to see things moving is more in the direction
>>>> of
>>>> block expressions, which allow even more freedom. That is, a list of
>>>> statements (maybe var decls, but maybe not), followed by an expression
>>>> (which is the expression value). I think this could be a powerful tool
>>>> that
>>>> could come handy for some of the features discussed under the Amber
>>>> umbrella. So, I agree with you that LetExpr should be improved, but I
>>>> guess
>>>> I'm in for a more radical overhaul ;-)
>>> Should I create a JBS issue only for the optimization of
>>> Lower.makeComma(), not to forget it once LetExpr will be updated?
>>>
>>> Thanks,
>>> Bernard
>>>
>>>> Maurizio
>>>>
>>>>
>>>>
>>>> On 10/05/17 21:14, B. Blaser wrote:
>>>>> Hi,
>>>>>
>>>>> I've suggested some time ago a refactoring of LetExpr to generate a
>>>>> more optimized code in some cases, see [1].
>>>>>
>>>>> The key idea is to allow LetExpr to have more than one statement in
>>>>> addition to multiple variable declarations. This would lead to a more
>>>>> optimal translation of comma-expressions, see [1].
>>>>>
>>>>> This suggestion refers to let-expressions in Lisp which allow more
>>>>> than one statement in addition to multiple variable declarations, see
>>>>> [2].
>>>>>
>>>>> Are you interested in such a feature? Should I create a JBS issue for
>>>>> that to be integrated in JDK 10?
>>>>>
>>>>> Regards,
>>>>> Bernard
>>>>>
>>>>> [1]
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010531.html
>>>>> [2) http://www.lispworks.com/documentation/HyperSpec/Body/s_let_l.htm
>>>>


From cushon at google.com  Thu Jul  6 19:27:54 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 6 Jul 2017 12:27:54 -0700
Subject: RFR: 8181897: JDK 9 change to symlink handling affects SourceFile
 attributes
In-Reply-To: <595129EF.7090005@oracle.com>
References: <595129EF.7090005@oracle.com>
Message-ID: <CAL4Qsgs2ktLb1gZjEQYjb+A5AfcF+c9ipNrVXNj0RwCdWW3a+Q@mail.gmail.com>

Thanks Jan - this looks good to me, for what that's worth.

On Mon, Jun 26, 2017 at 8:36 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:

> Hi,
>
> I'd like to propose a simple fix for:
> https://bugs.openjdk.java.net/browse/JDK-8181897
>
> The proposed fix is to use the original/user path for toUri():
> http://cr.openjdk.java.net/~jlahoda/8181897/webrev.00/
>
> I believe this is conceptually consistent with the JDK 8 behavior.
>
> Jan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170706/f859a7b8/attachment.html>

From steff.nicolas at gmail.com  Sat Jul  8 18:00:55 2017
From: steff.nicolas at gmail.com (=?UTF-8?Q?St=C3=A9phane_NICOLAS?=)
Date: Sat, 8 Jul 2017 11:00:55 -0700
Subject: How to access elements outside an Annotation Processor
Message-ID: <CALo37o5jvAwX1PVH1J4RP3T4a9mRykXtx5oqJzgqHMqqm7oAzw@mail.gmail.com>

Hi there,

my last question about elements (de)serialization didn't really catch your
attention, but I try again !
:)

I would like to have the advises of people on this list to access elements
outside an AP.

Context: I am developing a build tool and would need, given a list of
files, to access all elements annotated with a given set of annotations.

I read the javac's compiler code and found out that javac does it via the
JavaProcessingEnvironment, that create a RoundEnvironment that in turn uses
a TypeUtil instance and a visitor to scan all elements and return those
which are annotated.

But the internals of javac are a bit complex, is there a simpler way to do
this ? What would you recommend ?
Please note that I want to do this BEFORE annotation processing itself,
hence I can't use an Annotation Processor to achieve it.

Thanks in advance and thanks for this amazing compiler !

S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170708/df2e21c6/attachment.html>

From jonathan.gibbons at oracle.com  Sat Jul  8 19:56:14 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sat, 8 Jul 2017 12:56:14 -0700
Subject: How to access elements outside an Annotation Processor
In-Reply-To: <CALo37o5jvAwX1PVH1J4RP3T4a9mRykXtx5oqJzgqHMqqm7oAzw@mail.gmail.com>
References: <CALo37o5jvAwX1PVH1J4RP3T4a9mRykXtx5oqJzgqHMqqm7oAzw@mail.gmail.com>
Message-ID: <a402a01e-abe4-6c1a-5348-52f976f16d50@oracle.com>

If you want to do work before annotation processing, you can use a 
combination of the

     Compiler Tree API (com.sun.source.*). As well as proving access to 
the AST, it also provides API to supply TaskListeners to be invoked at 
different points in the compilation pipeline. There is also a command 
line option that allows you to specify a "plugin" which will be invoked 
after option decoding, and which can register task listeners to be 
called later on.

     Language Model API (javax.lang.model.*). But note, while you can 
walk the AST as soon as its available, you won't be able to access the 
Elements to which names refer until later in the compilation pipeline. 
And, for annotations, that is round about the time that annotation 
processing occurs.

-- Jon


On 7/8/17 11:00 AM, St?phane NICOLAS wrote:
> Hi there,
>
> my last question about elements (de)serialization didn't really catch 
> your attention, but I try again !
> :)
>
> I would like to have the advises of people on this list to access 
> elements outside an AP.
>
> Context: I am developing a build tool and would need, given a list of 
> files, to access all elements annotated with a given set of annotations.
>
> I read the javac's compiler code and found out that javac does it via 
> the JavaProcessingEnvironment, that create a RoundEnvironment that in 
> turn uses a TypeUtil instance and a visitor to scan all elements and 
> return those which are annotated.
>
> But the internals of javac are a bit complex, is there a simpler way 
> to do this ? What would you recommend ?
> Please note that I want to do this BEFORE annotation processing 
> itself, hence I can't use an Annotation Processor to achieve it.
>
> Thanks in advance and thanks for this amazing compiler !
>
> S.
>


From shafi.s.ahmad at oracle.com  Thu Jul 13 07:20:07 2017
From: shafi.s.ahmad at oracle.com (Shafi Ahmad)
Date: Thu, 13 Jul 2017 00:20:07 -0700 (PDT)
Subject: [10] RFR for JDK-8181500: [TESTBUG] com/sun/jdi/LineNumberInfo.java
 fails with jArrayIndexOutOfBoundsException
Message-ID: <c4a15219-ce55-4a3d-b984-d4fed48d6b6c@default>

Hi,

Please review the trivial  change for the fix of bug 'JDK-8181500: [TESTBUG] com/sun/jdi/LineNumberInfo.java fails with jArrayIndexOutOfBoundsException'

Summary:
This test is sensitive to the compiler's code generation and recently we did some changes to fix 'JDK-8180660: missing LNT entry for finally block'. 
As the fix of  JDK-8180660 emit missing line number table entry so we have to update the line number table and code indices table of test test/com/sun/jdi/LineNumberInfo.java.

jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8181500
webrev link: http://cr.openjdk.java.net/~shshahma/8181500/webrev.00/

Testing: run jprt

Regards,
Shafi

From vicente.romero at oracle.com  Thu Jul 13 13:42:43 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 13 Jul 2017 09:42:43 -0400
Subject: [10] RFR for JDK-8181500: [TESTBUG]
 com/sun/jdi/LineNumberInfo.java fails with jArrayIndexOutOfBoundsException
In-Reply-To: <c4a15219-ce55-4a3d-b984-d4fed48d6b6c@default>
References: <c4a15219-ce55-4a3d-b984-d4fed48d6b6c@default>
Message-ID: <8089ffe8-d2eb-f63f-94d5-88a39bb7b0d8@oracle.com>

looks good,
Vicente

On 07/13/2017 03:20 AM, Shafi Ahmad wrote:
> Hi,
>
> Please review the trivial  change for the fix of bug 'JDK-8181500: [TESTBUG] com/sun/jdi/LineNumberInfo.java fails with jArrayIndexOutOfBoundsException'
>
> Summary:
> This test is sensitive to the compiler's code generation and recently we did some changes to fix 'JDK-8180660: missing LNT entry for finally block'.
> As the fix of  JDK-8180660 emit missing line number table entry so we have to update the line number table and code indices table of test test/com/sun/jdi/LineNumberInfo.java.
>
> jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8181500
> webrev link: http://cr.openjdk.java.net/~shshahma/8181500/webrev.00/
>
> Testing: run jprt
>
> Regards,
> Shafi


From steff.nicolas at gmail.com  Thu Jul 13 14:42:38 2017
From: steff.nicolas at gmail.com (=?UTF-8?Q?St=C3=A9phane_NICOLAS?=)
Date: Thu, 13 Jul 2017 07:42:38 -0700
Subject: How to Use a Task Listener in a different process ?
Message-ID: <CALo37o7g9H0L6cssgCnyMqmErSYFLyzR5qCqEEPeo_RDn3hYBQ@mail.gmail.com>

Hello,

in gradle, they run the compiler in a different process.
I am wondering how to pass a TaskListener in the context. I saw there was a
call to context.get(TaskListener.class) but couldn't find the entry point
to add it properly to the context,
especially if the task is gonna run in a different process.

How is it supposed to work ?

Thanks in advance,
 S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170713/18e013a7/attachment.html>

From jonathan.gibbons at oracle.com  Thu Jul 13 14:59:44 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 13 Jul 2017 07:59:44 -0700
Subject: How to Use a Task Listener in a different process ?
In-Reply-To: <CALo37o7g9H0L6cssgCnyMqmErSYFLyzR5qCqEEPeo_RDn3hYBQ@mail.gmail.com>
References: <CALo37o7g9H0L6cssgCnyMqmErSYFLyzR5qCqEEPeo_RDn3hYBQ@mail.gmail.com>
Message-ID: <669a6799-e84b-49f1-e35b-cc205284f8b1@oracle.com>

Anything to do with contexts is internal API, and hopefully you should 
not need to go there.

If you're dealing with the compiler in another process, I'd recommend 
you investigate the -Xplugin option.  With the option, you can register 
a plugin as a service, and request that it be started from the command 
line, with any desired arguments. The plugin will be located on the same 
path(s) used for annotation processors (i.e. -processorpath).  When the 
plugin is invoked, you can create and register task listeners.

-- Jon



On 7/13/17 7:42 AM, St?phane NICOLAS wrote:
> Hello,
>
> in gradle, they run the compiler in a different process.
> I am wondering how to pass a TaskListener in the context. I saw there 
> was a call to context.get(TaskListener.class) but couldn't find the 
> entry point to add it properly to the context,
> especially if the task is gonna run in a different process.
>
> How is it supposed to work ?
>
> Thanks in advance,
>  S.
>


From shafi.s.ahmad at oracle.com  Mon Jul 17 09:44:31 2017
From: shafi.s.ahmad at oracle.com (Shafi Ahmad)
Date: Mon, 17 Jul 2017 02:44:31 -0700 (PDT)
Subject: [10] RFR for JDK-8181500: [TESTBUG]
 com/sun/jdi/LineNumberInfo.java fails with jArrayIndexOutOfBoundsException
In-Reply-To: <8089ffe8-d2eb-f63f-94d5-88a39bb7b0d8@oracle.com>
References: <c4a15219-ce55-4a3d-b984-d4fed48d6b6c@default>
 <8089ffe8-d2eb-f63f-94d5-88a39bb7b0d8@oracle.com>
Message-ID: <4e9eae7b-0c36-45f3-8fde-42ea3775cbd7@default>

Thank you Vicente.

May I get the second review on this change.

Regards,
Shafi

> -----Original Message-----
> From: Vicente Romero
> Sent: Thursday, July 13, 2017 7:13 PM
> To: Shafi Ahmad <shafi.s.ahmad at oracle.com>; compiler-
> dev at openjdk.java.net
> Cc: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
> Subject: Re: [10] RFR for JDK-8181500: [TESTBUG]
> com/sun/jdi/LineNumberInfo.java fails with
> jArrayIndexOutOfBoundsException
> 
> looks good,
> Vicente
> 
> On 07/13/2017 03:20 AM, Shafi Ahmad wrote:
> > Hi,
> >
> > Please review the trivial  change for the fix of bug 'JDK-8181500: [TESTBUG]
> com/sun/jdi/LineNumberInfo.java fails with
> jArrayIndexOutOfBoundsException'
> >
> > Summary:
> > This test is sensitive to the compiler's code generation and recently we did
> some changes to fix 'JDK-8180660: missing LNT entry for finally block'.
> > As the fix of  JDK-8180660 emit missing line number table entry so we have
> to update the line number table and code indices table of test
> test/com/sun/jdi/LineNumberInfo.java.
> >
> > jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8181500
> > webrev link: http://cr.openjdk.java.net/~shshahma/8181500/webrev.00/
> >
> > Testing: run jprt
> >
> > Regards,
> > Shafi
> 

From Ronald_Servant at ca.ibm.com  Tue Jul 18 19:52:54 2017
From: Ronald_Servant at ca.ibm.com (Ronald Servant)
Date: Tue, 18 Jul 2017 19:52:54 +0000
Subject: Behaviour change between Java 8 and Java 9 javac
Message-ID: <OF389B3404.66A52798-ON00258161.006CDB78-00258161.006D36A9@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170718/895bee3f/attachment.html>

From alex.buckley at oracle.com  Tue Jul 18 20:00:27 2017
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 18 Jul 2017 13:00:27 -0700
Subject: Behaviour change between Java 8 and Java 9 javac
In-Reply-To: <OF389B3404.66A52798-ON00258161.006CDB78-00258161.006D36A9@notes.na.collabserv.com>
References: <OF389B3404.66A52798-ON00258161.006CDB78-00258161.006D36A9@notes.na.collabserv.com>
Message-ID: <596E68DB.9000209@oracle.com>

This is an intended change, see 
https://bugs.openjdk.java.net/browse/JDK-8034044.

I confess that I am unable to find anything about this user-visible 
change in the early-access JDK 9 Release Notes 
(http://jdk.java.net/9/release-notes).

Alex

On 7/18/2017 12:52 PM, Ronald Servant wrote:
> Hi,
> We have noticed a change in how java9 and java8 javac compile classes
> with static anonymous inner classes.
> With the java8 compiler, static anonymous inner classes have a static
> modifier, but with the java9 javac they do not. We are unclear as to
> whether this is an intended change or a defect with the newer compiler.
> Is an intended behaviour change?
> The following code sample displays the issue:
> ---------------------------------------------
> import java.lang.reflect.Modifier;
> public class TestStaticModifier {
>      static Object staticInnerAnonymousObject = new Object() {};
>      static Class<?> staticInnerAnonymousClazz =
> staticInnerAnonymousObject.getClass();
>
>      public static void main(String[] args) {
>          TestStaticModifier tsm = new TestStaticModifier();
>          getClassInfoStatic(staticInnerAnonymousClazz);
>      }
>
>      public static void getClassInfoStatic(Class<?> clazz) {
>          System.out.println("Name : " + clazz.getName());
>          System.out.println("Anonymous : " + clazz.isAnonymousClass());
>          System.out.println("static ? " +
> Modifier.isStatic(clazz.getModifiers()));
>      }
>
> }
> ---------------------------------------------
> With java8:
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
> javac generates the following in the classfile:
> InnerClasses:
>       static #20; //class TestStaticModifier$1
>
> When the program is run it outputs:
> Name : TestStaticModifier$1
> Anonymous : true
> static ? true
>
> With java9:
> openjdk version "9-internal"
> OpenJDK Runtime Environment (build 9-internal+0-adhoc.arnold.jdk9175)
> OpenJDK 64-Bit Server VM (build 9-internal+0-adhoc.arnold.jdk9175, mixed
> mode)
> javac generates the following in the classfile:
> InnerClasses:
>    #20;                                    // class TestStaticModifier$1
> When the program is run it outputs:
> Name : TestStaticModifier$1
> Anonymous : true
> static ? false
>

From steff.nicolas at gmail.com  Mon Jul  3 07:02:56 2017
From: steff.nicolas at gmail.com (=?UTF-8?Q?St=C3=A9phane_NICOLAS?=)
Date: Mon, 03 Jul 2017 07:02:56 -0000
Subject: How to serialize elements (or to lookup up for them efficiently) ?
Message-ID: <CALo37o6FGnaCprpK_Cr-q9vBo8TwJQ+G=12KYBnO5E83YGgynQ@mail.gmail.com>

I am looking for a way to serialize elements between builds,
or, as it looks no such mechanism exists out of the box, I am looking for a
way to encode their location and being able to retrieve the new element in
the new build using this location.

What would be the best way to do this ?

Thx in advance,
 S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170703/c8aa7c3f/attachment.html>

From andrey.petushkov at gmail.com  Mon Jul 31 14:30:53 2017
From: andrey.petushkov at gmail.com (Andrey Petushkov)
Date: Mon, 31 Jul 2017 17:30:53 +0300
Subject: RFR: JDK-8184989. Incorrect class file created when passing lambda in
 inner class constructor and outer is subclass
Message-ID: <B713E33A-9515-42CD-9029-5EF0A927F33C@gmail.com>

Dear Compiler Team,

We?ve occasionally found out that there is a problem in javac related to lambda support, in part related to referencing the outer?s entity which otherwise would be captured by using inner this, but cannot be since it?s not yet fully initialized. More specifically this seem to be omission in the fix for JDK-8129740 <https://bugs.openjdk.java.net/browse/JDK-8129740>:
it's fix works fine if it deals with the entity from the outer class(es), but fails if the entity is inherited from outer?s parent. Consider the following source code:

A.java 
public class A { 
    public boolean test(){ 
        return true; 
    } 
    class AA{ 
        public AA(Condition condition) { 
        } 
    } 
} 

Condition.java 
public interface Condition<T> { 
    boolean check(T t); 
} 

B.java 
public class B extends A { 
    private final BA myBA; 
    public B() { 
        myBA = new BA(); 
    } 
    public class BA extends AA{ 
        public BA() { 
            super(o -> test()); 
        } 
    } 
    public static void main(String[] args) { 
        B b = new B(); 
        System.out.println(b); 
    } 
}
 

source compiles but execution of B fails with: 
Exception in thread "main" java.lang.VerifyError: Bad type on operand stack 
Exception Details: 
  Location: 
    B$BA.lambda$new$0(LB;Ljava/lang/Object;)Z @1: getfield 
  Reason: 
    Type 'B' (current frame, stack[0]) is not assignable to 'B$BA' 
  Current Frame: 
    bci: @1 
    flags: { } 
    locals: { 'B', 'java/lang/Object' } 
    stack: { 'B' } 
  Bytecode: 
    0x0000000: 2ab4 0001 b600 04ac 

at B.<init>(B.java:6) 
at B.main(B.java:17) 

The problem is reproduced on both latest 8u and 9 (by the time of the bug submission)

My naive attempt to fix could be seen here http://cr.openjdk.java.net/~apetushkov/8184989/webrev/ <http://cr.openjdk.java.net/~apetushkov/8184989/webrev/> (based on latest 8u)
Please could you consider reviewing/improving it or suggesting improvement direction as appropriate

Thanks,
Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170731/e24e6a6f/attachment-0001.html>