[jira] [Commented] (GROOVY-9472) Static import causes unresolved reference to become resolved
[
https://issues.apache.org/jira/browse/GROOVY-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507909#comment-17507909
]
Eric Milles commented on GROOVY-9472:
-
If you include the class or classes that file1 generates on the classpath when
compiling file2 there can be a significant difference. When compiled together,
source units are brought through compile phases in lockstep. In case of
Builder, the inner class is not generated before resolution of type references.
> Static import causes unresolved reference to become resolved
>
>
> Key: GROOVY-9472
> URL: https://issues.apache.org/jira/browse/GROOVY-9472
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static Type Checker
>Affects Versions: 2.5.10
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0
>
>
> {code:groovy|title=com/foo/Person.groovy}
> package com.foo
> @groovy.transform.builder.Builder
> class Person {
> String name
> }
> {code}
> 1.
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> class Main {
> static void main(String[] args) {
> Person.PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Trying to use it without a static import yields {{unable to resolve class
> Person.PersonBuilder}}, which is another issue.
> 2. Let's add a static import
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> The code compiles, but fails with {{java.lang.NoClassDefFoundError:
> PersonBuilder}} when run.
> 3. Let's add {{@CompileStatic}}
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> import groovy.transform.CompileStatic
> @CompileStatic
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Compilation fails with:
> {{Cannot assign value of type com.foo.Person$PersonBuilder to variable of
> type PersonBuilder}} and {{Cannot find matching method PersonBuilder#build()}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GROOVY-10530) Calling firstChild does not produce the same result as getFirstChild()
[
https://issues.apache.org/jira/browse/GROOVY-10530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507906#comment-17507906
]
Eric Milles commented on GROOVY-10530:
--
Does node provide isFirstChild()? If so this is a known breaking change in
Groovy 4.
> Calling firstChild does not produce the same result as getFirstChild()
> --
>
> Key: GROOVY-10530
> URL: https://issues.apache.org/jira/browse/GROOVY-10530
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.0
> Environment: IntelliJ IDEA 2021.3.2
> Java jdk1.8.0_211
> Groovy 4.0.0
>Reporter: Ted Lundqvist
>Priority: Major
>
> Calling firstChild returns a Boolean with the value false but getFirstChild()
> returns the correct object.
> Noticed this problem when upgrading from Groovy 3.0.5 to 4.0.0
> {code:java}
> import org.junit.jupiter.api.Test
> import org.w3c.dom.Node
> import org.xml.sax.InputSource
> import javax.xml.parsers.DocumentBuilderFactory
> import static org.junit.jupiter.api.Assertions.assertEquals
> class XmlTest {
> @Test()
> void firstChild_test() {
> String xml = "bar"
> Node node = DocumentBuilderFactory.newInstance()
> .newDocumentBuilder()
> .parse(new InputSource(new StringReader(xml)))
> assertEquals(node.getFirstChild().class, node.firstChild.class)
> //org.opentest4j.AssertionFailedError:
> //Expected :class
> com.sun.org.apache.xerces.internal.dom.DeferredElementImpl
> //Actual :class java.lang.Boolean
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GROOVY-9472) Static import causes unresolved reference to become resolved
[
https://issues.apache.org/jira/browse/GROOVY-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507786#comment-17507786
]
Daniil Ovchinnikov commented on GROOVY-9472:
More general problem: there should be *zero* difference in compilation of file1
and file2 together in one run and file1 followed by file2 in two subsequent
runs (= two different compilation units). I've encountered this problem
multiple times. The problem hits incremental recompilation, when e.g. file1 is
unchanged, and we only want to recompile file2. I'm not sure how it works in
Gradle, but it's one major pita in IJ, e.g. in this particular case the first
compilation run would compile Person.groovy and fail with an error in
Main.groovy, then the next run would compile Main.groovy successfully, so users
come and ask why IJ cannot do it in one go.
> Static import causes unresolved reference to become resolved
>
>
> Key: GROOVY-9472
> URL: https://issues.apache.org/jira/browse/GROOVY-9472
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static Type Checker
>Affects Versions: 2.5.10
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0
>
>
> {code:groovy|title=com/foo/Person.groovy}
> package com.foo
> @groovy.transform.builder.Builder
> class Person {
> String name
> }
> {code}
> 1.
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> class Main {
> static void main(String[] args) {
> Person.PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Trying to use it without a static import yields {{unable to resolve class
> Person.PersonBuilder}}, which is another issue.
> 2. Let's add a static import
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> The code compiles, but fails with {{java.lang.NoClassDefFoundError:
> PersonBuilder}} when run.
> 3. Let's add {{@CompileStatic}}
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> import groovy.transform.CompileStatic
> @CompileStatic
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Compilation fails with:
> {{Cannot assign value of type com.foo.Person$PersonBuilder to variable of
> type PersonBuilder}} and {{Cannot find matching method PersonBuilder#build()}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GROOVY-10524) BUG! exception in phase 'canonicalization' in source unit 'Script1.groovy' unexpected NullPointerException
[
https://issues.apache.org/jira/browse/GROOVY-10524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Schuhmann updated GROOVY-10524:
Description:
We see this {{AssertionError}} occasionally (difficult to reproduce) since
we've updated to Java 17.
The NPE occurs in {{ClassInfo.createCachedClass()}} in line 343 when it tries
to:
{code:java}
...
if (Number.class.isAssignableFrom(klazz) || klazz.isPrimitive()) {
...
{code}
{{klazz}} is {{null}} here. {{ClassInfo.createCachedClass()}} is called from
{{ClassInfo.LazyCachedClassRef.initValue()}} in line 437:
{code:java}
...
return createCachedClass(info.classRef.get(), info);
...
{code}
{{classRef}} is a {{WeakReference}} which has been collected and hence
{{get()}} returns {{{}null{}}}. Should there be another reference to that class
that should justify the assumption it cannot become stale?
The corresponding assertion is in
{{CompilationUnit.IPrimaryClassNodeOperation.doPhaseOperation()}} in line 902:
{code:java}
...
} catch (NullPointerException npe) {
GroovyBugError gbe = new GroovyBugError("unexpected NullPointerException",
npe);
unit.changeBugText(gbe, context);
throw gbe;
...
{code}
Before spending time to create a reproducible test case, I'm trying to gather
information what we could have done wrong on our side. We're executing a Groovy
script which in turn executes another Java class, which itself executed another
Groovy script. This inner Groovy script then executes other Java methods. When
running the corresponding code for 5-15 minutes it in most cases stops with the
above assertion in an inner Groovy script execution. We parse the Groovy
scripts in one phase, cache the {{groovy.lang.Script}} instances and then
execute these cached scripts in iterations. Once this assertion is thrown, all
further executions fail with the same assertion until JVM restart.
What could cause the weak reference to become stale? Assuming there must be
another reference to protect the referenced class from being collected by GC,
what could have caused this reference to be cut?
We're using Shenandoah GC with {{{}-XX:ShenandoahGCHeuristics=compact{}}}.
Other GCs and Shenandoah without {{compact}} heuristics seem to be not affected.
_Update: turns out this is caused by Shenandoah GC unloading classes referenced
by these weak references. With {{-XX:-ClassUnloadingWithConcurrentMark}}
Shenandoah seems to unload classes later, references remain valid and above
mentioned NPE doesn't occur._
was:
We see this {{AssertionError}} occasionally (difficult to reproduce) since
we've updated to Java 17.
The NPE occurs in {{ClassInfo.createCachedClass()}} in line 343 when it tries
to:
{code:java}
...
if (Number.class.isAssignableFrom(klazz) || klazz.isPrimitive()) {
...
{code}
{{klazz}} is {{null}} here. {{ClassInfo.createCachedClass()}} is called from
{{ClassInfo.LazyCachedClassRef.initValue()}} in line 437:
{code:java}
...
return createCachedClass(info.classRef.get(), info);
...
{code}
{{classRef}} is a {{WeakReference}} which has been collected and hence
{{get()}} returns {{{}null{}}}. Should there be another reference to that class
that should justify the assumption it cannot become stale?
The corresponding assertion is in
{{CompilationUnit.IPrimaryClassNodeOperation.doPhaseOperation()}} in line 902:
{code:java}
...
} catch (NullPointerException npe) {
GroovyBugError gbe = new GroovyBugError("unexpected NullPointerException",
npe);
unit.changeBugText(gbe, context);
throw gbe;
...
{code}
Before spending time to create a reproducible test case, I'm trying to gather
information what we could have done wrong on our side. We're executing a Groovy
script which in turn executes another Java class, which itself executed another
Groovy script. This inner Groovy script then executes other Java methods. When
running the corresponding code for 5-15 minutes it in most cases stops with the
above assertion in an inner Groovy script execution. We parse the Groovy
scripts in one phase, cache the {{groovy.lang.Script}} instances and then
execute these cached scripts in iterations. Once this assertion is thrown, all
further executions fail with the same assertion until JVM restart.
What could cause the weak reference to become stale? Assuming there must be
another reference to protect the referenced class from being collected by GC,
what could have caused this reference to be cut?
We're using Shenandoah GC with {{{}-XX:ShenandoahGCHeuristics=compact{}}}.
Other GCs and Shenandoah without {{compact}} seem to be not affected.
> BUG! exception in phase 'canonicalization' in source unit 'Script1.groovy'
> unexpected NullPointerException
> --
>
> Key: GROOVY-10524
> URL:
[jira] [Updated] (GROOVY-10530) Calling firstChild does not produce the same result as getFirstChild()
[
https://issues.apache.org/jira/browse/GROOVY-10530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Lundqvist updated GROOVY-10530:
---
Description:
Calling firstChild returns a Boolean with the value false but getFirstChild()
returns the correct object.
Noticed this problem when upgrading from Groovy 3.0.5 to 4.0.0
{code:java}
import org.junit.jupiter.api.Test
import org.w3c.dom.Node
import org.xml.sax.InputSource
import javax.xml.parsers.DocumentBuilderFactory
import static org.junit.jupiter.api.Assertions.assertEquals
class XmlTest {
@Test()
void firstChild_test() {
String xml = "bar"
Node node = DocumentBuilderFactory.newInstance()
.newDocumentBuilder()
.parse(new InputSource(new StringReader(xml)))
assertEquals(node.getFirstChild().class, node.firstChild.class)
//org.opentest4j.AssertionFailedError:
//Expected :class
com.sun.org.apache.xerces.internal.dom.DeferredElementImpl
//Actual :class java.lang.Boolean
}
}
{code}
was:
Calling firstChild returns a Boolean with the value false but getFirstChild()
returns the correct object.
Noticed this problem when upgrading from Groovy 3.0.5 to 4.0.0
{code:java}
import org.junit.jupiter.api.Test
import org.w3c.dom.Node
import org.xml.sax.InputSource
import javax.xml.parsers.DocumentBuilderFactory
import static org.junit.jupiter.api.Assertions.assertEquals
class XmlTest {
@Test()
void firstChild_test() {
String xml = "bar"
Node node = DocumentBuilderFactory.newInstance()
.newDocumentBuilder()
.parse(new InputSource(new StringReader(xml)))
assertEquals(node.firstChild.class, node.getFirstChild().class)
//org.opentest4j.AssertionFailedError:
//Expected :class java.lang.Boolean
//Actual :class org.apache.xerces.dom.DeferredElementImpl
}
}
{code}
> Calling firstChild does not produce the same result as getFirstChild()
> --
>
> Key: GROOVY-10530
> URL: https://issues.apache.org/jira/browse/GROOVY-10530
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.0
> Environment: IntelliJ IDEA 2021.3.2
> Java jdk1.8.0_211
> Groovy 4.0.0
>Reporter: Ted Lundqvist
>Priority: Major
>
> Calling firstChild returns a Boolean with the value false but getFirstChild()
> returns the correct object.
> Noticed this problem when upgrading from Groovy 3.0.5 to 4.0.0
> {code:java}
> import org.junit.jupiter.api.Test
> import org.w3c.dom.Node
> import org.xml.sax.InputSource
> import javax.xml.parsers.DocumentBuilderFactory
> import static org.junit.jupiter.api.Assertions.assertEquals
> class XmlTest {
> @Test()
> void firstChild_test() {
> String xml = "bar"
> Node node = DocumentBuilderFactory.newInstance()
> .newDocumentBuilder()
> .parse(new InputSource(new StringReader(xml)))
> assertEquals(node.getFirstChild().class, node.firstChild.class)
> //org.opentest4j.AssertionFailedError:
> //Expected :class
> com.sun.org.apache.xerces.internal.dom.DeferredElementImpl
> //Actual :class java.lang.Boolean
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GROOVY-10530) Calling firstChild does not produce the same result as getFirstChild()
Ted Lundqvist created GROOVY-10530:
--
Summary: Calling firstChild does not produce the same result as
getFirstChild()
Key: GROOVY-10530
URL: https://issues.apache.org/jira/browse/GROOVY-10530
Project: Groovy
Issue Type: Bug
Affects Versions: 4.0.0
Environment: IntelliJ IDEA 2021.3.2
Java jdk1.8.0_211
Groovy 4.0.0
Reporter: Ted Lundqvist
Calling firstChild returns a Boolean with the value false but getFirstChild()
returns the correct object.
Noticed this problem when upgrading from Groovy 3.0.5 to 4.0.0
{code:java}
import org.junit.jupiter.api.Test
import org.w3c.dom.Node
import org.xml.sax.InputSource
import javax.xml.parsers.DocumentBuilderFactory
import static org.junit.jupiter.api.Assertions.assertEquals
class XmlTest {
@Test()
void firstChild_test() {
String xml = "bar"
Node node = DocumentBuilderFactory.newInstance()
.newDocumentBuilder()
.parse(new InputSource(new StringReader(xml)))
assertEquals(node.firstChild.class, node.getFirstChild().class)
//org.opentest4j.AssertionFailedError:
//Expected :class java.lang.Boolean
//Actual :class org.apache.xerces.dom.DeferredElementImpl
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GROOVY-9472) Static import causes unresolved reference to become resolved
[
https://issues.apache.org/jira/browse/GROOVY-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507515#comment-17507515
]
Paul King commented on GROOVY-9472:
---
> * dynamic mode works fine as long as you do not reference the Builder class
> by name.
The JavaDoc for {{DefaultStrategy}} could certainly be expanded. I am unsure if
it is needed for {{InitializerStrategy}}. It is N/A for the other strategies.
> * static mode should just completely fail to use this annotation
There are currently unit tests for {{@CompileStatic}} with all strategies
including using a local variable for the builder. None of these tests ever
reference the builder classname at compile time but inference stores the
correct classes names for subsequent static compilation.
> * joint compilation fails for this if the usage is in the same compilation
> and in Java
We have the general disclaimer that traits may not work in conjunction with
some AST transforms, we should probably have something similar for joint
compilation and AST transforms.
> Static import causes unresolved reference to become resolved
>
>
> Key: GROOVY-9472
> URL: https://issues.apache.org/jira/browse/GROOVY-9472
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static Type Checker
>Affects Versions: 2.5.10
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0
>
>
> {code:groovy|title=com/foo/Person.groovy}
> package com.foo
> @groovy.transform.builder.Builder
> class Person {
> String name
> }
> {code}
> 1.
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> class Main {
> static void main(String[] args) {
> Person.PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Trying to use it without a static import yields {{unable to resolve class
> Person.PersonBuilder}}, which is another issue.
> 2. Let's add a static import
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> The code compiles, but fails with {{java.lang.NoClassDefFoundError:
> PersonBuilder}} when run.
> 3. Let's add {{@CompileStatic}}
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> import groovy.transform.CompileStatic
> @CompileStatic
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Compilation fails with:
> {{Cannot assign value of type com.foo.Person$PersonBuilder to variable of
> type PersonBuilder}} and {{Cannot find matching method PersonBuilder#build()}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GROOVY-9472) Static import causes unresolved reference to become resolved
[
https://issues.apache.org/jira/browse/GROOVY-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507476#comment-17507476
]
Jochen Theodorou commented on GROOVY-9472:
--
[~paulk] not sure I completely agree. For me the situation is as follows:
* dynamic mode works fine as long as you do not reference the Builder class by
name.
* static mode should just completely fail to use this annotation even with
default strategy, because even without the builder class reference it has to be
in bytecode as soon as you call for example
Person.builder().firstName("Robert"). Because without the Builder class being
available, we cannot resolve the firstName method. But since this actually
depends on method resolution it will still work as long as you do not reference
the class by name like in dynamic mode. Not sure if saving the builder in a
local variable and then calling methods on it is safe. It probably works.
* joint compilation fails for this if the usage is in the same compilation and
in Java
Still I think these things should be mentioned in the javadoc. Or if on our
website, then a reference should be done from the javadoc.
> Static import causes unresolved reference to become resolved
>
>
> Key: GROOVY-9472
> URL: https://issues.apache.org/jira/browse/GROOVY-9472
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static Type Checker
>Affects Versions: 2.5.10
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0
>
>
> {code:groovy|title=com/foo/Person.groovy}
> package com.foo
> @groovy.transform.builder.Builder
> class Person {
> String name
> }
> {code}
> 1.
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> class Main {
> static void main(String[] args) {
> Person.PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Trying to use it without a static import yields {{unable to resolve class
> Person.PersonBuilder}}, which is another issue.
> 2. Let's add a static import
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> The code compiles, but fails with {{java.lang.NoClassDefFoundError:
> PersonBuilder}} when run.
> 3. Let's add {{@CompileStatic}}
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> import groovy.transform.CompileStatic
> @CompileStatic
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Compilation fails with:
> {{Cannot assign value of type com.foo.Person$PersonBuilder to variable of
> type PersonBuilder}} and {{Cannot find matching method PersonBuilder#build()}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GROOVY-9472) Static import causes unresolved reference to become resolved
[
https://issues.apache.org/jira/browse/GROOVY-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507462#comment-17507462
]
Paul King commented on GROOVY-9472:
---
Yes, there are definitely two sides to the situation.
On the one hand, it isn't "complicated" when you use the feature in the
standard way. The documentation shows the standard way. In some sense, the fact
that an inner class is used as part of the building process for some strategies
is an internal detail that can usually be ignored. For a few of the strategies,
you call the {{builder()}} method to get the builder and the builder has a
{{build()}} method. For other strategies, no inner class is used or the other
details may differ. So by design, since the inner class is an internal detail
not mentioned in the source code anywhere, it is a class you should not be
referencing. The {{ExternalStrategy}} is by design one which mentions the
builder class and the preferred option when you want to use the class elsewhere.
On the other hand, the strategies align with some of the more common builder
strategies which Java folks use and there are expectations around how they work
and things which can be made to work if you were doing it by hand in Java. With
that in mind, I agree it would be good to consider more sophistication in the
resolution process.
> Static import causes unresolved reference to become resolved
>
>
> Key: GROOVY-9472
> URL: https://issues.apache.org/jira/browse/GROOVY-9472
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static Type Checker
>Affects Versions: 2.5.10
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0
>
>
> {code:groovy|title=com/foo/Person.groovy}
> package com.foo
> @groovy.transform.builder.Builder
> class Person {
> String name
> }
> {code}
> 1.
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> class Main {
> static void main(String[] args) {
> Person.PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Trying to use it without a static import yields {{unable to resolve class
> Person.PersonBuilder}}, which is another issue.
> 2. Let's add a static import
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> The code compiles, but fails with {{java.lang.NoClassDefFoundError:
> PersonBuilder}} when run.
> 3. Let's add {{@CompileStatic}}
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> import groovy.transform.CompileStatic
> @CompileStatic
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Compilation fails with:
> {{Cannot assign value of type com.foo.Person$PersonBuilder to variable of
> type PersonBuilder}} and {{Cannot find matching method PersonBuilder#build()}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GROOVY-9472) Static import causes unresolved reference to become resolved
[
https://issues.apache.org/jira/browse/GROOVY-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507389#comment-17507389
]
Jochen Theodorou commented on GROOVY-9472:
--
I have to add: Of course a normally declared inner class would have been picked
up, because the compiler does of course forward the added source unit to the
same phase. But maybe it should not stop at the same phase, maybe it should
complete the phase. Then we would still get a problem in circular references of
classes generated in that phase, but I think something like that should be
really a special problem
> Static import causes unresolved reference to become resolved
>
>
> Key: GROOVY-9472
> URL: https://issues.apache.org/jira/browse/GROOVY-9472
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static Type Checker
>Affects Versions: 2.5.10
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0
>
>
> {code:groovy|title=com/foo/Person.groovy}
> package com.foo
> @groovy.transform.builder.Builder
> class Person {
> String name
> }
> {code}
> 1.
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> class Main {
> static void main(String[] args) {
> Person.PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Trying to use it without a static import yields {{unable to resolve class
> Person.PersonBuilder}}, which is another issue.
> 2. Let's add a static import
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> The code compiles, but fails with {{java.lang.NoClassDefFoundError:
> PersonBuilder}} when run.
> 3. Let's add {{@CompileStatic}}
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> import groovy.transform.CompileStatic
> @CompileStatic
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Compilation fails with:
> {{Cannot assign value of type com.foo.Person$PersonBuilder to variable of
> type PersonBuilder}} and {{Cannot find matching method PersonBuilder#build()}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GROOVY-9472) Static import causes unresolved reference to become resolved
[
https://issues.apache.org/jira/browse/GROOVY-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507387#comment-17507387
]
Jochen Theodorou commented on GROOVY-9472:
--
[~paulk] I never used the annotation because frankly I have no use for it. But
if it is that "complicated" to use then (playing a new user's side here) I
would expect its limitations been documented. That some things don't work with
joint compilation is a big problem, but this does not work if it is in the same
compilation Unit and it is not even specific to @CompileStatic. As soon as you
reference the class in the same CompilationUnit in normal source code you get
a problem. For me this points to that the resolution of classes should not be a
single pass process if new sources are picked up during resolution, at least
not if we want to resolve an inner class of that. Of course I am aware of this
being complicated and introducing complications.
> Static import causes unresolved reference to become resolved
>
>
> Key: GROOVY-9472
> URL: https://issues.apache.org/jira/browse/GROOVY-9472
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static Type Checker
>Affects Versions: 2.5.10
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0
>
>
> {code:groovy|title=com/foo/Person.groovy}
> package com.foo
> @groovy.transform.builder.Builder
> class Person {
> String name
> }
> {code}
> 1.
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> class Main {
> static void main(String[] args) {
> Person.PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Trying to use it without a static import yields {{unable to resolve class
> Person.PersonBuilder}}, which is another issue.
> 2. Let's add a static import
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> The code compiles, but fails with {{java.lang.NoClassDefFoundError:
> PersonBuilder}} when run.
> 3. Let's add {{@CompileStatic}}
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> import groovy.transform.CompileStatic
> @CompileStatic
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Compilation fails with:
> {{Cannot assign value of type com.foo.Person$PersonBuilder to variable of
> type PersonBuilder}} and {{Cannot find matching method PersonBuilder#build()}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GROOVY-9472) Static import causes unresolved reference to become resolved
[
https://issues.apache.org/jira/browse/GROOVY-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507373#comment-17507373
]
Paul King commented on GROOVY-9472:
---
[~blackdrag] I don't think anything has changed w.r.t the normal compilation
path/usage for @Builder which has been identified as a potential issue before
(GROOVY-8803). In dynamic style (the context assumed in the design of most of
the current strategies), you might rarely need to reference the builder class
and can proceed as normal. For static typing scenarios or cases like the
@Delegate combination mentioned in GROOVY-8803, it would be good to have access
to the builder class. We could take some steps forward by making something like
a Buildable interface (would be Buildable in the above example). The
Default and External strategies could add this interface for example and we'd
need a way to make that happen early, e.g. CONVERSION. A similar trick might
fix the similar @Delegate with joint compilation issue discussed previously
(GROOVY-8105) if we could get it to work. This might not address all use cases
but might be a very useful step forward.
> Static import causes unresolved reference to become resolved
>
>
> Key: GROOVY-9472
> URL: https://issues.apache.org/jira/browse/GROOVY-9472
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static Type Checker
>Affects Versions: 2.5.10
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0
>
>
> {code:groovy|title=com/foo/Person.groovy}
> package com.foo
> @groovy.transform.builder.Builder
> class Person {
> String name
> }
> {code}
> 1.
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> class Main {
> static void main(String[] args) {
> Person.PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Trying to use it without a static import yields {{unable to resolve class
> Person.PersonBuilder}}, which is another issue.
> 2. Let's add a static import
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> The code compiles, but fails with {{java.lang.NoClassDefFoundError:
> PersonBuilder}} when run.
> 3. Let's add {{@CompileStatic}}
> {code:groovy|title=Main.groovy}
> import com.foo.Person
> import static com.foo.Person.PersonBuilder
> import groovy.transform.CompileStatic
> @CompileStatic
> class Main {
> static void main(String[] args) {
> PersonBuilder pb = Person.builder()
> println(pb.build())
> }
> }
> {code}
> Compilation fails with:
> {{Cannot assign value of type com.foo.Person$PersonBuilder to variable of
> type PersonBuilder}} and {{Cannot find matching method PersonBuilder#build()}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
