Hi Uwe, I am happy to hear that you think this plan reasonable.
On May 18, 2015, at 12:43 PM, Uwe Schindler <[email protected]> wrote: > the plan looks fine from my perspective! Many thanks! > > I have a few comments on the items: > 1. We were using FileChannel.open(Path,…) to open directories, we never > used Files.newByteChannel(Path,…): see https://goo.gl/4wDo41; but I assume > they both delegate to the same method and both return a FileChannel instance. > So maybe we can just prevent directories from be opened with > Files.newByteChannel(). But FileChannel.open() could be documented to also > work on Directories. This is just an idea. Thanks for pointing that out. > 2. Thanks! > 3. That’s the best of the whole approach. #1 ensures that our current > code still works, I hope to get #1 accomplished fairly quickly so at least you can be “back in business” soon. > and this one would be the solution once we “detect” Java 9. We can reflect on > new OpenOptions or new methods and include that code asap, once a first impl > is available. It will take a long time until our code will require Java 9, > but we can support those APIs before (using > reflection/MethodHandles/StandardOpenOption.valueOf(“StringValueOfNewOption”)) I am sure we will have further discussions once we get to #3. Ideally it would be something which would require no change at all on your end but would be logically consistent with the APIs. Thanks, Brian
