JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

joe darcy
Hello,

Please review the straightforward fix to address:

     JDK-8173609: Elements.printElements needs to support modules
     http://cr.openjdk.java.net/~darcy/8173609.0/

Once additional information about modules is available (JDK-8172810:
ModuleElement should declare and provide appropriate modifiers), the
printing processor should be updated to expose that information.

Admittedly this changeset would be better with some regression testing.

Thanks,

-Joe

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

Remi Forax
Hi Joe,
i believe that all non public methods you have added can be declared private,
and printNameableList can use a stream and a collector

  private void printNameableList(List<? extends QualifiedNameable> nameables) {
    writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(", "));
  }

cheers,
Rémi

----- Mail original -----
> De: "joe darcy" <[hidden email]>
> À: [hidden email]
> Envoyé: Samedi 28 Janvier 2017 22:39:26
> Objet: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

> Hello,
>
> Please review the straightforward fix to address:
>
>     JDK-8173609: Elements.printElements needs to support modules
>     http://cr.openjdk.java.net/~darcy/8173609.0/
>
> Once additional information about modules is available (JDK-8172810:
> ModuleElement should declare and provide appropriate modifiers), the
> printing processor should be updated to expose that information.
>
> Admittedly this changeset would be better with some regression testing.
>
> Thanks,
>
> -Joe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

joe darcy
Hi Remi,


On 1/29/2017 3:21 AM, Remi Forax wrote:
> Hi Joe,
> i believe that all non public methods you have added can be declared private,

Good point; I'll make that change before pushing.

> and printNameableList can use a stream and a collector
>
>    private void printNameableList(List<? extends QualifiedNameable> nameables) {
>      writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(", "));

I thought of using that style instead and changed some core reflection
code to use streams and collectors earlier in 9 (JDK-8162817: Annotation
toString output not reusable for source input).

I'll let Jon or Jan weigh in on which style is preferred for javac.

Thanks,

-Joe

>    }
>
> cheers,
> Rémi
>
> ----- Mail original -----
>> De: "joe darcy" <[hidden email]>
>> À: [hidden email]
>> Envoyé: Samedi 28 Janvier 2017 22:39:26
>> Objet: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules
>> Hello,
>>
>> Please review the straightforward fix to address:
>>
>>      JDK-8173609: Elements.printElements needs to support modules
>>      http://cr.openjdk.java.net/~darcy/8173609.0/
>>
>> Once additional information about modules is available (JDK-8172810:
>> ModuleElement should declare and provide appropriate modifiers), the
>> printing processor should be updated to expose that information.
>>
>> Admittedly this changeset would be better with some regression testing.
>>
>> Thanks,
>>
>> -Joe

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

B. Blaser
In reply to this post by joe darcy
Joe,

2017-01-28 22:39 GMT+01:00 joe darcy <[hidden email]>:

> Hello,
>
> Please review the straightforward fix to address:
>
>     JDK-8173609: Elements.printElements needs to support modules
>     http://cr.openjdk.java.net/~darcy/8173609.0/
>
> Once additional information about modules is available (JDK-8172810:
> ModuleElement should declare and provide appropriate modifiers), the
> printing processor should be updated to expose that information.
>
> Admittedly this changeset would be better with some regression testing.
>
> Thanks,
>
> -Joe
>
Here is a test for that.
Regards,
Bernard

