[jira] [Updated] (GROOVY-11341) @CompileStatic: Compilation fails due to a synthetic bridge method in the subclass
[
https://issues.apache.org/jira/browse/GROOVY-11341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Schmitz updated GROOVY-11341:
---
Description:
Given the following Java classes:
{code:java}
public interface InterfaceBase {
Object getValue();
}
public class MyImplBase {
public Long getValue() {
return 42L;
}
}
public class MyImpl extends MyImplBase implements InterfaceBase {
} {code}
And the following SimpleCaller.groovy:
{code:java}
@groovy.transform.CompileStatic
class SimpleCaller {
public static void main(String[] args) {
Long v = new MyImpl().getValue();
System.out.println(v); //42
}
} {code}
The compilation fails with:
{{SimpleCaller.groovy: 7: [Static type checking] - Cannot assign value of type
java.lang.Object to variable of type java.lang.Long}}
{{ @ line 7, column 16.}}
{{ Long v = new MyImpl().getValue();}}
{{ ^}}
Compiling the equivalent {{SimpleCaller.java}} with _javac_ completes
successfully.
This structure is a bit uncommon, because MyImplBase uses a covariant return
type and doesn't implement the interface directly, only its subclass does.
I believe the problem is connected to the synthetic bridge method inserted into
the bytecode of {_}MyImpl{_}, which is picked up and preferred by _groovyc_
over the non-synthetic method in {_}MyImplBase{_}.
In case this is related: The synthetic bridge method is selected when using
reflection as well, causing the inferred type by javac and reflection to
diverge:
{code:java}
Method getValueMethod = MyImpl.class.getMethod("getValue");
// public java.lang.Object MyImpl.getValue() {code}
Workarounds: * Disable static compilation
* An explicit cast to Long in SimpleCaller.
* Explicitly repeat the method signature by repeating the method signature
* If possible, add/Move the implements to MyImplBase - then the synthetic
method is in the same class as the real one, which _groovyc_ is able to detect.
Using generics in the Interface doesn't work either (probably due to type
erasure).
Seems to be a more generalized issue when compared to the similar GROOVY-5003
was:
Given the following Java classes:
{code:java}
public interface InterfaceBase {
Object getValue();
}
public class MyImplBase {
public Long getValue() {
return 42L;
}
}
public class MyImpl extends MyImplBase implements InterfaceBase {
} {code}
And the following SimpleCaller.groovy:
{code:java}
@groovy.transform.CompileStatic
class SimpleCaller {
public static void main(String[] args) {
Long v = new MyImpl().getValue();
System.out.println(v); //42
}
} {code}
The compilation fails with:
{{SimpleCaller.groovy: 7: [Static type checking] - Cannot assign value of type
java.lang.Object to variable of type java.lang.Long}}
{{ @ line 7, column 16.}}
{{ Long v = new MyImpl().getValue();}}
{{ ^}}
Compiling the equivalent {{SimpleCaller.java}} with _javac_ completes
successfully.
This structure is a bit uncommon, because MyImplBase uses a covariant return
type and doesn't implement the interface directly, only its subclass does.
I believe the problem is connected to the synthetic bridge method inserted into
the bytecode of {_}MyImpl{_}, which is picked up and preferred by _groovyc_
over the non-synthetic method in {_}MyImplBase{_}.
In case this is related: The synthetic bridge method is selected when using
reflection as well, causing the inferred type by javac and reflection to
diverge:
{code:java}
Method getNumber = MyImpl.class.getMethod("getValue");
// public java.lang.Object MyImpl.getValue() {code}
Workarounds: * Disable static compilation
* An explicit cast to Long in SimpleCaller.
* Explicitly repeat the method signature by repeating the method signature
* If possible, add/Move the implements to MyImplBase - then the synthetic
method is in the same class as the real one, which _groovyc_ is able to detect.
Using generics in the Interface doesn't work either (probably due to type
erasure).
Seems to be a more generalized issue when compared to the similar
[GROOVY-5003|https://issues.apache.org/jira/browse/GROOVY-5003]
> @CompileStatic: Compilation fails due to a synthetic bridge method in the
> subclass
> --
>
> Key: GROOVY-11341
> URL: https://issues.apache.org/jira/browse/GROOVY-11341
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.x, 2.5.x, 3.0.21, 5.0.0-alpha-7, 4.0.20
>Reporter: Peter Schmitz
>Priority: Minor
> Labels: CompileStatic, groovyc
>
> Given the following Java classes:
> {code:java}
> public interface InterfaceBase {
> Object getValue();
> }
>
> public class My
[jira] [Updated] (GROOVY-11341) @CompileStatic: Compilation fails due to a synthetic bridge method in the subclass
[
https://issues.apache.org/jira/browse/GROOVY-11341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Schmitz updated GROOVY-11341:
---
Description:
Given the following Java classes:
{code:java}
public interface InterfaceBase {
Object getValue();
}
public class MyImplBase {
public Long getValue() {
return 42L;
}
}
public class MyImpl extends MyImplBase implements InterfaceBase {
} {code}
And the following SimpleCaller.groovy:
{code:java}
@groovy.transform.CompileStatic
class SimpleCaller {
public static void main(String[] args) {
Long v = new MyImpl().getValue();
System.out.println(v); //42
}
} {code}
The compilation fails with:
{{SimpleCaller.groovy: 7: [Static type checking] - Cannot assign value of type
java.lang.Object to variable of type java.lang.Long}}
{{ @ line 7, column 16.}}
{{ Long v = new MyImpl().getValue();}}
{{ ^}}
Compiling the equivalent {{SimpleCaller.java}} with _javac_ completes
successfully.
This structure is a bit uncommon, because MyImplBase uses a covariant return
type and doesn't implement the interface directly, only its subclass does.
I believe the problem is connected to the synthetic bridge method inserted into
the bytecode of {_}MyImpl{_}, which is picked up and preferred by _groovyc_
over the non-synthetic method in {_}MyImplBase{_}.
In case this is related: The synthetic bridge method is selected when using
reflection as well, causing the inferred type by javac and reflection to
diverge:
{code:java}
Method getValueMethod = MyImpl.class.getMethod("getValue");
// public java.lang.Object MyImpl.getValue() {code}
Workarounds:
* Disable static compilation
* An explicit cast to Long in SimpleCaller.
* Explicitly repeat the method signature by repeating the method signature
* If possible, add/Move the implements to MyImplBase - then the synthetic
method is in the same class as the real one, which _groovyc_ is able to detect.
Using generics in the Interface doesn't work either (probably due to type
erasure).
Seems to be a more generalized issue when compared to the similar GROOVY-5003
was:
Given the following Java classes:
{code:java}
public interface InterfaceBase {
Object getValue();
}
public class MyImplBase {
public Long getValue() {
return 42L;
}
}
public class MyImpl extends MyImplBase implements InterfaceBase {
} {code}
And the following SimpleCaller.groovy:
{code:java}
@groovy.transform.CompileStatic
class SimpleCaller {
public static void main(String[] args) {
Long v = new MyImpl().getValue();
System.out.println(v); //42
}
} {code}
The compilation fails with:
{{SimpleCaller.groovy: 7: [Static type checking] - Cannot assign value of type
java.lang.Object to variable of type java.lang.Long}}
{{ @ line 7, column 16.}}
{{ Long v = new MyImpl().getValue();}}
{{ ^}}
Compiling the equivalent {{SimpleCaller.java}} with _javac_ completes
successfully.
This structure is a bit uncommon, because MyImplBase uses a covariant return
type and doesn't implement the interface directly, only its subclass does.
I believe the problem is connected to the synthetic bridge method inserted into
the bytecode of {_}MyImpl{_}, which is picked up and preferred by _groovyc_
over the non-synthetic method in {_}MyImplBase{_}.
In case this is related: The synthetic bridge method is selected when using
reflection as well, causing the inferred type by javac and reflection to
diverge:
{code:java}
Method getValueMethod = MyImpl.class.getMethod("getValue");
// public java.lang.Object MyImpl.getValue() {code}
Workarounds: * Disable static compilation
* An explicit cast to Long in SimpleCaller.
* Explicitly repeat the method signature by repeating the method signature
* If possible, add/Move the implements to MyImplBase - then the synthetic
method is in the same class as the real one, which _groovyc_ is able to detect.
Using generics in the Interface doesn't work either (probably due to type
erasure).
Seems to be a more generalized issue when compared to the similar GROOVY-5003
> @CompileStatic: Compilation fails due to a synthetic bridge method in the
> subclass
> --
>
> Key: GROOVY-11341
> URL: https://issues.apache.org/jira/browse/GROOVY-11341
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.x, 2.5.x, 3.0.21, 5.0.0-alpha-7, 4.0.20
>Reporter: Peter Schmitz
>Priority: Minor
> Labels: CompileStatic, groovyc
>
> Given the following Java classes:
> {code:java}
> public interface InterfaceBase {
> Object getValue();
> }
>
> public class MyImplBase {
> public Long getValue() {
>
[jira] [Updated] (GROOVY-11341) @CompileStatic: Compilation fails due to the synthetic bridge method in a subclass
[
https://issues.apache.org/jira/browse/GROOVY-11341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Schmitz updated GROOVY-11341:
---
Summary: @CompileStatic: Compilation fails due to the synthetic bridge
method in a subclass (was: @CompileStatic: Compilation fails due to synthetic
bridge methods (probably) )
> @CompileStatic: Compilation fails due to the synthetic bridge method in a
> subclass
> --
>
> Key: GROOVY-11341
> URL: https://issues.apache.org/jira/browse/GROOVY-11341
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.x, 2.5.x, 3.0.21, 5.0.0-alpha-7, 4.0.20
>Reporter: Peter Schmitz
>Priority: Minor
> Labels: CompileStatic, groovyc
>
> Given the following Java classes:
> {code:java}
> public interface InterfaceBase {
> Object getValue();
> }
>
> public class MyImplBase {
> public Long getValue() {
> return 42L;
> }
> }
>
> public class MyImpl extends MyImplBase implements InterfaceBase {
> } {code}
>
> And the following SimpleCaller.groovy:
> {code:java}
> @groovy.transform.CompileStatic
> class SimpleCaller {
>public static void main(String[] args) {
> Long v = new MyImpl().getValue();
> System.out.println(v); //42
>}
> } {code}
> The compilation fails with:
>
> {{SimpleCaller.groovy: 7: [Static type checking] - Cannot assign value of
> type java.lang.Object to variable of type java.lang.Long}}
> {{ @ line 7, column 16.}}
> {{ Long v = new MyImpl().getValue();}}
> {{ ^}}
>
> Compiling the equivalent {{SimpleCaller.java}} with _javac_ completes
> successfully.
>
> This structure is a bit uncommon, because MyImplBase uses a covariant return
> type and doesn't implement the interface directly, only its subclass does.
>
> I believe the problem is connected to the synthetic bridge method inserted
> into the bytecode of {_}MyImpl{_}, which is picked up and preferred by
> _groovyc_ over the non-synthetic method in {_}MyImplBase{_}.
>
>
> In case this is related: The synthetic bridge method is selected when using
> reflection as well, causing the inferred type by javac and reflection to
> diverge:
> {code:java}
> Method getNumber = MyImpl.class.getMethod("getValue");
> // public java.lang.Object MyImpl.getValue() {code}
>
>
> Workarounds: * Disable static compilation
> * An explicit cast to Long in SimpleCaller.
> * Explicitly repeat the method signature by repeating the method signature
> * If possible, add/Move the implements to MyImplBase - then the synthetic
> method is in the same class as the real one, which _groovyc_ is able to
> detect.
> Using generics in the Interface doesn't work either (probably due to type
> erasure).
>
> Seems to be a more generalized issue when compared to the similar
> [GROOVY-5003|https://issues.apache.org/jira/browse/GROOVY-5003]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11341) @CompileStatic: Compilation fails due to a synthetic bridge method in the subclass
[
https://issues.apache.org/jira/browse/GROOVY-11341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Schmitz updated GROOVY-11341:
---
Summary: @CompileStatic: Compilation fails due to a synthetic bridge method
in the subclass (was: @CompileStatic: Compilation fails due to the synthetic
bridge method in a subclass)
> @CompileStatic: Compilation fails due to a synthetic bridge method in the
> subclass
> --
>
> Key: GROOVY-11341
> URL: https://issues.apache.org/jira/browse/GROOVY-11341
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.x, 2.5.x, 3.0.21, 5.0.0-alpha-7, 4.0.20
>Reporter: Peter Schmitz
>Priority: Minor
> Labels: CompileStatic, groovyc
>
> Given the following Java classes:
> {code:java}
> public interface InterfaceBase {
> Object getValue();
> }
>
> public class MyImplBase {
> public Long getValue() {
> return 42L;
> }
> }
>
> public class MyImpl extends MyImplBase implements InterfaceBase {
> } {code}
>
> And the following SimpleCaller.groovy:
> {code:java}
> @groovy.transform.CompileStatic
> class SimpleCaller {
>public static void main(String[] args) {
> Long v = new MyImpl().getValue();
> System.out.println(v); //42
>}
> } {code}
> The compilation fails with:
>
> {{SimpleCaller.groovy: 7: [Static type checking] - Cannot assign value of
> type java.lang.Object to variable of type java.lang.Long}}
> {{ @ line 7, column 16.}}
> {{ Long v = new MyImpl().getValue();}}
> {{ ^}}
>
> Compiling the equivalent {{SimpleCaller.java}} with _javac_ completes
> successfully.
>
> This structure is a bit uncommon, because MyImplBase uses a covariant return
> type and doesn't implement the interface directly, only its subclass does.
>
> I believe the problem is connected to the synthetic bridge method inserted
> into the bytecode of {_}MyImpl{_}, which is picked up and preferred by
> _groovyc_ over the non-synthetic method in {_}MyImplBase{_}.
>
>
> In case this is related: The synthetic bridge method is selected when using
> reflection as well, causing the inferred type by javac and reflection to
> diverge:
> {code:java}
> Method getNumber = MyImpl.class.getMethod("getValue");
> // public java.lang.Object MyImpl.getValue() {code}
>
>
> Workarounds: * Disable static compilation
> * An explicit cast to Long in SimpleCaller.
> * Explicitly repeat the method signature by repeating the method signature
> * If possible, add/Move the implements to MyImplBase - then the synthetic
> method is in the same class as the real one, which _groovyc_ is able to
> detect.
> Using generics in the Interface doesn't work either (probably due to type
> erasure).
>
> Seems to be a more generalized issue when compared to the similar
> [GROOVY-5003|https://issues.apache.org/jira/browse/GROOVY-5003]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11341) @CompileStatic: Compilation fails due to synthetic bridge methods (probably)
Peter Schmitz created GROOVY-11341:
--
Summary: @CompileStatic: Compilation fails due to synthetic bridge
methods (probably)
Key: GROOVY-11341
URL: https://issues.apache.org/jira/browse/GROOVY-11341
Project: Groovy
Issue Type: Bug
Components: Static compilation, Static Type Checker
Affects Versions: 4.0.20, 5.0.0-alpha-7, 3.0.21, 2.4.x, 2.5.x
Reporter: Peter Schmitz
Given the following Java classes:
{code:java}
public interface InterfaceBase {
Object getValue();
}
public class MyImplBase {
public Long getValue() {
return 42L;
}
}
public class MyImpl extends MyImplBase implements InterfaceBase {
} {code}
And the following SimpleCaller.groovy:
{code:java}
@groovy.transform.CompileStatic
class SimpleCaller {
public static void main(String[] args) {
Long v = new MyImpl().getValue();
System.out.println(v); //42
}
} {code}
The compilation fails with:
{{SimpleCaller.groovy: 7: [Static type checking] - Cannot assign value of type
java.lang.Object to variable of type java.lang.Long}}
{{ @ line 7, column 16.}}
{{ Long v = new MyImpl().getValue();}}
{{ ^}}
Compiling the equivalent {{SimpleCaller.java}} with _javac_ completes
successfully.
This structure is a bit uncommon, because MyImplBase uses a covariant return
type and doesn't implement the interface directly, only its subclass does.
I believe the problem is connected to the synthetic bridge method inserted into
the bytecode of {_}MyImpl{_}, which is picked up and preferred by _groovyc_
over the non-synthetic method in {_}MyImplBase{_}.
In case this is related: The synthetic bridge method is selected when using
reflection as well, causing the inferred type by javac and reflection to
diverge:
{code:java}
Method getNumber = MyImpl.class.getMethod("getValue");
// public java.lang.Object MyImpl.getValue() {code}
Workarounds: * Disable static compilation
* An explicit cast to Long in SimpleCaller.
* Explicitly repeat the method signature by repeating the method signature
* If possible, add/Move the implements to MyImplBase - then the synthetic
method is in the same class as the real one, which _groovyc_ is able to detect.
Using generics in the Interface doesn't work either (probably due to type
erasure).
Seems to be a more generalized issue when compared to the similar
[GROOVY-5003|https://issues.apache.org/jira/browse/GROOVY-5003]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11341) @CompileStatic: Compilation fails due to a synthetic bridge method in the subclass
[
https://issues.apache.org/jira/browse/GROOVY-11341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Schmitz updated GROOVY-11341:
---
Description:
Given the following Java classes:
{code:java}
public interface InterfaceBase {
Object getValue();
}
public class MyImplBase {
public Long getValue() {
return 42L;
}
}
public class MyImpl extends MyImplBase implements InterfaceBase {
} {code}
And the following SimpleCaller.groovy:
{code:java}
@groovy.transform.CompileStatic
class SimpleCaller {
public static void main(String[] args) {
Long v = new MyImpl().getValue();
System.out.println(v); //42
}
} {code}
The compilation fails with:
{{SimpleCaller.groovy: 7: [Static type checking] - Cannot assign value of type
java.lang.Object to variable of type java.lang.Long}}
{{ @ line 7, column 16.}}
{{ Long v = new MyImpl().getValue();}}
{{ ^}}
Compiling the equivalent {{SimpleCaller.java}} with _javac_ completes
successfully.
This structure is a bit uncommon, because MyImplBase uses a covariant return
type and doesn't implement the interface directly, only its subclass does.
I believe the problem is connected to the synthetic bridge method inserted into
the bytecode of {_}MyImpl{_}, which is picked up and preferred by _groovyc_
over the non-synthetic method in {_}MyImplBase{_}.
In case this is related: The synthetic bridge method is selected when using
reflection as well, causing the inferred type by javac and reflection to
diverge:
{code:java}
Method getValueMethod = MyImpl.class.getMethod("getValue");
// public java.lang.Object MyImpl.getValue() {code}
Workarounds:
* Disable static compilation
* An explicit cast to Long in SimpleCaller.
* Explicitly repeat the covariant method signature in MyImpl
* If possible, add/Move the implements to MyImplBase - then the synthetic
method is in the same class as the real one, which _groovyc_ is able to detect.
Using generics in the Interface doesn't work either (probably due to type
erasure).
Seems to be a more generalized issue when compared to the similar GROOVY-5003
was:
Given the following Java classes:
{code:java}
public interface InterfaceBase {
Object getValue();
}
public class MyImplBase {
public Long getValue() {
return 42L;
}
}
public class MyImpl extends MyImplBase implements InterfaceBase {
} {code}
And the following SimpleCaller.groovy:
{code:java}
@groovy.transform.CompileStatic
class SimpleCaller {
public static void main(String[] args) {
Long v = new MyImpl().getValue();
System.out.println(v); //42
}
} {code}
The compilation fails with:
{{SimpleCaller.groovy: 7: [Static type checking] - Cannot assign value of type
java.lang.Object to variable of type java.lang.Long}}
{{ @ line 7, column 16.}}
{{ Long v = new MyImpl().getValue();}}
{{ ^}}
Compiling the equivalent {{SimpleCaller.java}} with _javac_ completes
successfully.
This structure is a bit uncommon, because MyImplBase uses a covariant return
type and doesn't implement the interface directly, only its subclass does.
I believe the problem is connected to the synthetic bridge method inserted into
the bytecode of {_}MyImpl{_}, which is picked up and preferred by _groovyc_
over the non-synthetic method in {_}MyImplBase{_}.
In case this is related: The synthetic bridge method is selected when using
reflection as well, causing the inferred type by javac and reflection to
diverge:
{code:java}
Method getValueMethod = MyImpl.class.getMethod("getValue");
// public java.lang.Object MyImpl.getValue() {code}
Workarounds:
* Disable static compilation
* An explicit cast to Long in SimpleCaller.
* Explicitly repeat the method signature by repeating the method signature
* If possible, add/Move the implements to MyImplBase - then the synthetic
method is in the same class as the real one, which _groovyc_ is able to detect.
Using generics in the Interface doesn't work either (probably due to type
erasure).
Seems to be a more generalized issue when compared to the similar GROOVY-5003
> @CompileStatic: Compilation fails due to a synthetic bridge method in the
> subclass
> --
>
> Key: GROOVY-11341
> URL: https://issues.apache.org/jira/browse/GROOVY-11341
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.x, 2.5.x, 3.0.21, 5.0.0-alpha-7, 4.0.20
>Reporter: Peter Schmitz
>Priority: Minor
> Labels: CompileStatic, groovyc
>
> Given the following Java classes:
> {code:java}
> public interface InterfaceBase {
> Object getValue();
> }
>
> public class MyImplBase {
> public Long getValue() {
> r
[jira] [Commented] (GROOVY-8603) @CompileStatic: matching method check limited to 30 super classes
[
https://issues.apache.org/jira/browse/GROOVY-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16831457#comment-16831457
]
Peter Schmitz commented on GROOVY-8603:
---
At the moment we're hitting the limit only in a few rare cases. I'd guess 64
should be enough - or 128 to be on the safe side.
A collegue of mine happened to take a look into it last week or so and we're
currently evaluating a patch. As far as I remember his explanation, the limit
is introduced by some kind of distance function/variable that uses a 32bit int
and bit shifts each time a class is inherited from. The patch we're currently
testing switches from shifting to incrementing after the value has already
shifted several times, e.g. the distance is larger than 10bit.
He is currently unavailable, but should provide the diff in the near future if
no problems have been found by then.
hth
> @CompileStatic: matching method check limited to 30 super classes
> -
>
> Key: GROOVY-8603
> URL: https://issues.apache.org/jira/browse/GROOVY-8603
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.3.11, 2.4.13, 2.5.0-rc-3
>Reporter: Peter Schmitz
>Priority: Major
> Labels: CompileStatic, Matching, extends, inheritance, method,
> parameters, typecheck
>
> There is currently a maximum hierarchical depth for childclasses when using
> compile static.
> The compiler only searches for method parameters that match the provided
> class or up to 29 super classes. This in return means that the usable
> hierarchical depth is limited 29 child classes/distance from the root.
> Without CompileStatic this limit does not exists. Changing the following code
> to Java works too.
> This Code:
> {code:java}
> import groovy.transform.CompileStatic
> @CompileStatic
> class StaticTest {
>public static int getNummer( ZClassDepth0 instance ) {
> return instance.depth
>}
>public static void main( String[] args ) {
> println getNummer( new ZClassDepth29() ) //works
> println getNummer( new ZClassDepth30() ) //doesn't work
>}
> }
> {code}
> fails with the following execption:
> {code:java}
> Error:(13, 15) Groovyc: [Static type checking] - Cannot find matching method
> StaticTest#getNummer(ZClassDepth30). Please check if the declared type is
> right and if the method exists.
> {code}
>
> How the "ZClassDepth" files where generated:
> {code:java}
> import java.nio.file.Paths
> class Generator {
>public static void main( String[] args ) {
> def template = { int nummer ->
> return """\
> public class ZClassDepth${ nummer } ${ nummer > 0 ? "extends ZClassDepth${
> nummer - 1 }" : '' } {
>${ nummer > 0 ? '@Override' : '' }
>public int getDepth() {
> return $nummer
>}
> }
> """
> }
> def path = Paths.get( '[PATH_TO_SOURCE]/src' )
> 101.times{ i ->
> new File( path.toFile(), "ZClassDepth${i}.groovy" ).text = template(
> i )
> }
>}
> }
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8603) @CompileStatic: matching method check limited to 30 super classes
[
https://issues.apache.org/jira/browse/GROOVY-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Schmitz updated GROOVY-8603:
--
Labels: CompileStatic Matching extends inheritance method parameters
typecheck (was: CompileStatic Matching extends method parameters typecheck)
> @CompileStatic: matching method check limited to 30 super classes
> -
>
> Key: GROOVY-8603
> URL: https://issues.apache.org/jira/browse/GROOVY-8603
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.3.11, 2.4.13, 2.5.0-rc-3
>Reporter: Peter Schmitz
>Priority: Major
> Labels: CompileStatic, Matching, extends, inheritance, method,
> parameters, typecheck
>
> There is currently a maximum hierarchical depth for childclasses when using
> compile static.
> The compiler only searches for method parameters that match the provided
> class or up to 29 super classes. This in return means that the usable
> hierarchical depth is limited 29 child classes/distance from the root.
> Without CompileStatic this limit does not exists. Changing the following code
> to Java works too.
> This Code:
> {code:java}
> import groovy.transform.CompileStatic
> @CompileStatic
> class StaticTest {
>public static int getNummer( ZClassDepth0 instance ) {
> return instance.depth
>}
>public static void main( String[] args ) {
> println getNummer( new ZClassDepth29() ) //works
> println getNummer( new ZClassDepth30() ) //doesn't work
>}
> }
> {code}
> fails with the following execption:
> {code:java}
> Error:(13, 15) Groovyc: [Static type checking] - Cannot find matching method
> StaticTest#getNummer(ZClassDepth30). Please check if the declared type is
> right and if the method exists.
> {code}
>
> How the "ZClassDepth" files where generated:
> {code:java}
> import java.nio.file.Paths
> class Generator {
>public static void main( String[] args ) {
> def template = { int nummer ->
> return """\
> public class ZClassDepth${ nummer } ${ nummer > 0 ? "extends ZClassDepth${
> nummer - 1 }" : '' } {
>${ nummer > 0 ? '@Override' : '' }
>public int getDepth() {
> return $nummer
>}
> }
> """
> }
> def path = Paths.get( '[PATH_TO_SOURCE]/src' )
> 101.times{ i ->
> new File( path.toFile(), "ZClassDepth${i}.groovy" ).text = template(
> i )
> }
>}
> }
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8603) @CompileStatic: matching method check limited to 30 super classes
[
https://issues.apache.org/jira/browse/GROOVY-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16490423#comment-16490423
]
Peter Schmitz commented on GROOVY-8603:
---
I'd like to say no, but... yes, it is. :-/
> @CompileStatic: matching method check limited to 30 super classes
> -
>
> Key: GROOVY-8603
> URL: https://issues.apache.org/jira/browse/GROOVY-8603
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.3.11, 2.4.13, 2.5.0-rc-3
>Reporter: Peter Schmitz
>Priority: Major
> Labels: CompileStatic, Matching, extends, method, parameters,
> typecheck
>
> There is currently a maximum hierarchical depth for childclasses when using
> compile static.
> The compiler only searches for method parameters that match the provided
> class or up to 29 super classes. This in return means that the usable
> hierarchical depth is limited 29 child classes/distance from the root.
> Without CompileStatic this limit does not exists. Changing the following code
> to Java works too.
> This Code:
> {code:java}
> import groovy.transform.CompileStatic
> @CompileStatic
> class StaticTest {
>public static int getNummer( ZClassDepth0 instance ) {
> return instance.depth
>}
>public static void main( String[] args ) {
> println getNummer( new ZClassDepth29() ) //works
> println getNummer( new ZClassDepth30() ) //doesn't work
>}
> }
> {code}
> fails with the following execption:
> {code:java}
> Error:(13, 15) Groovyc: [Static type checking] - Cannot find matching method
> StaticTest#getNummer(ZClassDepth30). Please check if the declared type is
> right and if the method exists.
> {code}
>
> How the "ZClassDepth" files where generated:
> {code:java}
> import java.nio.file.Paths
> class Generator {
>public static void main( String[] args ) {
> def template = { int nummer ->
> return """\
> public class ZClassDepth${ nummer } ${ nummer > 0 ? "extends ZClassDepth${
> nummer - 1 }" : '' } {
>${ nummer > 0 ? '@Override' : '' }
>public int getDepth() {
> return $nummer
>}
> }
> """
> }
> def path = Paths.get( '[PATH_TO_SOURCE]/src' )
> 101.times{ i ->
> new File( path.toFile(), "ZClassDepth${i}.groovy" ).text = template(
> i )
> }
>}
> }
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8603) @CompileStatic: matching method check limited to 30 super classes
Peter Schmitz created GROOVY-8603:
-
Summary: @CompileStatic: matching method check limited to 30 super
classes
Key: GROOVY-8603
URL: https://issues.apache.org/jira/browse/GROOVY-8603
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Affects Versions: 2.5.0-rc-3, 2.4.13, 2.3.11
Reporter: Peter Schmitz
There is currently a maximum hierarchical depth for childclasses when using
compile static.
The compiler only searches for method parameters that match the provided class
or up to 29 super classes. This in return means that the usable hierarchical
depth is limited 29 child classes/distance from the root.
Without CompileStatic this limit does not exists. Changing the following code
to Java works too.
This Code:
{code:java}
import groovy.transform.CompileStatic
@CompileStatic
class StaticTest {
public static int getNummer( ZClassDepth0 instance ) {
return instance.depth
}
public static void main( String[] args ) {
println getNummer( new ZClassDepth29() ) //works
println getNummer( new ZClassDepth30() ) //doesn't work
}
}
{code}
fails with the following execption:
{code:java}
Error:(13, 15) Groovyc: [Static type checking] - Cannot find matching method
StaticTest#getNummer(ZClassDepth30). Please check if the declared type is right
and if the method exists.
{code}
How the "ZClassDepth" files where generated:
{code:java}
import java.nio.file.Paths
class Generator {
public static void main( String[] args ) {
def template = { int nummer ->
return """\
public class ZClassDepth${ nummer } ${ nummer > 0 ? "extends ZClassDepth${
nummer - 1 }" : '' } {
${ nummer > 0 ? '@Override' : '' }
public int getDepth() {
return $nummer
}
}
"""
}
def path = Paths.get( '[PATH_TO_SOURCE]/src' )
101.times{ i ->
new File( path.toFile(), "ZClassDepth${i}.groovy" ).text = template( i
)
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
