> The reason it's useful to look at this now is to ensure we don't evolve > EFS in a way that is fundamentally at odds with java.nio.file, that > would prevent us adopting it when the time comes. Yes, that's exactly it. Interestingly, the basic concepts in JSR 203 and EFS have evolved very similarly, with EFS shooting at the "least common denominator" and JSR 203 shooting for extremely broad applicability. When I noticed that JSR203 had adopted URI as a constructor parameter for java.nio.file.Path I couldn't help smiling. That seems just the perfect API boundary in case somebody wants to fiddle with stuff like ACL's in JSR203 based on Eclipse that uses EFS for most of its work identifying files. I'm sure that EFS and JSR203 will work together very nicely. Thanks for the great work! [and thanks for pushing back on some requested API changes as well, I'm understanding better and better why these have no place in a core API]. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