diff --git a/test/tools/javac/modules/T8173609/module-info.java
b/test/tools/javac/modules/T8173609/module-info.java
new file mode 100644
--- /dev/null
+++ b/test/tools/javac/modules/T8173609/module-info.java
@@ -0,0 +1,13 @@
+/*
+ * @test
+ * @bug 8173609
+ * @summary printing of modules
+ * @compile/ref=module-info.out -Xprint p/P.java module-info.java
+ */
+module JDK_8173609 {
+    requires static transitive java.base;
+    exports p to m.m1, m.m2;
+    opens p to m.m1, m.m2;
+    uses p.P;
+    provides p.P with p.P.P1, p.P.P2;
+}
diff --git a/test/tools/javac/modules/T8173609/module-info.out
b/test/tools/javac/modules/T8173609/module-info.out
new file mode 100644
--- /dev/null
+++ b/test/tools/javac/modules/T8173609/module-info.out
@@ -0,0 +1,23 @@
+package p;
+
+public class P {
+
+  public static class P1 extends p.P {
+
+    public P1();
+  }
+
+  public static class P2 extends p.P {
+
+    public P2();
+  }
+
+  public P();
+}
+module JDK_8173609 {
+  requires static transitive java.base;
+  exports p to m.m1, m.m2;
+  opens p to m.m1, m.m2;
+  uses p.P;
+  provides p.P with p.P.P1, p.P.P2;
+}
diff --git a/test/tools/javac/modules/T8173609/p/P.java
b/test/tools/javac/modules/T8173609/p/P.java
new file mode 100644
--- /dev/null
+++ b/test/tools/javac/modules/T8173609/p/P.java
@@ -0,0 +1,6 @@
+package p;
+
+public class P {
+    public static class P1 extends P {}
+    public static class P2 extends P {}
+}
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

Jan Lahoda
In reply to this post by joe darcy
On 29.1.2017 21:55, joe darcy wrote:

