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."
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. Guillaume On Wed, Apr 4, 2018 at 12:46 PM, Jochen Theodorou <[email protected]> wrote: > > > Am 04.04.2018 um 06:58 schrieb Daniel Sun: > >> Hi all, >> >> >> Paul proposed to enhance import aliasing to an alias with a >> package >> name(see GROOVY-8527[2]), which I think is useful sometimes, so I have >> implemented in groovy-parser project[1]. >> >> If no one rejects it, I will sync it to apache/groovy project. >> >> Cheers, >> Daniel.Sun >> >> [1] https://github.com/danielsun1106/groovy-parser/tree/refine-import-as >> [2] https://issues.apache.org/jira/browse/GROOVY-8527 >> > > I am unclear about the use case for this. I mean if you > > import java.lang.String as some.package.MyString > > you will have to do "new some.package.MyString()". If you are fully > qualifying the name, why not use the original name instead. > > bye Jochen > -- Guillaume Laforge Apache Groovy committer & PMC Vice-President Developer Advocate @ Google Cloud Platform Blog: http://glaforge.appspot.com/ Social: @glaforge <http://twitter.com/glaforge> / Google+ <https://plus.google.com/u/0/114130972232398734985/posts>
