You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Daniel Sun (JIRA)" <ji...@apache.org> on 2018/04/04 03:03:00 UTC
[jira] [Assigned] (GROOVY-8527) Enhance import aliasing to an alias
with a package name
[ https://issues.apache.org/jira/browse/GROOVY-8527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Sun reassigned GROOVY-8527:
----------------------------------
Assignee: Daniel Sun
> Enhance import aliasing to an alias with a package name
> -------------------------------------------------------
>
> Key: GROOVY-8527
> URL: https://issues.apache.org/jira/browse/GROOVY-8527
> Project: Groovy
> Issue Type: New Feature
> Reporter: Paul King
> Assignee: Daniel Sun
> Priority: Major
>
> Currently at the syntax level you can do:
> {code:java}
> import java.lang.String as MyString
> {code}
> but the grammar prohibits:
> {code:java}
> import java.lang.String as some.package.MyString
> {code}
> It is already possible to include a dot within the name via the api:
> {code}
> import org.codehaus.groovy.control.CompilerConfiguration
> import org.codehaus.groovy.control.customizers.ImportCustomizer
> def configuration = new CompilerConfiguration()
> def imports = new ImportCustomizer()
> imports.addImport('foo.bar.LegacyDate', 'java.util.Date')
> configuration.addCompilationCustomizers(imports)
> def shell = new GroovyShell(configuration)
> shell.evaluate('println new foo.bar.LegacyDate()')
> {code}
> This usage is not currently common however and perhaps parts of the code base don't expect it. We should include some further tests and also make sure there aren't any security implications if someone started using a java.lang.Object alias or something similar.
> We should also consider adding a DEFAULT_ALIASES similar to {{ResolveVisitor#DEFAULT_IMPORTS}} and consider a mechanism for extending the list (potentially for both).
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)