RFR: 8220687: Change signature of StandardJavaFileManager.getJavaFileObjectsFromPaths

[Jonathan Gibbons]

Liam,

ClientCodeWrapper and DelegatingJavaFileManager should both add 
overrides for the new method, instead of repurposing the old existing 
override.  The code should not rely on implementations choosing to use 
the now-default implementations defined in the interface.

-- Jon


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/9a90ab59/attachment.html>