RFR: 8220687: Change signature of StandardJavaFileManager.getJavaFileObjectsFromPaths

[Jonathan Gibbons]

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/4958d16b/attachment.html>