RFR: 8220687: Change signature of StandardJavaFileManager.getJavaFileObjectsFromPaths

[Jonathan Gibbons]

+1

-- Jon


On 03/26/2019 01:46 PM, Liam Miller-Cushon wrote:
> Jon,
>
> Thanks, I updated ClientCodeWrapper and DelegatingJavaFileManager, and 
> verified the tier1 langtools tests are passing.
>
> I also adapted one of the existing tests to exercise to deprecated 
> Iterable overload.
>
> Here's the updated webrev:
> http://cr.openjdk.java.net/~cushon/8220687/webrev.03/ 
> <http://cr.openjdk.java.net/%7Ecushon/8220687/webrev.03/>
>
> On Tue, Mar 26, 2019 at 12:06 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Liam,
>
>     Make sure the proposed new code passes all the standard langtools
>     tests, including (in particular) TestClientCodeWrapper.java.
>
>     As a general process point, a changeset should always either have
>     a test, or the JBS issue should have a "noreg-*" label, where the
>     label is chosen from the list here [1].  In other words, write a
>     test, or justify why one is not required.  Internally, we have
>     infrastructure that checks this condition.  If you create a new
>     test, or edit an existing one, make sure the jtreg
>     test-description lists the JBS issue number in the `@bug` line.
>
>     -- Jon
>
>     [1] https://openjdk.java.net/guide/changePlanning.html#bug (See
>     section 6.)
>
>
>     On 03/14/2019 06:19 PM, Liam Miller-Cushon wrote:
>>     Hi,
>>
>>     This change adds a getJavaFileObjectsFromPaths(Collection<Path>)
>>     method, and deprecates the existing
>>     getJavaFileObjectsFromPaths(Iterable<Path>). The motivation is
>>     the same as JDK-8150111, which made a similar change to
>>     setLocationFromPaths: methods that take Iterable<Path> are
>>     error-prone since Path itself implements Iterable<Path>.
>>
>>     I have two initial questions: do you think this is worthwhile,
>>     and if so what's the correct process (should I file a CSR?).
>>
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8220687
>>     webrev: http://cr.openjdk.java.net/~cushon/8220687/webrev.00/
>>     <http://cr.openjdk.java.net/%7Ecushon/8220687/webrev.00/>
>>
>>     Thanks,
>>     Liam
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190326/8f13a90c/attachment.html>