ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <g.grigelio...@gmail.com>
Subject Re: ant git commit: Generate manifest files and add automatic module names for JPMS
Date Tue, 06 Feb 2018 17:50:47 GMT
2018-02-06 11:05 GMT+01:00 Stefan Bodewig <bodewig@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message