Am 04.04.2018 um 12:55 schrieb Guillaume Laforge:
See Paul's description in the JIRA issue for the motivation:
"My use case is around JDK9+ modules. We might move the package for,
e.g. groovy.util.XmlSlurper to something like
groovy.xml.parsers.XmlSlurper (or whatever) but we might like to retain
(perhaps with a commandline switch) the ability to compile source code
still using the old package name."
ah, seems I overscrolled that.
At first, I had the same reaction, as I didn't want to have to type new
foo.bar.Baz() instead of new AliasedBaz(), but perhaps it's useful
somehow for our split packages trouble.
for me, what is required is something like this:
import x.Y as a.B
import a.B
new B()
then it makes sense. But I don't think that would work, just because the
grammar is changed. This will imho require more changes
But I wonder if it is worth it. changing some imports is much more
easily done than if for example the meta class system changes in an
incompatible way... and I see no way around that currently. We will most
likely even have to deprecate the remove points for method invocation we
have since Groovy 1 (ScriptByteCodeAdapter invoke*, get*, set*), and the
old method caching. The only part, that has a chance of survival is the
indy version.
bye Jochen