> Hi Remi,
>
>
> On 1/29/2017 3:21 AM, Remi Forax wrote:
>> Hi Joe,
>> i believe that all non public methods you have added can be declared
>> private,
>
> Good point; I'll make that change before pushing.
>
>> and printNameableList can use a stream and a collector
>>
>>    private void printNameableList(List<? extends QualifiedNameable>
>> nameables) {
>>
>> writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(",
>> "));
>
> I thought of using that style instead and changed some core reflection
> code to use streams and collectors earlier in 9 (JDK-8162817: Annotation
> toString output not reusable for source input).
>
> I'll let Jon or Jan weigh in on which style is preferred for javac.

I personally think both are fine here: using stream and collector avoids
the auxiliary variable ("first"); using the loop avoids the need to
construct the compound string by writing the elements to the output one
by one.

Jan

>
> Thanks,
>
> -Joe
>
>>    }
>>
>> cheers,
>> Rémi
>>
>> ----- Mail original -----
>>> De: "joe darcy" <[hidden email]>
>>> À: [hidden email]
>>> Envoyé: Samedi 28 Janvier 2017 22:39:26
>>> Objet: JDK 9 RFR of JDK-8173609: Elements.printElements needs to
>>> support    modules
>>> Hello,
>>>
>>> Please review the straightforward fix to address:
>>>
>>>      JDK-8173609: Elements.printElements needs to support modules
>>>      http://cr.openjdk.java.net/~darcy/8173609.0/
>>>
>>> Once additional information about modules is available (JDK-8172810:
>>> ModuleElement should declare and provide appropriate modifiers), the
>>> printing processor should be updated to expose that information.
>>>
>>> Admittedly this changeset would be better with some regression testing.
>>>
>>> Thanks,
>>>
>>> -Joe
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

Jonathan Gibbons
In reply to this post by joe darcy


On 01/29/2017 12:55 PM, joe darcy wrote:

> Hi Remi,
>
>
> On 1/29/2017 3:21 AM, Remi Forax wrote:
>> Hi Joe,
>> i believe that all non public methods you have added can be declared
>> private,
>
> Good point; I'll make that change before pushing.
>
>> and printNameableList can use a stream and a collector
>>
>>    private void printNameableList(List<? extends QualifiedNameable>
>> nameables) {
>> writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(",
>> "));
>
> I thought of using that style instead and changed some core reflection
> code to use streams and collectors earlier in 9 (JDK-8162817:
> Annotation toString output not reusable for source input).
>
> I'll let Jon or Jan weigh in on which style is preferred for javac.

We recently did a pass over javac code to modernize code, so these days,
I think streams and collectors are fine. The primary criteria are regard
for the bootstrap process, and no large destabilizing changes that might
advesely impact forward/backward parts at the beginning of a release cycle.

We can maybe quibble over the formatting: one line, or one line per
chained method.  :-)

-- Jon

>
> Thanks,
>
> -Joe
>
>>    }
>>
>> cheers,
>> Rémi
>>
>> ----- Mail original -----
>>> De: "joe darcy" <[hidden email]>
>>> À: [hidden email]
>>> Envoyé: Samedi 28 Janvier 2017 22:39:26
>>> Objet: JDK 9 RFR of JDK-8173609: Elements.printElements needs to
>>> support    modules
>>> Hello,
>>>
>>> Please review the straightforward fix to address:
>>>
>>>      JDK-8173609: Elements.printElements needs to support modules
>>>      http://cr.openjdk.java.net/~darcy/8173609.0/
>>>
>>> Once additional information about modules is available (JDK-8172810:
>>> ModuleElement should declare and provide appropriate modifiers), the
>>> printing processor should be updated to expose that information.
>>>
>>> Admittedly this changeset would be better with some regression testing.
>>>
>>> Thanks,
>>>
>>> -Joe
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

joe darcy
Hi Jon,


On 1/30/2017 2:04 PM, Jonathan Gibbons wrote:

>
>
> On 01/29/2017 12:55 PM, joe darcy wrote:
>> Hi Remi,
>>
>>
>> On 1/29/2017 3:21 AM, Remi Forax wrote:
>>> Hi Joe,
>>> i believe that all non public methods you have added can be declared
>>> private,
>>
>> Good point; I'll make that change before pushing.
>>
>>> and printNameableList can use a stream and a collector
>>>
>>>    private void printNameableList(List<? extends QualifiedNameable>
>>> nameables) {
>>> writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(",
>>> "));
>>
>> I thought of using that style instead and changed some core
>> reflection code to use streams and collectors earlier in 9
>> (JDK-8162817: Annotation toString output not reusable for source input).
>>
>> I'll let Jon or Jan weigh in on which style is preferred for javac.
>
> We recently did a pass over javac code to modernize code, so these
> days, I think streams and collectors are fine. The primary criteria
> are regard for the bootstrap process, and no large destabilizing
> changes that might advesely impact forward/backward parts at the
> beginning of a release cycle.
>
> We can maybe quibble over the formatting: one line, or one line per
> chained method.  :-)
>

Replaced with for-loop and state variable over names with

+        private void printNameableList(List<? extends
QualifiedNameable> nameables) {
+                writer.print(nameables.stream().
+ map(QualifiedNameable::getQualifiedName).
+                             collect(Collectors.joining(", ")));
+        }

and verified the output for java.base was the same as before.

-Joe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

Remi Forax
In reply to this post by Jonathan Gibbons
Jon, all,
i've found that Streams are great until you use polymorphic methods in lambdas that are parameters of map(), flatMap(), filter() etc because when you debug, the stacktrace will be quite big, and jump on methods you have no control over.
So i tend to use Stream in my code when the stream call methods i know the implementations and use loops otherwise.

Rémi

----- Mail original -----
> De: "Jonathan Gibbons" <[hidden email]>
> À: [hidden email]
> Envoyé: Lundi 30 Janvier 2017 23:04:57
> Objet: Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

> On 01/29/2017 12:55 PM, joe darcy wrote:
>> Hi Remi,
>>
>>
>> On 1/29/2017 3:21 AM, Remi Forax wrote:
>>> Hi Joe,
>>> i believe that all non public methods you have added can be declared
>>> private,
>>
>> Good point; I'll make that change before pushing.
>>
>>> and printNameableList can use a stream and a collector
>>>
>>>    private void printNameableList(List<? extends QualifiedNameable>
>>> nameables) {
>>> writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(",
>>> "));
>>
>> I thought of using that style instead and changed some core reflection
>> code to use streams and collectors earlier in 9 (JDK-8162817:
>> Annotation toString output not reusable for source input).
>>
>> I'll let Jon or Jan weigh in on which style is preferred for javac.
>
> We recently did a pass over javac code to modernize code, so these days,
> I think streams and collectors are fine. The primary criteria are regard
> for the bootstrap process, and no large destabilizing changes that might
> advesely impact forward/backward parts at the beginning of a release cycle.
>
> We can maybe quibble over the formatting: one line, or one line per
> chained method.  :-)
>
> -- Jon
>
>>
>> Thanks,
>>
>> -Joe
>>
>>>    }
>>>
>>> cheers,
>>> Rémi
>>>
>>> ----- Mail original -----
>>>> De: "joe darcy" <[hidden email]>
>>>> À: [hidden email]
>>>> Envoyé: Samedi 28 Janvier 2017 22:39:26
>>>> Objet: JDK 9 RFR of JDK-8173609: Elements.printElements needs to
>>>> support    modules
>>>> Hello,
>>>>
>>>> Please review the straightforward fix to address:
>>>>
>>>>      JDK-8173609: Elements.printElements needs to support modules
>>>>      http://cr.openjdk.java.net/~darcy/8173609.0/
>>>>
>>>> Once additional information about modules is available (JDK-8172810:
>>>> ModuleElement should declare and provide appropriate modifiers), the
>>>> printing processor should be updated to expose that information.
>>>>
>>>> Admittedly this changeset would be better with some regression testing.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

Jonathan Gibbons
Remi,

That sounds like interesting feedback for the streams() folk. I don't
this we can rely on most folk making informed judgements based on
implementation details :-(

-- Jon


On 01/30/2017 02:26 PM, Remi Forax wrote:

> Jon, all,
> i've found that Streams are great until you use polymorphic methods in lambdas that are parameters of map(), flatMap(), filter() etc because when you debug, the stacktrace will be quite big, and jump on methods you have no control over.
> So i tend to use Stream in my code when the stream call methods i know the implementations and use loops otherwise.
>
> Rémi
>
> ----- Mail original -----
>> De: "Jonathan Gibbons" <[hidden email]>
>> À: [hidden email]
>> Envoyé: Lundi 30 Janvier 2017 23:04:57
>> Objet: Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules
>> On 01/29/2017 12:55 PM, joe darcy wrote:
>>> Hi Remi,
>>>
>>>
>>> On 1/29/2017 3:21 AM, Remi Forax wrote:
>>>> Hi Joe,
>>>> i believe that all non public methods you have added can be declared
>>>> private,
>>> Good point; I'll make that change before pushing.
>>>
>>>> and printNameableList can use a stream and a collector
>>>>
>>>>     private void printNameableList(List<? extends QualifiedNameable>
>>>> nameables) {
>>>> writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(",
>>>> "));
>>> I thought of using that style instead and changed some core reflection
>>> code to use streams and collectors earlier in 9 (JDK-8162817:
>>> Annotation toString output not reusable for source input).
>>>
>>> I'll let Jon or Jan weigh in on which style is preferred for javac.
>> We recently did a pass over javac code to modernize code, so these days,
>> I think streams and collectors are fine. The primary criteria are regard
>> for the bootstrap process, and no large destabilizing changes that might
>> advesely impact forward/backward parts at the beginning of a release cycle.
>>
>> We can maybe quibble over the formatting: one line, or one line per
>> chained method.  :-)
>>
>> -- Jon
>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>>>     }
>>>>
>>>> cheers,
>>>> Rémi
>>>>
>>>> ----- Mail original -----
>>>>> De: "joe darcy" <[hidden email]>
>>>>> À: [hidden email]
>>>>> Envoyé: Samedi 28 Janvier 2017 22:39:26
>>>>> Objet: JDK 9 RFR of JDK-8173609: Elements.printElements needs to
>>>>> support    modules
>>>>> Hello,
>>>>>
>>>>> Please review the straightforward fix to address:
>>>>>
>>>>>       JDK-8173609: Elements.printElements needs to support modules
>>>>>       http://cr.openjdk.java.net/~darcy/8173609.0/
>>>>>
>>>>> Once additional information about modules is available (JDK-8172810:
>>>>> ModuleElement should declare and provide appropriate modifiers), the
>>>>> printing processor should be updated to expose that information.
>>>>>
>>>>> Admittedly this changeset would be better with some regression testing.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Joe

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

joe darcy
In reply to this post by B. Blaser
Hi Bernard,

On 1/30/2017 5:50 AM, B. Blaser wrote:

> Joe,
>
> 2017-01-28 22:39 GMT+01:00 joe darcy <[hidden email]>:
>> Hello,
>>
>> Please review the straightforward fix to address:
>>
>>      JDK-8173609: Elements.printElements needs to support modules
>>      http://cr.openjdk.java.net/~darcy/8173609.0/
>>
>> Once additional information about modules is available (JDK-8172810:
>> ModuleElement should declare and provide appropriate modifiers), the
>> printing processor should be updated to expose that information.
>>
>> Admittedly this changeset would be better with some regression testing.
>>
>> Thanks,
>>
>> -Joe
>>
> Here is a test for that.
> Regards,
> Bernard

Thanks for patch for the test.

We've largely abandoned the bug number based scheme for categorizing
tests; it became cumbersome to find the tests we were looking for as the
set of tests grew.

Since the functionality in question is related to the annotation
processing implementation in javac, I think a location under
test/tools/javac/processing/model/util would be more appropriate.

Also for a source-based test, it would be more complete to also examine
doc comments and annotations. If you make those amendments, I can push
the test as follow-up work (since I've already pushed the code change).

Thanks,

-Joe


>
> diff --git a/test/tools/javac/modules/T8173609/module-info.java
> b/test/tools/javac/modules/T8173609/module-info.java
> new file mode 100644
> --- /dev/null
> +++ b/test/tools/javac/modules/T8173609/module-info.java
> @@ -0,0 +1,13 @@
> +/*
> + * @test
> + * @bug 8173609
> + * @summary printing of modules
> + * @compile/ref=module-info.out -Xprint p/P.java module-info.java
> + */
> +module JDK_8173609 {
> +    requires static transitive java.base;
> +    exports p to m.m1, m.m2;
> +    opens p to m.m1, m.m2;
> +    uses p.P;
> +    provides p.P with p.P.P1, p.P.P2;
> +}
> diff --git a/test/tools/javac/modules/T8173609/module-info.out
> b/test/tools/javac/modules/T8173609/module-info.out
> new file mode 100644
> --- /dev/null
> +++ b/test/tools/javac/modules/T8173609/module-info.out
> @@ -0,0 +1,23 @@
> +package p;
> +
> +public class P {
> +
> +  public static class P1 extends p.P {
> +
> +    public P1();
> +  }
> +
> +  public static class P2 extends p.P {
> +
> +    public P2();
> +  }
> +
> +  public P();
> +}
> +module JDK_8173609 {
> +  requires static transitive java.base;
> +  exports p to m.m1, m.m2;
> +  opens p to m.m1, m.m2;
> +  uses p.P;
> +  provides p.P with p.P.P1, p.P.P2;
> +}
> diff --git a/test/tools/javac/modules/T8173609/p/P.java
> b/test/tools/javac/modules/T8173609/p/P.java
> new file mode 100644
> --- /dev/null
> +++ b/test/tools/javac/modules/T8173609/p/P.java
> @@ -0,0 +1,6 @@
> +package p;
> +
> +public class P {
> +    public static class P1 extends P {}
> +    public static class P2 extends P {}
> +}

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

B. Blaser
Hi Joe,

2017-01-31 0:15 GMT+01:00 Joseph D. Darcy <[hidden email]>:

> Hi Bernard,
>
> Thanks for patch for the test.
>
> We've largely abandoned the bug number based scheme for categorizing tests;
> it became cumbersome to find the tests we were looking for as the set of
> tests grew.
>
> Since the functionality in question is related to the annotation processing
> implementation in javac, I think a location under
> test/tools/javac/processing/model/util would be more appropriate.
>
> Also for a source-based test, it would be more complete to also examine doc
> comments and annotations. If you make those amendments, I can push the test
> as follow-up work (since I've already pushed the code change).
>
> Thanks,
>
> -Joe

Thanks for your comments.
Please, find next the updated test.

Bernard

diff --git a/test/tools/javac/processing/model/util/printing/module-info.java
b/test/tools/javac/processing/model/util/printing/module-info.java
new file mode 100644
--- /dev/null
+++ b/test/tools/javac/processing/model/util/printing/module-info.java
@@ -0,0 +1,18 @@
+/*
+ * @test
+ * @bug 8173609
+ * @summary printing of modules
+ * @compile/ref=module-info.out -Xprint p/P.java module-info.java
+ */
+
+/**
+ * Printing of modules
+ */
+@Deprecated
+module printing {
+    requires static transitive java.base;
+    exports p to m.m1, m.m2;
+    opens p to m.m1, m.m2;
+    uses p.P;
+    provides p.P with p.P.P1, p.P.P2;
+}
diff --git a/test/tools/javac/processing/model/util/printing/module-info.out
b/test/tools/javac/processing/model/util/printing/module-info.out
new file mode 100644
--- /dev/null
+++ b/test/tools/javac/processing/model/util/printing/module-info.out
@@ -0,0 +1,27 @@
+package p;
+
+public class P {
+
+  public static class P1 extends p.P {
+
+    public P1();
+  }
+
+  public static class P2 extends p.P {
+
+    public P2();
+  }
+
+  public P();
+}
+/**
+ * Printing of modules
+ */
+@java.lang.Deprecated
+module printing {
+  requires static transitive java.base;
+  exports p to m.m1, m.m2;
+  opens p to m.m1, m.m2;
+  uses p.P;
+  provides p.P with p.P.P1, p.P.P2;
+}
diff --git a/test/tools/javac/processing/model/util/printing/p/P.java
b/test/tools/javac/processing/model/util/printing/p/P.java
new file mode 100644
--- /dev/null
+++ b/test/tools/javac/processing/model/util/printing/p/P.java
@@ -0,0 +1,6 @@
+package p;
+
+public class P {
+    public static class P1 extends P {}
+    public static class P2 extends P {}
+}
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules

joe darcy
Hi Bernard,

Just pushed your test under 8173798: Tests for printing modules.

Thanks again for the test,

-Joe


On 1/31/2017 4:59 AM, B. Blaser wrote:

> Hi Joe,
>
> 2017-01-31 0:15 GMT+01:00 Joseph D. Darcy <[hidden email]>:
>> Hi Bernard,
>>
>> Thanks for patch for the test.
>>
>> We've largely abandoned the bug number based scheme for categorizing tests;
>> it became cumbersome to find the tests we were looking for as the set of
>> tests grew.
>>
>> Since the functionality in question is related to the annotation processing
>> implementation in javac, I think a location under
>> test/tools/javac/processing/model/util would be more appropriate.
>>
>> Also for a source-based test, it would be more complete to also examine doc
>> comments and annotations. If you make those amendments, I can push the test
>> as follow-up work (since I've already pushed the code change).
>>
>> Thanks,
>>
>> -Joe
> Thanks for your comments.
> Please, find next the updated test.
>
> Bernard
>
>

Loading...