2018-02-06 11:05 GMT+01:00 Stefan Bodewig <bode...@apache.org>: > On 2018-02-05, Gintautas Grigelionis wrote: > > > I adjusted the proposal and I hope that I addressed your criticism. > > Unfortunately it doesn't. > > I'm afraid that we would be sending a wrong signal here. On top of that > I don't think Ant would actually work if parts of it are used as > modules. We use classloaders and Class.forName all over the place, not > ServiceLoader, for example. > > If the taskdef/typedef implementation classes are loaded via a module > path and a custom task lives on the CLASSPATH will taskdef be able to > load it at all? >
Anything on the CLASSPATH is in the unnamed module. The worst that can happen is the situation where a package split between module path and classpath. That's what --patch-module is for. > As for moving classes and adding stubs for backwards compatibility - > let's please evaluate what we'd gain with such a move. > > Ant is used as a code dependency by way more things than we know. We do > know Gradle and SBT directly call into Ant classes under the > covers. Lots and lots of custom tasks have been written that rely on our > API. If you use some kind of Maven antrun construct then moving classes > around and adding a new jar means you have to add a new dependency when > you want to upgrade to a new version. This is inconvenient and may turn > out to cause difficult to diagnose problems. > Modules is the way to take back control. There are switches in Java 9 to enable access. We should rather be doing now when JRE is still lenient. Who knows what to expect from Java 11 LTS (6 months from now)? Gintas
