[
https://issues.apache.org/jira/browse/GROOVY-10148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-10148:
-------------------------------
Description:
For Java 15/16 under preview and targeted for 17+, sealed classes and
interfaces can be created. Creating Groovy classes which extend such sealed
Java classes or implement sealed interfaces, results in classes which will give
a runtime error when loaded:
{noformat}
java.lang.RuntimeException: java.lang.IncompatibleClassChangeError:
class MyGroovyChildClass cannot inherit from sealed class MyJavaSealedClass
{noformat}
When creating sealed classes, Java currently requires all mentioned permitted
children to be compiled in the source set. However, it does allow subsequent
compilation steps to include just one of the children (and have the parent
pre-compiled). This in theory allows scenarios where one could have mixed
Java/Groovy hierarchies by using stubs initially.
So, Groovy could eventually support compilation where the name of the Groovy
class being compiled matched one of the declared permitted subclasses (though
there may be some module implications too). I propose that we just disallow all
cases in the first instance. We should create a GEP which outlines what we want
to do with respect to Groovy support for sealed hierarchies and discuss further
there how we might relax the restriction if it turns out to be feasible.
was:
For Java 15/16 under preview and targeted for 17+, sealed classes and
interfaces can be created. Creating Groovy classes which extend such sealed
Java classes or implement sealed interfaces, results in classes which will give
a runtime error when loaded:
{noformat}
java.lang.RuntimeException: java.lang.IncompatibleClassChangeError: class
MyGroovyChildClass cannot inherit from sealed class MyJavaSealedClass
{noformat}
When creating sealed classes, Java currently requires all mentioned permitted
children to be compiled in the source set. However, it does allow subsequent
compilation steps to include just one of the children (and have the parent
pre-compiled). This in theory allows scenarios where one could have mixed
Java/Groovy hierarchies by using stubs initially.
So, Groovy should eventually support compilation where the name of the Groovy
class being compiled matched one of the declared permitted subclasses (though
there may be some module implications too). I propose that we just disallow all
cases in the first instance. We should create a GEP which outlines what we want
to do with respect to Groovy support for sealed hierarchies and discuss further
there how we might relax the restriction if it turns out to be feasible.
> Groovy should not allow classes to extend sealed Java classes
> -------------------------------------------------------------
>
> Key: GROOVY-10148
> URL: https://issues.apache.org/jira/browse/GROOVY-10148
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
> Reporter: Paul King
> Priority: Major
>
> For Java 15/16 under preview and targeted for 17+, sealed classes and
> interfaces can be created. Creating Groovy classes which extend such sealed
> Java classes or implement sealed interfaces, results in classes which will
> give a runtime error when loaded:
> {noformat}
> java.lang.RuntimeException: java.lang.IncompatibleClassChangeError:
> class MyGroovyChildClass cannot inherit from sealed class MyJavaSealedClass
> {noformat}
> When creating sealed classes, Java currently requires all mentioned permitted
> children to be compiled in the source set. However, it does allow subsequent
> compilation steps to include just one of the children (and have the parent
> pre-compiled). This in theory allows scenarios where one could have mixed
> Java/Groovy hierarchies by using stubs initially.
> So, Groovy could eventually support compilation where the name of the Groovy
> class being compiled matched one of the declared permitted subclasses (though
> there may be some module implications too). I propose that we just disallow
> all cases in the first instance. We should create a GEP which outlines what
> we want to do with respect to Groovy support for sealed hierarchies and
> discuss further there how we might relax the restriction if it turns out to
> be feasible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
