[jira] [Created] (GROOVY-11132) Bump jqwik to 1.7.4 (test dependency)
Paul King created GROOVY-11132: -- Summary: Bump jqwik to 1.7.4 (test dependency) Key: GROOVY-11132 URL: https://issues.apache.org/jira/browse/GROOVY-11132 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 4.0.8 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11131) Bump javaparser to 3.25.4
[ https://issues.apache.org/jira/browse/GROOVY-11131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11131: --- Fix Version/s: 4.0.14 (was: 4.0.12) > Bump javaparser to 3.25.4 > - > > Key: GROOVY-11131 > URL: https://issues.apache.org/jira/browse/GROOVY-11131 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.14 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11131) Bump javaparser to 3.25.4
Paul King created GROOVY-11131: -- Summary: Bump javaparser to 3.25.4 Key: GROOVY-11131 URL: https://issues.apache.org/jira/browse/GROOVY-11131 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 4.0.12 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11130) Groovy 4 doesn't have classes from groovy.antlr
[
https://issues.apache.org/jira/browse/GROOVY-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745313#comment-17745313
]
Paul King commented on GROOVY-11130:
The legacy parser was disabled by default for Groovy 3 and removed (see commit
below) for Groovy 4:
[https://github.com/apache/groovy/commit/fee8d39c539]
GroovyDoc parsing of Java files in Groovy 3 and 4 no longer uses the legacy
classes like {{Java2GroovyConverter}} and {{JavaLexer}} but instead uses the
{{com.github.javaparser:javaparser-core}} library and the
{{GroovydocJavaVisitor}} class. You can still use those classes directly or
disable the new parser when using Groovy 3.
Perhaps if you tell us what didn't work for you with GROOVY-10886 we can give
you further guidance. Certainly everything you seem to be doing is done already
in Groovy 4, just with the newer classes. Having said that, we only see a small
glimpse of what you are doing from the info so far in the issues.
Cheers, Paul.
> Groovy 4 doesn't have classes from groovy.antlr
> ---
>
> Key: GROOVY-11130
> URL: https://issues.apache.org/jira/browse/GROOVY-11130
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.0
> Environment: Gradle 7.1
> Java SDK 11
> Groovy 3.0.9 -> Groovy 4.0.2
>Reporter: Dmitry
>Priority: Major
>
> Hi team.
> I tried to resolve this issue in
> https://issues.apache.org/jira/browse/GROOVY-10886. But it was unsuccessful.
> The proposed 'GroovyShell' parser does not perform its functions.
> I tried to update Groovy for 4.0.2 version.
> But org.apache.groovy:groovy-all:4.0.2 doesn't have classes which we use in
> our project.
> AntlrASTProcessor
> SourceBuffer
> UnicodeEscapingReader
> Groovifier
> Java2GroovyConverter
> JavaLexer
> JavaRecognizer
> GroovyLexer
> GroovyRecognizer
> PreOrderTraversal
> SourceCodeTraversal
> Visitor
> SimpleGroovyClassDocAssembler
> In this method we create SimpleGroovyClassDoc. Do you have the same classes
> in Groovy 4?
>
> {code:java}
> import groovyjarjarantlr.RecognitionException
> import groovyjarjarantlr.TokenStreamException
> import groovyjarjarantlr.collections.AST
> import org.codehaus.groovy.antlr.AntlrASTProcessor
> import org.codehaus.groovy.antlr.SourceBuffer
> import org.codehaus.groovy.antlr.UnicodeEscapingReader
> import org.codehaus.groovy.antlr.java.Groovifier
> import org.codehaus.groovy.antlr.java.Java2GroovyConverter
> import org.codehaus.groovy.antlr.java.JavaLexer
> import org.codehaus.groovy.antlr.java.JavaRecognizer
> import org.codehaus.groovy.antlr.parser.GroovyLexer
> import org.codehaus.groovy.antlr.parser.GroovyRecognizer
> import org.codehaus.groovy.antlr.treewalker.PreOrderTraversal
> import org.codehaus.groovy.antlr.treewalker.SourceCodeTraversal
> import org.codehaus.groovy.antlr.treewalker.Visitor
> import org.codehaus.groovy.groovydoc.GroovyClassDoc
> import org.codehaus.groovy.runtime.ResourceGroovyMethods
> import org.codehaus.groovy.tools.groovydoc.SimpleGroovyClassDoc
> import org.codehaus.groovy.tools.groovydoc.SimpleGroovyClassDocAssembler
> class App {
> private Map parseGroovy(String src, String
> packagePath, String file)
> throws RecognitionException, TokenStreamException {
> boolean isJava = file.endsWith(".java")
> println "Groovy version: " + GroovySystem.version
> SourceBuffer sourceBuffer = new SourceBuffer()
> UnicodeEscapingReader unicodeReader = new UnicodeEscapingReader(new
> StringReader(src), sourceBuffer)
> def parser
> if (isJava) {
> JavaLexer lexer = new JavaLexer(unicodeReader)
> unicodeReader.setLexer(lexer)
> parser = JavaRecognizer.make(lexer)
> } else {
> GroovyLexer lexer = new GroovyLexer(unicodeReader)
> unicodeReader.setLexer(lexer)
> parser = GroovyRecognizer.make(lexer)
> }
> parser.setSourceBuffer(sourceBuffer)
> parser.compilationUnit()
> AST ast = parser.getAST()
> if (isJava) {
> // modify the Java AST into a Groovy AST (just token types)
> Visitor java2groovyConverter = new
> Java2GroovyConverter(parser.getTokenNames())
> AntlrASTProcessor java2groovyTraverser = new
> PreOrderTraversal(java2groovyConverter)
> java2groovyTraverser.process(ast)
> // now mutate (groovify) the ast into groovy
> Visitor groovifier = new Groovifier(parser.getTokenNames(), false)
> AntlrASTProcessor groovifierTraverser = new
> PreOrderTraversal(groovifier)
> groovifierTraverser.process(ast)
> }
> Visitor visitor = new SimpleGroovyClassDocAssembler(packagePath,
> file, sourceBuffer, links, properties, !isJava)
> AntlrASTProcessor traverser =
[jira] [Closed] (GROOVY-10886) Error in Groovy enums parsing using GroovyRecognizer
[
https://issues.apache.org/jira/browse/GROOVY-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-10886.
--
Assignee: Paul King
Resolution: Not A Problem
No further feedback, closing the issue.
> Error in Groovy enums parsing using GroovyRecognizer
>
>
> Key: GROOVY-10886
> URL: https://issues.apache.org/jira/browse/GROOVY-10886
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, parser
>Affects Versions: 2.5.15, 3.0.9
> Environment: Java SDK 11
> Gradle 7.4.1
> Groovy 2.5.15 ( This is version of our project, but parser and all the
> required entities are imported from gradle -> groovy 3.0.9)
>Reporter: Dmitry
>Assignee: Paul King
>Priority: Major
>
> We recently upgraded to gradle version 7.4.1 and ran into problem with
> parsing groovy enums.
> Environment:
> * Java SDK 11
> * Gradle 7.4.1
> * Groovy 2.5.15 ( This is version of our project, but parser and all the
> required entities are imported from gradle -> groovy 3.0.9)
> We try parse groovy enums using GroovyRecognizer. Groovy code:
> {code:java}
> SourceBuffer sourceBuffer = new SourceBuffer()
> UnicodeEscapingReader unicodeReader = new UnicodeEscapingReader(new
> StringReader(‘ExampleEnum.groovy'), sourceBuffer)
> GroovyLexer lexer = new GroovyLexer(unicodeReader)
> unicodeReader.setLexer(lexer)
> parser = GroovyRecognizer.make(lexer)
> parser.setSourceBuffer(sourceBuffer)
> parser.compilationUnit()
> {code}
> Enum example:
> {code:java}
> @API
> public enum ExampleEnum implements Serializable {
> @API
> ITEM1(1),
> @API
> ITEM2(2),
> @API
> ITEM3(3);
>
> private Integer value;
> public TaggableClasses(Integer value) {
> this.value = value;
> }
> public Integer getValue() {
> return this.value;
> }
> {code}
> {{.compilationUnit()}} method throws an exception "Parsing failed for
> 'ExampleEnum.groovy' due to: unexpected token: 2"
> Token is value of ITEM2.
> Groovy class and interfaces parsing work correctly.
> My colleague created a test project that reproduces the issue.
> [https://github.com/KeyrisXdSnow/GradleReproducer.git]
> We discussed the issue with gradle team, they said it is not on their
> (gradle) side. https://github.com/gradle/gradle/issues/20244
> Could you please advise how we can solve this problem?
> Thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745296#comment-17745296
]
Kenneth W DeLong commented on GROOVY-11126:
---
Thank you all for the quick work! You are all rock stars.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Assignee: Eric Milles
>Priority: Critical
> Fix For: 4.0.14
>
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-4232) Better support for CheckedCollections
[ https://issues.apache.org/jira/browse/GROOVY-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Milles resolved GROOVY-4232. - Fix Version/s: 5.0.0-alpha-1 Resolution: Fixed https://github.com/apache/groovy/commit/07416cfef93594b1388c4cf679c8e92499f9cd1c > Better support for CheckedCollections > - > > Key: GROOVY-4232 > URL: https://issues.apache.org/jira/browse/GROOVY-4232 > Project: Groovy > Issue Type: New Feature > Components: groovy-jdk >Affects Versions: 1.7.2 >Reporter: Paul King >Assignee: Eric Milles >Priority: Major > Fix For: 5.0.0-alpha-1 > > Attachments: AlphaCheckedTransform.patch > > > Groovy could provide better support for the CheckedCollection, CheckedList, > CheckedMap, etc. classes from java.util.Collections. This could include > supporting asChecked(klass) methods in the DGM or could involve creation of > AST transforms. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GROOVY-4232) Better support for CheckedCollections
[ https://issues.apache.org/jira/browse/GROOVY-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Milles reassigned GROOVY-4232: --- Assignee: Eric Milles > Better support for CheckedCollections > - > > Key: GROOVY-4232 > URL: https://issues.apache.org/jira/browse/GROOVY-4232 > Project: Groovy > Issue Type: New Feature > Components: groovy-jdk >Affects Versions: 1.7.2 >Reporter: Paul King >Assignee: Eric Milles >Priority: Major > Attachments: AlphaCheckedTransform.patch > > > Groovy could provide better support for the CheckedCollection, CheckedList, > CheckedMap, etc. classes from java.util.Collections. This could include > supporting asChecked(klass) methods in the DGM or could involve creation of > AST transforms. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11130) Groovy 4 doesn't have classes from groovy.antlr
Dmitry created GROOVY-11130:
---
Summary: Groovy 4 doesn't have classes from groovy.antlr
Key: GROOVY-11130
URL: https://issues.apache.org/jira/browse/GROOVY-11130
Project: Groovy
Issue Type: Bug
Affects Versions: 4.0.0
Environment: Gradle 7.1
Java SDK 11
Groovy 3.0.9 -> Groovy 4.0.2
Reporter: Dmitry
Hi team.
I tried to resolve this issue in
https://issues.apache.org/jira/browse/GROOVY-10886. But it was unsuccessful.
The proposed 'GroovyShell' parser does not perform its functions.
I tried to update Groovy for 4.0.2 version.
But org.apache.groovy:groovy-all:4.0.2 doesn't have classes which we use in our
project.
AntlrASTProcessor
SourceBuffer
UnicodeEscapingReader
Groovifier
Java2GroovyConverter
JavaLexer
JavaRecognizer
GroovyLexer
GroovyRecognizer
PreOrderTraversal
SourceCodeTraversal
Visitor
SimpleGroovyClassDocAssembler
In this method we create SimpleGroovyClassDoc. Do you have the same classes in
Groovy 4?
{code:java}
import groovyjarjarantlr.RecognitionException
import groovyjarjarantlr.TokenStreamException
import groovyjarjarantlr.collections.AST
import org.codehaus.groovy.antlr.AntlrASTProcessor
import org.codehaus.groovy.antlr.SourceBuffer
import org.codehaus.groovy.antlr.UnicodeEscapingReader
import org.codehaus.groovy.antlr.java.Groovifier
import org.codehaus.groovy.antlr.java.Java2GroovyConverter
import org.codehaus.groovy.antlr.java.JavaLexer
import org.codehaus.groovy.antlr.java.JavaRecognizer
import org.codehaus.groovy.antlr.parser.GroovyLexer
import org.codehaus.groovy.antlr.parser.GroovyRecognizer
import org.codehaus.groovy.antlr.treewalker.PreOrderTraversal
import org.codehaus.groovy.antlr.treewalker.SourceCodeTraversal
import org.codehaus.groovy.antlr.treewalker.Visitor
import org.codehaus.groovy.groovydoc.GroovyClassDoc
import org.codehaus.groovy.runtime.ResourceGroovyMethods
import org.codehaus.groovy.tools.groovydoc.SimpleGroovyClassDoc
import org.codehaus.groovy.tools.groovydoc.SimpleGroovyClassDocAssembler
class App {
private Map parseGroovy(String src, String
packagePath, String file)
throws RecognitionException, TokenStreamException {
boolean isJava = file.endsWith(".java")
println "Groovy version: " + GroovySystem.version
SourceBuffer sourceBuffer = new SourceBuffer()
UnicodeEscapingReader unicodeReader = new UnicodeEscapingReader(new
StringReader(src), sourceBuffer)
def parser
if (isJava) {
JavaLexer lexer = new JavaLexer(unicodeReader)
unicodeReader.setLexer(lexer)
parser = JavaRecognizer.make(lexer)
} else {
GroovyLexer lexer = new GroovyLexer(unicodeReader)
unicodeReader.setLexer(lexer)
parser = GroovyRecognizer.make(lexer)
}
parser.setSourceBuffer(sourceBuffer)
parser.compilationUnit()
AST ast = parser.getAST()
if (isJava) {
// modify the Java AST into a Groovy AST (just token types)
Visitor java2groovyConverter = new
Java2GroovyConverter(parser.getTokenNames())
AntlrASTProcessor java2groovyTraverser = new
PreOrderTraversal(java2groovyConverter)
java2groovyTraverser.process(ast)
// now mutate (groovify) the ast into groovy
Visitor groovifier = new Groovifier(parser.getTokenNames(), false)
AntlrASTProcessor groovifierTraverser = new
PreOrderTraversal(groovifier)
groovifierTraverser.process(ast)
}
Visitor visitor = new SimpleGroovyClassDocAssembler(packagePath, file,
sourceBuffer, links, properties, !isJava)
AntlrASTProcessor traverser = new SourceCodeTraversal(visitor)
traverser.process(ast)
return ((SimpleGroovyClassDocAssembler)visitor).getGroovyClassDocs()
}
}{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GROOVY-10099) A single null argument to a varargs parameter is received as null
[
https://issues.apache.org/jira/browse/GROOVY-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles closed GROOVY-10099.
Resolution: Won't Fix
> A single null argument to a varargs parameter is received as null
> -
>
> Key: GROOVY-10099
> URL: https://issues.apache.org/jira/browse/GROOVY-10099
> Project: Groovy
> Issue Type: Bug
>Reporter: Rachel Greenham
>Assignee: Eric Milles
>Priority: Major
> Labels: varargs
> Attachments: VarArgsTest.groovy, VarArgsTest.jsh
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> (NB: I would set the priority to P2 default to be triaged, but I seem not to
> have that option, so I left it at the default I was presented with.)
> When calling a method with a varargs parameter with a single value, that
> value is wrapped into an array of length 1. This is the behaviour in Java,
> and is the expected behaviour, and _most_ of the time is the behaviour in
> Groovy too.
> But when that single value is null, Groovy will instead just pass the null
> into the method. Java will not do this: You'll get an array with a single
> null in it. Because Groovy's behaviour is unexpected, especially when
> interfacing with Java code, NullPointerExceptions can often ensue.
> Adding to the inconsistencies, if the Groovy code calling the method is in a
> {{@CompileStatic}} context, it behaves just like Java, and the method
> (whether or not _it_ is statically compiled or a dynamic Groovy method)
> receives an array with a null in it.
> So the behaviour in Groovy is inconsistent, both with itself in a
> {{@CompileStatic}} situation, and with Java, and is requiring workarounds in
> Java code to handle this normally-impossible eventuality. (Even if no varargs
> parameter is given you get an empty array, as in fact you do in Groovy too.)
> This may be an "early instalment weirdness": There's an ancient ticket, from
> not long after varargs were introduced into Java, which appears to have
> argued - successfully at the time - that the normal behaviour is a bug:
> https://issues.apache.org/jira/browse/GROOVY-1026
> Further adding to the confusion may be that Groovy usually elides the
> difference between an {{Object[]}} parameter and an {{Object...}} parameter:
> They both behave the same.
> The offending code appears to be in
> org.codehaus.groovy.reflection.ParameterTypes.java in method fitToVars, lines
> 200-215 in master at the time of writing, which even includes a comment that
> "if the last argument is null, then we don't have to do anything", with which
> I respectfully disagree. :) That behaviour should be to return an array with
> a single null in it (Handily, MetaClassHelper.ARRAY_WITH_NULL saves having to
> make a new one.)
> In principle it's an easy fix (although I've left tagging to others as this
> is my first issue here), but there'd be an obvious nervousness about changing
> behaviour like this when there might be a lot of old code out there depending
> on it behaving the way it does now. OTOH the way it behaves now is breaking
> the expectations of those of us coming to Groovy from a lifetime of Java...
> Attachments:
> VarArgsTest.groovy - a script saved from, and runnable in, groovyConsole,
> demonstrating the behaviour. The behaviour is the same regardless of whether
> the console is launched with the -indy option. (The issue was initially
> observed in indy.) The dynamic portion of the test, when run, ends in a
> NullPointerException as Arrays.asList is not expecting a null varargs
> parameter. Output seen (-indy or not):
>
> {code:java}
> name: the static name 1
> params is null? false
> params length is 1
> [blah]
> name: the static name 2
> params is null? false
> params length is 2
> [blah, blue]
> name: the static name 3 with blah=null
> params is null? false
> params length is 1
> [null]
> Arrays.asList(blah)? [null]
> name: the dynamic name 1
> params is null? false
> params length is 1
> [blah]
> name: the dynamic name 2
> params is null? false
> params length is 2
> [blah, blue]
> name: the dynamic name 3 with blah=null
> params is null? true
> Exception thrown
> java.lang.NullPointerException
> ...{code}
> (etc. stack trace not shown for formatting reasons.)
> VarArgsTest.jsh - a jshell script demonstrating Java's behaviour, very
> similar to the groovy test, but omitting the dynamic portion of the test for
> obvious reasons. (The statements in the Groovy script ending in semicolons
> are left that way precisely to mark that they're identical to the Java test.)
> Runnable with
>
> {code:java}
> jshell PRINTING VarArgsTest.jsh
> {code}
> Output seen:
> {code:java}
> name: the static name 1
> params is null? false
> params length is 1
> [blah]
> name: the static name 2
[jira] [Commented] (GROOVY-10099) A single null argument to a varargs parameter is received as null
[
https://issues.apache.org/jira/browse/GROOVY-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745172#comment-17745172
]
Eric Milles commented on GROOVY-10099:
--
When the method target is known, {{InvocationWriter}} adds an {{instanceof}}
check to sort out if the single argument for the variadic parameter is an array
or a scalar (see GROOVY-10722). The cached and uncached paths have no fore
knowledge of the method target. So all I can think of is to write a typecast
for every trailing argument. I don't think that would be reasonable to do.
See InvokeDynamicWriter#makeIndyCall args loop.
> A single null argument to a varargs parameter is received as null
> -
>
> Key: GROOVY-10099
> URL: https://issues.apache.org/jira/browse/GROOVY-10099
> Project: Groovy
> Issue Type: Bug
>Reporter: Rachel Greenham
>Assignee: Eric Milles
>Priority: Major
> Labels: varargs
> Attachments: VarArgsTest.groovy, VarArgsTest.jsh
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> (NB: I would set the priority to P2 default to be triaged, but I seem not to
> have that option, so I left it at the default I was presented with.)
> When calling a method with a varargs parameter with a single value, that
> value is wrapped into an array of length 1. This is the behaviour in Java,
> and is the expected behaviour, and _most_ of the time is the behaviour in
> Groovy too.
> But when that single value is null, Groovy will instead just pass the null
> into the method. Java will not do this: You'll get an array with a single
> null in it. Because Groovy's behaviour is unexpected, especially when
> interfacing with Java code, NullPointerExceptions can often ensue.
> Adding to the inconsistencies, if the Groovy code calling the method is in a
> {{@CompileStatic}} context, it behaves just like Java, and the method
> (whether or not _it_ is statically compiled or a dynamic Groovy method)
> receives an array with a null in it.
> So the behaviour in Groovy is inconsistent, both with itself in a
> {{@CompileStatic}} situation, and with Java, and is requiring workarounds in
> Java code to handle this normally-impossible eventuality. (Even if no varargs
> parameter is given you get an empty array, as in fact you do in Groovy too.)
> This may be an "early instalment weirdness": There's an ancient ticket, from
> not long after varargs were introduced into Java, which appears to have
> argued - successfully at the time - that the normal behaviour is a bug:
> https://issues.apache.org/jira/browse/GROOVY-1026
> Further adding to the confusion may be that Groovy usually elides the
> difference between an {{Object[]}} parameter and an {{Object...}} parameter:
> They both behave the same.
> The offending code appears to be in
> org.codehaus.groovy.reflection.ParameterTypes.java in method fitToVars, lines
> 200-215 in master at the time of writing, which even includes a comment that
> "if the last argument is null, then we don't have to do anything", with which
> I respectfully disagree. :) That behaviour should be to return an array with
> a single null in it (Handily, MetaClassHelper.ARRAY_WITH_NULL saves having to
> make a new one.)
> In principle it's an easy fix (although I've left tagging to others as this
> is my first issue here), but there'd be an obvious nervousness about changing
> behaviour like this when there might be a lot of old code out there depending
> on it behaving the way it does now. OTOH the way it behaves now is breaking
> the expectations of those of us coming to Groovy from a lifetime of Java...
> Attachments:
> VarArgsTest.groovy - a script saved from, and runnable in, groovyConsole,
> demonstrating the behaviour. The behaviour is the same regardless of whether
> the console is launched with the -indy option. (The issue was initially
> observed in indy.) The dynamic portion of the test, when run, ends in a
> NullPointerException as Arrays.asList is not expecting a null varargs
> parameter. Output seen (-indy or not):
>
> {code:java}
> name: the static name 1
> params is null? false
> params length is 1
> [blah]
> name: the static name 2
> params is null? false
> params length is 2
> [blah, blue]
> name: the static name 3 with blah=null
> params is null? false
> params length is 1
> [null]
> Arrays.asList(blah)? [null]
> name: the dynamic name 1
> params is null? false
> params length is 1
> [blah]
> name: the dynamic name 2
> params is null? false
> params length is 2
> [blah, blue]
> name: the dynamic name 3 with blah=null
> params is null? true
> Exception thrown
> java.lang.NullPointerException
> ...{code}
> (etc. stack trace not shown for formatting reasons.)
> VarArgsTest.jsh - a jshell script demonstrating Java's behaviour,
[jira] [Comment Edited] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745158#comment-17745158
]
Eric Milles edited comment on GROOVY-11126 at 7/20/23 4:14 PM:
---
A call with non-null receiver like "color=''; color?.size()" will fall to the
new block which adds a guard so that null will have the call site go to
fallback. Then if you come through with a call with null receiver like "color
= null; color?.size()" the first set of guards will be added (the IS_NULL path).
If you have a test that demonstrates a problem, please share.
was (Author: emilles):
A call with non-null receiver like "color=''; color?.size()" will fall to the
new block which adds a guard so that null will have the call site go to
fallback. Then if you com through with a call with null receiver like "color =
null; color?.size()" the first set of guards will be added (the IS_NULL path).
If you have a test that demonstrates a problem, please share.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Assignee: Eric Milles
>Priority: Critical
> Fix For: 4.0.14
>
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745158#comment-17745158
]
Eric Milles commented on GROOVY-11126:
--
A call with non-null receiver like "color=''; color?.size()" will fall to the
new block which adds a guard so that null will have the call site go to
fallback. Then if you com through with a call with null receiver like "color =
null; color?.size()" the first set of guards will be added (the IS_NULL path).
If you have a test that demonstrates a problem, please share.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Assignee: Eric Milles
>Priority: Critical
> Fix For: 4.0.14
>
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-9851) Private field and method use from subclass is inconsistent
[
https://issues.apache.org/jira/browse/GROOVY-9851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745135#comment-17745135
]
Eric Milles edited comment on GROOVY-9851 at 7/20/23 3:35 PM:
--
Consistency is now quite good. The only subversive access that remains is
acquiring a method closure for the parent class and binding {{this}} with curry.
{code:groovy}
@Test
void 'testGROOVY 8999 9851'() {
assertScript '''import static groovy.test.GroovyAssert.shouldFail
class Foo {
private String field = 'field'
private String method() { 'method' }
}
class Bar extends Foo {
void test1() {
field
}
void test2() {
method()
}
void test3() {
this.field
}
void test4() {
this.method()
}
void test5() {
super.@field
}
void test6() {
super.field
}
void test7() {
super.method()
}
void test8() {
(this.)()
}
void test9() {
(super.)()
}
def testX() {
(Foo.(this))() // GROOVY-5051 workaround
}
}
/*line 40*/ def bar = new Bar()
shouldFail(MissingPropertyException, bar.)
shouldFail(MissingMethodException , bar.)
shouldFail(MissingPropertyException, bar.)
shouldFail(MissingMethodException , bar.)
shouldFail(MissingFieldException , bar.)
shouldFail(MissingPropertyException, bar.)
shouldFail(MissingMethodException , bar.)
shouldFail(MissingMethodException , bar.)
shouldFail(MissingMethodException , bar.)
assert bar.testX() == 'method'
'''
}
{code}
was (Author: emilles):
Consistency is now quite good. The only subversive access that remains is
acquiring a method closure for the parent class and binding this with curry.
{code:groovy}
@Test
void 'testGROOVY 8999 9851'() {
assertScript '''import static groovy.test.GroovyAssert.shouldFail
class Foo {
private String field = 'field'
private String method() { 'method' }
}
class Bar extends Foo {
void test1() {
field
}
void test2() {
method()
}
void test3() {
this.field
}
void test4() {
this.method()
}
void test5() {
super.@field
}
void test6() {
super.field
}
void test7() {
super.method()
}
void test8() {
(this.)()
}
void test9() {
(super.)()
}
def testX() {
(Foo.(this))() // GROOVY-5051 workaround
}
}
/*line 40*/ def bar = new Bar()
shouldFail(MissingPropertyException, bar.)
shouldFail(MissingMethodException , bar.)
shouldFail(MissingPropertyException, bar.)
shouldFail(MissingMethodException , bar.)
shouldFail(MissingFieldException , bar.)
shouldFail(MissingPropertyException, bar.)
shouldFail(MissingMethodException , bar.)
shouldFail(MissingMethodException , bar.)
shouldFail(MissingMethodException , bar.)
assert bar.testX() == 'method'
'''
}
{code}
> Private field and method use from subclass is inconsistent
> --
>
> Key: GROOVY-9851
> URL: https://issues.apache.org/jira/browse/GROOVY-9851
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
> Fix For: 4.0.0-rc-2
>
>
> This is probably just a slice of GROOVY-1591, GROOVY-3010, GROOVY-3142,
> GROOVY-5438, et al.
> Adding "super." qualifier causes strange behaviors. Consider the following:
> {code:java}
> class Foo {
> private String field = 'field'
> private String method() { 'method' }
> }
> class Bar extends Foo {
> def baz() {
> field // MissingPropertyException: No such property: field for class: Bar
> method() // MissingMethodException:
[jira] [Commented] (GROOVY-9851) Private field and method use from subclass is inconsistent
[
https://issues.apache.org/jira/browse/GROOVY-9851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745135#comment-17745135
]
Eric Milles commented on GROOVY-9851:
-
Consistency is now quite good. The only subversive access that remains is
acquiring a method closure for the parent class and binding this with curry.
{code:groovy}
@Test
void 'testGROOVY 8999 9851'() {
assertScript '''import static groovy.test.GroovyAssert.shouldFail
class Foo {
private String field = 'field'
private String method() { 'method' }
}
class Bar extends Foo {
void test1() {
field
}
void test2() {
method()
}
void test3() {
this.field
}
void test4() {
this.method()
}
void test5() {
super.@field
}
void test6() {
super.field
}
void test7() {
super.method()
}
void test8() {
(this.)()
}
void test9() {
(super.)()
}
def testX() {
(Foo.(this))() // GROOVY-5051 workaround
}
}
/*line 40*/ def bar = new Bar()
shouldFail(MissingPropertyException, bar.)
shouldFail(MissingMethodException , bar.)
shouldFail(MissingPropertyException, bar.)
shouldFail(MissingMethodException , bar.)
shouldFail(MissingFieldException , bar.)
shouldFail(MissingPropertyException, bar.)
shouldFail(MissingMethodException , bar.)
shouldFail(MissingMethodException , bar.)
shouldFail(MissingMethodException , bar.)
assert bar.testX() == 'method'
'''
}
{code}
> Private field and method use from subclass is inconsistent
> --
>
> Key: GROOVY-9851
> URL: https://issues.apache.org/jira/browse/GROOVY-9851
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
> Fix For: 4.0.0-rc-2
>
>
> This is probably just a slice of GROOVY-1591, GROOVY-3010, GROOVY-3142,
> GROOVY-5438, et al.
> Adding "super." qualifier causes strange behaviors. Consider the following:
> {code:java}
> class Foo {
> private String field = 'field'
> private String method() { 'method' }
> }
> class Bar extends Foo {
> def baz() {
> field // MissingPropertyException: No such property: field for class: Bar
> method() // MissingMethodException: No signature of method: Bar.method()
> this.field // MissingPropertyException: No such property: field for
> class: Bar
> this.method() // MissingMethodException: No signature of method:
> Bar.method()
> super.@field // MissingFieldException: No such field: field for class:
> Bar -- fixed by GROOVY-8999
> // so far, so good -- although Groovy allows access to private fields and
> methods from outside of Bar and Foo
> super.field // MissingMethodException: No signature of method:
> Bar.getField() -- that's strange
> super.method() // returns "method" -- Why is this okay?
> (super.)() // MissingMethodException: No signature of method:
> Bar.method() is applicable for argument types: () values: []
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745127#comment-17745127
]
Jochen Theodorou edited comment on GROOVY-11126 at 7/20/23 3:18 PM:
[~emilles]I think that needs a bit rework. First of all I would change the test
to not do the times loop, it is not required for the issue, and if it is, then
the there is another problem hidden by your solution. So I suggest using:
{code:Java}
def test(String string) {
string?.size()
}
test('1')
test('')
test()
test('2')
{code}
that is especially to cover the case NotNull->Null and Null->NotNull.
New line 943 does the null case, and applies guards IS_NULL and optionally
SAME_CLASS. 964 is the elseif to that, so here the receiver is not null. It
adds here the SAME_CLASS check if the arguments can change class. Your new code
in 970 is then another elseif and only called if the receiver is not null and
the arguments cannnot change class. Which means it will not be added in the
following case:
{code:Java}
def test(string) {
string?.size()
}
test('1')
test('')
test()
test('2')
{code}
Therefore your if-block should be inside the first elseif.
Unless I did misread the code again of course.
was (Author: blackdrag):
[~emilles]I think that needs a bit rework. First of all I would change the test
to not do the times loop, it is not required for the issue, and if it is, then
the there is another problem hidden by your solution. So I suggest using:
{code:Java}
def test(String string) {
string?.size()
}
test('1')
test('')
test()
test('2')
{code:Java}
that is especially to cover the case NotNull->Null and Null->NotNull.
New line 943 does the null case, and applies guards IS_NULL and optionally
SAME_CLASS. 964 is the elseif to that, so here the receiver is not null. It
adds here the SAME_CLASS check if the arguments can change class. Your new code
in 970 is then another elseif and only called if the receiver is not null and
the arguments cannnot change class. Which means it will not be added in the
following case:
{code:Java}
def test(string) {
string?.size()
}
test('1')
test('')
test()
test('2')
{code:Java}
Therefore your if-block should be inside the first elseif.
Unless I did misread the code again of course.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Assignee: Eric Milles
>Priority: Critical
> Fix For: 4.0.14
>
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745127#comment-17745127
]
Jochen Theodorou commented on GROOVY-11126:
---
[~emilles]I think that needs a bit rework. First of all I would change the test
to not do the times loop, it is not required for the issue, and if it is, then
the there is another problem hidden by your solution. So I suggest using:
{code:Java}
def test(String string) {
string?.size()
}
test('1')
test('')
test()
test('2')
{code:Java}
that is especially to cover the case NotNull->Null and Null->NotNull.
New line 943 does the null case, and applies guards IS_NULL and optionally
SAME_CLASS. 964 is the elseif to that, so here the receiver is not null. It
adds here the SAME_CLASS check if the arguments can change class. Your new code
in 970 is then another elseif and only called if the receiver is not null and
the arguments cannnot change class. Which means it will not be added in the
following case:
{code:Java}
def test(string) {
string?.size()
}
test('1')
test('')
test()
test('2')
{code:Java}
Therefore your if-block should be inside the first elseif.
Unless I did misread the code again of course.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Assignee: Eric Milles
>Priority: Critical
> Fix For: 4.0.14
>
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11129) STC chooses to call a non-polymorphic method although explicit type arguments are given
[
https://issues.apache.org/jira/browse/GROOVY-11129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745120#comment-17745120
]
Eric Milles commented on GROOVY-11129:
--
You should be able to add a typecast to clarify:
{code:groovy}
@groovy.transform.TypeChecked
void test(ExecutorService executor) {
Future future =
executor.submit((Callable) () -> "")
}
{code}
> STC chooses to call a non-polymorphic method although explicit type arguments
> are given
> ---
>
> Key: GROOVY-11129
> URL: https://issues.apache.org/jira/browse/GROOVY-11129
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
> Labels: overloading
>
> I have the following code:
> {code}
> import java.util.concurrent.*;
> class Main {
> static final void test() {
> ExecutorService z = null;
> Future future = z.submit(() -> "fd");
> }
> }
> {code}
> h3. Actual behavior
> {code}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Main.groovy: 7: [Static type checking] - Incompatible generic argument types.
> Cannot assign java.util.concurrent.Future to:
> java.util.concurrent.Future
> @ line 7, column 35.
>Future future = z.submit(() -> "fd");
> ^
> 1 error
> {code}
> h3. Expected behavior
> Compile successfully
> h3. Notes
> It seems that the compiler chooses to call the variant that takes no type
> arguments (see
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/ExecutorService.html#submit(java.lang.Runnable),
> even though explicit type arguments are given.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GROOVY-11129) STC chooses to call a non-polymorphic method although explicit type arguments are given
[
https://issues.apache.org/jira/browse/GROOVY-11129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles closed GROOVY-11129.
Resolution: Duplicate
> STC chooses to call a non-polymorphic method although explicit type arguments
> are given
> ---
>
> Key: GROOVY-11129
> URL: https://issues.apache.org/jira/browse/GROOVY-11129
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
> Labels: overloading
>
> I have the following code:
> {code}
> import java.util.concurrent.*;
> class Main {
> static final void test() {
> ExecutorService z = null;
> Future future = z.submit(() -> "fd");
> }
> }
> {code}
> h3. Actual behavior
> {code}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Main.groovy: 7: [Static type checking] - Incompatible generic argument types.
> Cannot assign java.util.concurrent.Future to:
> java.util.concurrent.Future
> @ line 7, column 35.
>Future future = z.submit(() -> "fd");
> ^
> 1 error
> {code}
> h3. Expected behavior
> Compile successfully
> h3. Notes
> It seems that the compiler chooses to call the variant that takes no type
> arguments (see
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/ExecutorService.html#submit(java.lang.Runnable),
> even though explicit type arguments are given.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11127) Add '|', '&', and '^' operators to Set and SortedSet
[
https://issues.apache.org/jira/browse/GROOVY-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745109#comment-17745109
]
ASF GitHub Bot commented on GROOVY-11127:
-
paulk-asert commented on PR #1915:
URL: https://github.com/apache/groovy/pull/1915#issuecomment-1644012383
I am still keen to keep Iterable as the second argument (option 3). It makes
most sense with how the DGM methods and the Java APIs are designed. I agree
that non-symmetry can potentially lead to confusion but I don't see that
applies here.
If we have explained that "union" is like a Set-specific "plus", then I
don't see why folks might expect it to work for Collections.
If I have `Set wordsSeen` and `List nextSentence`, then
doing `wordsSeen |= nextSentence` makes perfect sense just like we currently
would allow `wordsSeen += nextSentence`. Folks dealing with large datasets
aren't going to want the extra time or memory hit of creating the superfluous
set. I don't see folks suddenly expecting `nextSentence |= wordsSeen` to be
available when we have explained this as a set operation.
Or, to say it a different way, Set already has `containsAll(Collection)`,
`addAll(Collection)`,` retainAll(Collection)`, `removeAll(Collection)`, as well
as the Collection constructor, e.g. in HashSet. I see no problem with having
`union(Collection)` or in our case we'd have `union(Iterable)` and
`or(Iterable)` as an alias. We already have `minus(Iterable)`,
`plus(Iterable)`, and `intersect(Iterable)`.
Much like we know that subtraction, power, division aren't symmetric and the
order of the parameters is intrinsic to the problem domain, I see it that for
the set-specific operators, the order is important and the iterable can be the
second argument and have a different type to the first. Operations with a
custom comparator aren't going to be symmetric behavior-wise in general, I
don't see it as a given that set operations must be symmetric type-wise.
> Add '|', '&', and '^' operators to Set and SortedSet
>
>
> Key: GROOVY-11127
> URL: https://issues.apache.org/jira/browse/GROOVY-11127
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
>Reporter: Spencer Allain
>Assignee: Paul King
>Priority: Trivial
> Fix For: 5.x
>
>
> Many languages conventionally allow sets to use '|' as union, '&' as
> intersection, and '^' as symmetric difference operations on sets.
> This ticket is proposing adding these operations as DefaultGroovyMethods for
> Set and SortedSet such that the below tests should pass:
> {code:java}
> Set a = [1,2,3,4] as Set
> Set b = [3,4,5,6] as Set
> assert (a | b) == [1,2,3,4,5,6] as Set
> assert (a & b) == [3,4] as Set
> assert (a ^ b) == [1,2,5,6] as Set
> Set d = ['a', 'B', 'c'] as Set
> Set e = ['A', 'b', 'D'] as Set
> assert d.and(e, String.CASE_INSENSITIVE_ORDER) == ['a', 'B'] as Set
> assert d.and(e, Comparator.naturalOrder()) == [] as Set
> assert d.xor(e, String.CASE_INSENSITIVE_ORDER) == ['c', 'D'] as Set
> assert d.xor(e, Comparator.naturalOrder()) == ['a', 'B', 'c', 'A', 'b', 'D']
> as Set
> {code}
> A [Pull Request|https://github.com/apache/groovy/pull/1915] exists that
> implements the desired additions for the 5.x groovy branch (master), but it
> should be fairly easy to make the functionality available in 4.x if desired.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [groovy] paulk-asert commented on pull request #1915: GROOVY-11127: Set operator extension methods
paulk-asert commented on PR #1915: URL: https://github.com/apache/groovy/pull/1915#issuecomment-1644012383 I am still keen to keep Iterable as the second argument (option 3). It makes most sense with how the DGM methods and the Java APIs are designed. I agree that non-symmetry can potentially lead to confusion but I don't see that applies here. If we have explained that "union" is like a Set-specific "plus", then I don't see why folks might expect it to work for Collections. If I have `Set wordsSeen` and `List nextSentence`, then doing `wordsSeen |= nextSentence` makes perfect sense just like we currently would allow `wordsSeen += nextSentence`. Folks dealing with large datasets aren't going to want the extra time or memory hit of creating the superfluous set. I don't see folks suddenly expecting `nextSentence |= wordsSeen` to be available when we have explained this as a set operation. Or, to say it a different way, Set already has `containsAll(Collection)`, `addAll(Collection)`,` retainAll(Collection)`, `removeAll(Collection)`, as well as the Collection constructor, e.g. in HashSet. I see no problem with having `union(Collection)` or in our case we'd have `union(Iterable)` and `or(Iterable)` as an alias. We already have `minus(Iterable)`, `plus(Iterable)`, and `intersect(Iterable)`. Much like we know that subtraction, power, division aren't symmetric and the order of the parameters is intrinsic to the problem domain, I see it that for the set-specific operators, the order is important and the iterable can be the second argument and have a different type to the first. Operations with a custom comparator aren't going to be symmetric behavior-wise in general, I don't see it as a given that set operations must be symmetric type-wise. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@groovy.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-11126:
-
Fix Version/s: 4.0.14
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Assignee: Eric Milles
>Priority: Critical
> Fix For: 4.0.14
>
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-11126.
--
Resolution: Fixed
https://github.com/apache/groovy/commit/44897fe49894591079d8d3b99f6ade55e7d4a05f
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Assignee: Eric Milles
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745063#comment-17745063
]
Eric Milles commented on GROOVY-11126:
--
The indy guards are skipped if no arguments (aka color) are null and all
parameter types (aka String) are final. So there is no guard added for a
swtitch from String to null.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Assignee: Eric Milles
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-11126:
Assignee: Eric Milles
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Assignee: Eric Milles
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745059#comment-17745059
]
Jochen Theodorou commented on GROOVY-11126:
---
[~emilles]Those dgm methods are just basically proxies for calls to methods in
DefaultGroovyMethods and such. They exist only for groovy itself. And have no
logic for safe navigation. I wonder if we really still need those actually.
They had their use in the old callsite caching, but in Groovy 4? Anyway, it is
very good you found an example!
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745035#comment-17745035
]
Eric Milles edited comment on GROOVY-11126 at 7/20/23 11:49 AM:
Do we have any idea what "org.codehaus.groovy.runtime.dgm$1323" looks like?
I'm wondering if the switch to "dgm$1323.doInvokeMethod(color)" has the safe
check in the wrong position.
This script throws NPE as described:
{code:groovy}
def test(String string) {
string?.size()
}
1.times {
test('1')
test('')
}
test()
{code}
was (Author: emilles):
Do we have any idea what "org.codehaus.groovy.runtime.dgm$1323" looks like?
I'm wondering if the switch to "dgm$1323.doInvokeMethod(color,new Object[0])"
has the safe check in the wrong position.
This script throws NPE as described:
{code:groovy}
def test(String string) {
string?.size()
}
1.times {
test('1')
test('')
}
test()
{code}
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745035#comment-17745035
]
Eric Milles edited comment on GROOVY-11126 at 7/20/23 11:36 AM:
Do we have any idea what "org.codehaus.groovy.runtime.dgm$1323" looks like?
I'm wondering if the switch to "dgm$1323.doInvokeMethod(color,new Object[0])"
has the safe check in the wrong position.
This script throws NPE as described:
{code:groovy}
def test(String string) {
string?.size()
}
1.times {
test('1')
test('')
}
test()
{code}
was (Author: emilles):
Do we have any idea what "org.codehaus.groovy.runtime.dgm$1323" looks like?
I'm wondering if the switch to "dgm$1323.doInvokeMethod(string,new Object[0])"
has the safe check in the wrong position.
This script throws NPE as described:
{code:groovy}
def test(String string) {
string?.size()
}
1.times {
test('1')
test('')
}
test()
{code}
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745035#comment-17745035
]
Eric Milles edited comment on GROOVY-11126 at 7/20/23 11:34 AM:
Do we have any idea what "org.codehaus.groovy.runtime.dgm$1323" looks like?
I'm wondering if the switch to "dgm$1323.doInvokeMethod(string,new Object[0])"
has the safe check in the wrong position.
This script throws NPE as described:
{code:groovy}
def test(String string) {
string?.size()
}
1.times {
test('1')
test('')
}
test()
{code}
was (Author: emilles):
Do we have any idea what "org.codehaus.groovy.runtime.dgm$1323" looks like?
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745035#comment-17745035
]
Eric Milles commented on GROOVY-11126:
--
Do we have any idea what "org.codehaus.groovy.runtime.dgm$1323" looks like?
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744972#comment-17744972
]
Jochen Theodorou commented on GROOVY-11126:
---
[~daniel_sun]it is not a spread call, it is a safeNavigation call. For me
things point to the caching, but why exactly no idea. I could imagine that
there is a point where the SoftReference is cleared or the cache emptied. And
then somehow the safe navigation flag is lost I have found no pointers in
the code that would back this though. I guess we would need to experiment where
we manually clear the cache or the reference to try to reproduce the problem.
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744898#comment-17744898
]
Daniel Sun commented on GROOVY-11126:
-
We can bypass the PIC for safe invocation, but I still can not understand why
NPE will happen in your code sometimes... Could you reproduce the issue?
See also,
https://github.com/apache/groovy/blob/732a204a6439bfadece45b222758c1138cce3292/src/main/java/org/codehaus/groovy/vmplugin/v8/IndyInterface.java#L329
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
