[jira] [Commented] (GROOVY-9305) Unable to load class JaxbExtensions
[
https://issues.apache.org/jira/browse/GROOVY-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16982109#comment-16982109
]
Paul King commented on GROOVY-9305:
---
Copying my answer from SO:
{{--add-modules java.xml.bind}} is not appropriate for Java 11 since it has
deleted that module. I would use {{set DEBUG=true}} and see what is actually
happening on your machine. {{startGroovy.bat}} (called by
{{groovyConsole.bat}}) should be adding {{-Dgroovy.jaxb=jaxb}} to {{JAVA_OPTS}}
which is then used by {{groovy-starter.conf}}. You could check you haven't
created a custom version of that conf file on your classpath.
> Unable to load class JaxbExtensions
> ---
>
> Key: GROOVY-9305
> URL: https://issues.apache.org/jira/browse/GROOVY-9305
> Project: Groovy
> Issue Type: Bug
> Components: Groovy Console
>Affects Versions: 3.0.0-beta-3
> Environment: Training
>Reporter: Rod Hamann
>Priority: Minor
>
> Honestly, I am learning Groovy and I am getting this will taking the online
> course.
> Windows 10
> Java Folder : *C:\Program Files\Java\jdk-13.0.1*
> +Env Vars:+
> * *CLASSPATH* = *C:\Program Files\Java\jdk-13.0.1\lib*
> * *JAVA_HOME* = *C:\Program Files\Java\jdk-13.0.1*
> * Path env has "*C:\Program Files\Java\jdk-13.0.1\bin*" in it
>
> +Console:+
> groovy> println "X"
>
> Exception thrown
> java.lang.NoClassDefFoundError: Unable to load class
> org.apache.groovy.jaxb.extensions.JaxbExtensions due to missing dependency
> javax/xml/bind/JAXBContext
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9305) Unable to load class JaxbExtensions
[ https://issues.apache.org/jira/browse/GROOVY-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16982077#comment-16982077 ] Kenneth W DeLong commented on GROOVY-9305: -- There's also a StackOverflow about this [https://stackoverflow.com/questions/58680117/executing-scripts-in-groovyconsole-with-java-11-generates-missing-jaxb-dependenc/59042911] > Unable to load class JaxbExtensions > --- > > Key: GROOVY-9305 > URL: https://issues.apache.org/jira/browse/GROOVY-9305 > Project: Groovy > Issue Type: Bug > Components: Groovy Console >Affects Versions: 3.0.0-beta-3 > Environment: Training >Reporter: Rod Hamann >Priority: Minor > > Honestly, I am learning Groovy and I am getting this will taking the online > course. > Windows 10 > Java Folder : *C:\Program Files\Java\jdk-13.0.1* > +Env Vars:+ > * *CLASSPATH* = *C:\Program Files\Java\jdk-13.0.1\lib* > * *JAVA_HOME* = *C:\Program Files\Java\jdk-13.0.1* > * Path env has "*C:\Program Files\Java\jdk-13.0.1\bin*" in it > > +Console:+ > groovy> println "X" > > Exception thrown > java.lang.NoClassDefFoundError: Unable to load class > org.apache.groovy.jaxb.extensions.JaxbExtensions due to missing dependency > javax/xml/bind/JAXBContext > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9305) Unable to load class JaxbExtensions
[ https://issues.apache.org/jira/browse/GROOVY-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981995#comment-16981995 ] Kenneth W DeLong edited comment on GROOVY-9305 at 11/26/19 2:23 AM: I have installed Java 11 and Groovy 2.5.8: groovy -version WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v7.Java7$1 ([file:/C:/Users/Ken/java/groovy-2.5.8/lib/groovy-2.5.8.jar|file:///C:/Users/Ken/java/groovy-2.5.8/lib/groovy-2.5.8.jar]) to constructor java.lang.invoke.MethodHandles$Lookup(java.lang.Class,int) WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.vmplugin.v7.Java7$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release Groovy Version: 2.5.8 JVM: 11.0.5 Vendor: Azul Systems, Inc. OS: Windows 10 When I type "groovyconsole" at the command line (Windows 10) and run a script like "println 'hi'", I get the JAXB exception noted above. Underneath GROOVY_HOME/lib there are JAXB libraries, and the groovy-starter.conf file in the conf directory appears to put them on the classpath, so I don't know why it's broken. was (Author: kenwdelong): I have installed Java 11 and Groovy 2.5.8: groovy -version WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v7.Java7$1 (file:/C:/Users/Ken/java/groovy-2.5.8/lib/groovy-2.5.8.jar) to constructor java.lang.invoke.MethodHandles$Lookup(java.lang.Class,int) WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.vmplugin.v7.Java7$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release Groovy Version: 2.5.8 JVM: 11.0.5 Vendor: Azul Systems, Inc. OS: Windows 10 When I type "groovyconsole" at the command line (Windows 10) I get the JAXB exception noted above. Underneath GROOVY_HOME/lib there are JAXB libraries, and the groovy-starter.conf file in the conf directory appears to put them on the classpath, so I don't know why it's broken. > Unable to load class JaxbExtensions > --- > > Key: GROOVY-9305 > URL: https://issues.apache.org/jira/browse/GROOVY-9305 > Project: Groovy > Issue Type: Bug > Components: Groovy Console >Affects Versions: 3.0.0-beta-3 > Environment: Training >Reporter: Rod Hamann >Priority: Minor > > Honestly, I am learning Groovy and I am getting this will taking the online > course. > Windows 10 > Java Folder : *C:\Program Files\Java\jdk-13.0.1* > +Env Vars:+ > * *CLASSPATH* = *C:\Program Files\Java\jdk-13.0.1\lib* > * *JAVA_HOME* = *C:\Program Files\Java\jdk-13.0.1* > * Path env has "*C:\Program Files\Java\jdk-13.0.1\bin*" in it > > +Console:+ > groovy> println "X" > > Exception thrown > java.lang.NoClassDefFoundError: Unable to load class > org.apache.groovy.jaxb.extensions.JaxbExtensions due to missing dependency > javax/xml/bind/JAXBContext > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GROOVY-8527) Enhance import aliasing to an alias with a package name
[
https://issues.apache.org/jira/browse/GROOVY-8527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8527.
-
Resolution: Won't Fix
> Enhance import aliasing to an alias with a package name
> ---
>
> Key: GROOVY-8527
> URL: https://issues.apache.org/jira/browse/GROOVY-8527
> Project: Groovy
> Issue Type: New Feature
>Reporter: Paul King
>Priority: Major
>
> Currently at the syntax level you can do:
> {code:java}
> import java.lang.String as MyString
> {code}
> but the grammar prohibits:
> {code:java}
> import java.lang.String as some.package.MyString
> {code}
> It is already possible to include a dot within the name via the api:
> {code}
> import org.codehaus.groovy.control.CompilerConfiguration
> import org.codehaus.groovy.control.customizers.ImportCustomizer
> def configuration = new CompilerConfiguration()
> def imports = new ImportCustomizer()
> imports.addImport('foo.bar.LegacyDate', 'java.util.Date')
> configuration.addCompilationCustomizers(imports)
> def shell = new GroovyShell(configuration)
> shell.evaluate('println new foo.bar.LegacyDate()')
> {code}
> This usage is not currently common however and perhaps parts of the code base
> don't expect it. We should include some further tests and also make sure
> there aren't any security implications if someone started using a
> java.lang.Object alias or something similar.
> We should also consider adding a DEFAULT_ALIASES similar to
> {{ResolveVisitor#DEFAULT_IMPORTS}} and consider a mechanism for extending the
> list (potentially for both).
> My use case is around JDK9+ modules. We might move the package for, e.g.
> groovy.util.XmlSlurper to something like groovy.xml.parsers.XmlSlurper (or
> whatever) but we might like to retain (perhaps with a commandline switch) the
> ability to compile source code still using the old package name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-8527) Enhance import aliasing to an alias with a package name
[
https://issues.apache.org/jira/browse/GROOVY-8527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16982052#comment-16982052
]
Paul King commented on GROOVY-8527:
---
Since we didn't need this for our Groovy 3 JDK9+ package renaming requirements,
I plan to close this issue. As mentioned, it is available via the API and we
can always re-open if needed in the future.
> Enhance import aliasing to an alias with a package name
> ---
>
> Key: GROOVY-8527
> URL: https://issues.apache.org/jira/browse/GROOVY-8527
> Project: Groovy
> Issue Type: New Feature
>Reporter: Paul King
>Priority: Major
>
> Currently at the syntax level you can do:
> {code:java}
> import java.lang.String as MyString
> {code}
> but the grammar prohibits:
> {code:java}
> import java.lang.String as some.package.MyString
> {code}
> It is already possible to include a dot within the name via the api:
> {code}
> import org.codehaus.groovy.control.CompilerConfiguration
> import org.codehaus.groovy.control.customizers.ImportCustomizer
> def configuration = new CompilerConfiguration()
> def imports = new ImportCustomizer()
> imports.addImport('foo.bar.LegacyDate', 'java.util.Date')
> configuration.addCompilationCustomizers(imports)
> def shell = new GroovyShell(configuration)
> shell.evaluate('println new foo.bar.LegacyDate()')
> {code}
> This usage is not currently common however and perhaps parts of the code base
> don't expect it. We should include some further tests and also make sure
> there aren't any security implications if someone started using a
> java.lang.Object alias or something similar.
> We should also consider adding a DEFAULT_ALIASES similar to
> {{ResolveVisitor#DEFAULT_IMPORTS}} and consider a mechanism for extending the
> list (potentially for both).
> My use case is around JDK9+ modules. We might move the package for, e.g.
> groovy.util.XmlSlurper to something like groovy.xml.parsers.XmlSlurper (or
> whatever) but we might like to retain (perhaps with a commandline switch) the
> ability to compile source code still using the old package name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9305) Unable to load class JaxbExtensions
[ https://issues.apache.org/jira/browse/GROOVY-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981995#comment-16981995 ] Kenneth W DeLong commented on GROOVY-9305: -- I have installed Java 11 and Groovy 2.5.8: groovy -version WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v7.Java7$1 (file:/C:/Users/Ken/java/groovy-2.5.8/lib/groovy-2.5.8.jar) to constructor java.lang.invoke.MethodHandles$Lookup(java.lang.Class,int) WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.vmplugin.v7.Java7$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release Groovy Version: 2.5.8 JVM: 11.0.5 Vendor: Azul Systems, Inc. OS: Windows 10 When I type "groovyconsole" at the command line (Windows 10) I get the JAXB exception noted above. Underneath GROOVY_HOME/lib there are JAXB libraries, and the groovy-starter.conf file in the conf directory appears to put them on the classpath, so I don't know why it's broken. > Unable to load class JaxbExtensions > --- > > Key: GROOVY-9305 > URL: https://issues.apache.org/jira/browse/GROOVY-9305 > Project: Groovy > Issue Type: Bug > Components: Groovy Console >Affects Versions: 3.0.0-beta-3 > Environment: Training >Reporter: Rod Hamann >Priority: Minor > > Honestly, I am learning Groovy and I am getting this will taking the online > course. > Windows 10 > Java Folder : *C:\Program Files\Java\jdk-13.0.1* > +Env Vars:+ > * *CLASSPATH* = *C:\Program Files\Java\jdk-13.0.1\lib* > * *JAVA_HOME* = *C:\Program Files\Java\jdk-13.0.1* > * Path env has "*C:\Program Files\Java\jdk-13.0.1\bin*" in it > > +Console:+ > groovy> println "X" > > Exception thrown > java.lang.NoClassDefFoundError: Unable to load class > org.apache.groovy.jaxb.extensions.JaxbExtensions due to missing dependency > javax/xml/bind/JAXBContext > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GROOVY-8650) New line between prefix operator and operand
[
https://issues.apache.org/jira/browse/GROOVY-8650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun reassigned GROOVY-8650:
--
Assignee: (was: Daniel Sun)
> New line between prefix operator and operand
>
>
> Key: GROOVY-8650
> URL: https://issues.apache.org/jira/browse/GROOVY-8650
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr4
>Affects Versions: 3.0.0-alpha-2
>Reporter: Daniil Ovchinnikov
>Priority: Major
>
> The following code is parsed properly in previous versions, but fails in 3.0:
> {code:java}
> def c = --
> 1
> println c // 0{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-8642) New lines in qualified name cause errors
[
https://issues.apache.org/jira/browse/GROOVY-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun reassigned GROOVY-8642:
--
Assignee: (was: Daniel Sun)
> New lines in qualified name cause errors
>
>
> Key: GROOVY-8642
> URL: https://issues.apache.org/jira/browse/GROOVY-8642
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr4
>Affects Versions: 3.0.0-alpha-2
>Reporter: Daniil Ovchinnikov
>Priority: Major
>
> The following code is parsed properly in previous versions, but fails in 3.0:
> {code:java}
> import java. // Unexpected input: '\n'; Expecting '*' @ line 1, column 13.
> lang.
> Object
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-8212) coerce GString to String when used as Map key
[
https://issues.apache.org/jira/browse/GROOVY-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun reassigned GROOVY-8212:
--
Assignee: (was: Daniel Sun)
> coerce GString to String when used as Map key
> -
>
> Key: GROOVY-8212
> URL: https://issues.apache.org/jira/browse/GROOVY-8212
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.10
>Reporter: Christopher Smith
>Priority: Minor
>
> When a GString is used as the key for a bracket-style map get (in this case,
> from an overly verbose CSV file):
> {code}
> row["$param URL"]
> {code}
> the {{GStringImpl}} object is passed directly to {{Map#get(Object)}}. Since
> GStrings are never equal to Strings, this means that the get will always
> return null.
> If {{row}} is explicitly declared as a {{Map}}, however, Groovy
> ought to identify the intended behavior (using a templated string as a map
> key) and use the string value instead.
> The current behavior is a problem because even in static compilation mode,
> where the generic key bound is known, Groovy does not complain about the use
> of a GString here (because it normally treats GStrings as valid for
> {{String}} targets?), but the lookup will fail at runtime.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-8606) Provide friendly error message for invalid lambda body
[
https://issues.apache.org/jira/browse/GROOVY-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun reassigned GROOVY-8606:
--
Assignee: (was: Daniel Sun)
> Provide friendly error message for invalid lambda body
> --
>
> Key: GROOVY-8606
> URL: https://issues.apache.org/jira/browse/GROOVY-8606
> Project: Groovy
> Issue Type: Improvement
> Components: parser-antlr4
>Reporter: Daniel Sun
>Priority: Major
>
> We should provide friendly error message like "Statements should be wrapped
> in a block, e.g. () -> { some statements here }", e.g.
> Script1.groovy: 1: Statements should be wrapped in a block, e.g. () -> { some
> statements here } @ line 1, column 15.
>def a = () -> assert 1 == 1
> ^
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-8553) Parrot Parser: parse fails for typecast of slashy string
[
https://issues.apache.org/jira/browse/GROOVY-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun reassigned GROOVY-8553:
--
Assignee: (was: Daniel Sun)
> Parrot Parser: parse fails for typecast of slashy string
>
>
> Key: GROOVY-8553
> URL: https://issues.apache.org/jira/browse/GROOVY-8553
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr4
>Reporter: Eric Milles
>Priority: Minor
>
> This single-line script fails to parse:
> {code:groovy}
> def p = (java.util.regex.Pattern) /abc/
> {code}
> This one succeeds:
> {code:groovy}
> def p = (java.util.regex.Pattern) "abc"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-8992) [GEP]Polish the generics type syntax for closure
[
https://issues.apache.org/jira/browse/GROOVY-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun reassigned GROOVY-8992:
--
Assignee: (was: Daniel Sun)
> [GEP]Polish the generics type syntax for closure
>
>
> Key: GROOVY-8992
> URL: https://issues.apache.org/jira/browse/GROOVY-8992
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Priority: Major
>
> h2. 1. Background
> Currently the syntax specifying the generics type for closure is quite
> verbose and not type safe, e.g.
> {code:java}
> @ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure
> closure
> {code}
> h2. 2. Solutions
> ① × I propose to make the above code groovier, but the proposed "arrow
> syntax making it hard to read, in particular when the argument types have
> generics themselves" reminded by [~melix], e.g.
> {code:java}
> Closure V>
> {code}
> ② √ Suggestions of [~blackdrag] are much groovier for all cases:
> {code:java}
> Closure
> {code}
> ③ √ In the meanwhile, [~blackdrag] proposed other variants of the generics
> type syntax for closure to handle "polymorphic closures (aka closures which
> accept different kind of arguments)" reminded by [~melix]
> {code:java}
> Closure<():R1; (X):R2; (Y, Z):R3>
> {code}
> ④ ? [~emge] proposed the simplified version of ③.
> {code:java}
> Closure
> {code}
> h2. 3. Benefits
> ① The new syntax of generics type for closure is much more concise and
> readable:
> {code:java}
> Closure
> {code}
> {code:java}
> Closure // qualified name is not necessary if using imports
> {code}
> *VS*
> {code:java}
> @ClosureParams(value=SimpleType.class, options="groovy.sql.Sql") Closure
> {code}
> ② Type checking can be completed in the compilation time, so we can find
> errors in time, e.g. {{@ClosureParams(... options="groovy.sql.SqlAbc")}} of
> annotation specifies the type with string literal, but the type does not
> exist, so we can not the error in the compilation time. On the contrast,
> {{Closure}} can make compiler help us find type errors
> in the compilation time.
> ③ Better IDE support because of using the types instead of string literals
> for types
> h2. 4. Rationale
> In order to keep "consistency between using annotations and a type-checking
> only feature" reminded by [~melix], I propose to transform the groovier code
> to the original code when compiling, e.g.
> {{Closure}}
> will be transformed to
> {{@ClosureParams(value=SimpleType.class, options="groovy.sql.Sql")
> Closure}}
> h2. 5. Discussions in the dev mailing list
> [http://groovy.329449.n5.nabble.com/About-polish-the-generics-type-syntax-for-closure-tt5756586.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-9041) Support native method reference and constructor reference (advanced cases)
[ https://issues.apache.org/jira/browse/GROOVY-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun reassigned GROOVY-9041: -- Assignee: (was: Daniel Sun) > Support native method reference and constructor reference (advanced cases) > -- > > Key: GROOVY-9041 > URL: https://issues.apache.org/jira/browse/GROOVY-9041 > Project: Groovy > Issue Type: Improvement >Reporter: Daniel Sun >Priority: Major > > ||SUB TASK||PRIORITY||COMMENTS||COMPLETED|| > |CALLABLE|MIDDLE|N/A|TODO| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GROOVY-8998) [GEP]Concatenative Method Calls
[
https://issues.apache.org/jira/browse/GROOVY-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun reassigned GROOVY-8998:
--
Assignee: (was: Daniel Sun)
> [GEP]Concatenative Method Calls
> ---
>
> Key: GROOVY-8998
> URL: https://issues.apache.org/jira/browse/GROOVY-8998
> Project: Groovy
> Issue Type: New Feature
>Reporter: Daniel Sun
>Priority: Major
>
> h1. *DRAFT*
> {code:java}
> // lots of temp variable declarations and assignments
> def ar = a()
> def br = b(3, ar)
> def r = c(br, 2)
> // inline version of the above code, i.e. nested method calls
> def r =
> c(
> b(
> 3,
> a()
> ),
> 2
> )
> {code}
> {code:java}
> // leverage the power of DGM `with` to transform nested method calls to
> method call chain
> def r =
> a().with {
> b(3, it)
> }. with {
> c(it, 2)
> }
> {code}
> {code:java}
> // Introduce a new syntax to transform the above method call chain to
> concatenative method calls
> // `_` represents the result of previous part
> // `|>` is like a big arrow representing the direction of data flow
> // if the target is a variable, `|>` means assignment/declaration
> a() |> b(3, _) |> c(_, 2) |> (def r)
> {code}
> h2. More examples
> {code:java}
> // `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
> `*=`, etc.
> 6 / a() |> b(3, _) + 9 |> c(_, 2) * 5 |> (def r)
> // the above code is equal to
> def r =
> c(
> b(
> 3,
> 6 / a()
> ) + 9,
> 2
> ) * 5
> {code}
> {code:java}
> // passing multiple parameters
> a(1), 6 / a(2) |> b(_, 3, _) |> (def r)
> // the above code is equal to
> def r =
> b(
> a(1)
> 3,
> 6 / a(2)
> )
> {code}
> h2. discussion in the dev mailing list
>
> [http://groovy.329449.n5.nabble.com/GEP-Concatenative-Method-Calls-tt5747708.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-8683) CLONE - Cannot qualify path expression with soft keyword ("def" case)
[
https://issues.apache.org/jira/browse/GROOVY-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun reassigned GROOVY-8683:
--
Assignee: (was: Daniel Sun)
> CLONE - Cannot qualify path expression with soft keyword ("def" case)
> -
>
> Key: GROOVY-8683
> URL: https://issues.apache.org/jira/browse/GROOVY-8683
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr4
>Affects Versions: 3.0.0-alpha-2
>Reporter: Daniil Ovchinnikov
>Priority: Major
>
> {{in.foo}} (and others) in valid path expression in Groovy < 3.0.
> The following code is parsed and run properly in previous versions, but fails
> in 3.0:
> {code}
> def delegate = new Object() {
> def getProperty(String name) {
> println name
> return this
> }
> }
> delegate.with {
> def.foo
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-9075) The exception message should be more clear when a GroovyObject's metaClass is wrong
[
https://issues.apache.org/jira/browse/GROOVY-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun reassigned GROOVY-9075:
--
Assignee: (was: Daniel Sun)
> The exception message should be more clear when a GroovyObject's metaClass is
> wrong
> ---
>
> Key: GROOVY-9075
> URL: https://issues.apache.org/jira/browse/GROOVY-9075
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.16, 3.0.0-alpha-4, 2.5.6
>Reporter: Xiaoguang Wang
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> If a GroovyObject's metaClass is overwritten by mistake, the accesses to the
> instance may cause an exception with unclear message.
>
> We have met the problem too many times and have spent a lot of time on
> debugging (and teaching everyone never to use `BeanUtils.copyProperties`, etc)
>
> If there is a try-catch (or some other check) in the runtime code and report
> this problem more clearly, it will save everyone's time to debug. Or, is
> there any better solution to this problem, eg: check the class type in
> `MetaClassImpl.setProperty`, `DefaultGroovyMethods.setMetaClass` ?
>
> {code:java}
> import groovy.transform.CompileStatic
> //@CompileStatic
> class C1 {
> int x
> }
> //@CompileStatic
> class C2 {
> int x
> }
> //@CompileStatic
> class TestGroovy {
> static void main(String[] args) {
> def c1 = new C1()
> def c2 = new C2()
> c1.metaClass = c2.metaClass //eg:
> org.springframework.beans.BeanUtils.copyProperties
> // or c1.setMetaClass(c2.getMetaClass())
> c1.x += 1 // crash here with unclear exception, but c1.setX() works
> }
> }
> {code}
>
> {code:java}
> /*
> without @CompileStatic
> Exception in thread "main" java.lang.IllegalArgumentException: object is not
> an instance of declaring class
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:498)
>at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
>at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
>at
> org.codehaus.groovy.runtime.metaclass.MethodMetaProperty$GetBeanMethodMetaProperty.getProperty(MethodMetaProperty.java:76)
>at
> org.codehaus.groovy.runtime.callsite.GetEffectivePogoPropertySite.getProperty(GetEffectivePogoPropertySite.java:85)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:299)
> with @CompileStatic
> Exception in thread "main" java.lang.IllegalArgumentException: object is not
> an instance of declaring class
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:498)
>at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
>at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
>at groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:2726)
>at groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:3785)
>at C1.setProperty(TestGroovy.groovy)
>at
> org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:213)
>at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:497)
> */
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-9304) [Parrot] bitwise or followed by closure on next line parsed as command expression
[
https://issues.apache.org/jira/browse/GROOVY-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun reassigned GROOVY-9304:
--
Assignee: (was: Daniel Sun)
> [Parrot] bitwise or followed by closure on next line parsed as command
> expression
> -
>
> Key: GROOVY-9304
> URL: https://issues.apache.org/jira/browse/GROOVY-9304
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr4
>Affects Versions: 3.x
>Reporter: Alexey Afanasiev
>Priority: Major
>
> This code:
> {code:java}
> a | b
> {it -> true} (){code}
> will be parsed at 2.5.5 as two independent expressions:
> {code:java}
> a | b
> { java.lang.Object it -> true}.call()
> {code}
> and will be parsed at 3.0.0-rc-1 as single expression:
> {code:java}
> a | this.b({ java.lang.Object it -> true }).call()
> {code}
> I believe this expression should be parsed same way in both versions.
> Spock depends on structure of ast for these kind of expressions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-9072) Avoid creating inner classes for simple native lambda expressions
[
https://issues.apache.org/jira/browse/GROOVY-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun reassigned GROOVY-9072:
--
Assignee: (was: Daniel Sun)
> Avoid creating inner classes for simple native lambda expressions
> -
>
> Key: GROOVY-9072
> URL: https://issues.apache.org/jira/browse/GROOVY-9072
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Priority: Major
>
> Groovy will create inner classes for each native lambda expression because
> native lambda expression is versatile and mimic the behavior of closure as
> possible as it can.
> As a result, the performance of native lambda expression will be a bit less
> efficient than Java lambda expression.
> We can generate almost same bytecode for the simple native lambda
> expressions, e.g. no re-assignment of shared variables in the lambda
> expression body, no nested lambda expression.
> The improvement can cover most of usual cases, e.g.
> {code:java}
> Stream.of(1, -2, 3).map(e -> Math.abs(e))
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GROOVY-9315) Bump bytecode version to 1.8
[
https://issues.apache.org/jira/browse/GROOVY-9315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun closed GROOVY-9315.
--
Fix Version/s: (was: 3.0.0-rc-2)
Resolution: Won't Fix
> Bump bytecode version to 1.8
>
>
> Key: GROOVY-9315
> URL: https://issues.apache.org/jira/browse/GROOVY-9315
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Groovy 3.0.0 requires Java 8+ and supports Java8 language features, so it's
> better to use its relevant class file version, i.e. 1.8
> In the old codebase, we can not manage the bytecode version well, for
> example, we use many bytecode versions to generate bytecode, some very old
> bytecode versions like {{1.3}} are still used.
> What I propose to do is manage the default bytecode code version in a place,
> same for its relevant compute mode and parse mode. If we want to change them,
> just modify only one place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GROOVY-9319) Improve the performance of transforming meta methods
[ https://issues.apache.org/jira/browse/GROOVY-9319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun closed GROOVY-9319. -- Fix Version/s: (was: 3.0.0-rc-2) Resolution: Won't Fix > Improve the performance of transforming meta methods > > > Key: GROOVY-9319 > URL: https://issues.apache.org/jira/browse/GROOVY-9319 > Project: Groovy > Issue Type: Improvement >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Transforming meta methods is time-consuming. It's better to avoid > transforming meta method for each meta method repeatedly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [groovy] danielsun1106 closed pull request #1103: GROOVY-9315: Bump bytecode version to 1.8
danielsun1106 closed pull request #1103: GROOVY-9315: Bump bytecode version to 1.8 URL: https://github.com/apache/groovy/pull/1103 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (GROOVY-9315) Bump bytecode version to 1.8
[
https://issues.apache.org/jira/browse/GROOVY-9315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981986#comment-16981986
]
Daniel Sun commented on GROOVY-9315:
bq. Why do ClassReader and ClassWriter need different values?
FYI.
https://javadoc.io/doc/org.ow2.asm/asm/latest/org/objectweb/asm/ClassReader.html
parsingOptions - the options to use to parse this class. One or more of
SKIP_CODE, SKIP_DEBUG, SKIP_FRAMES or EXPAND_FRAMES.
https://javadoc.io/doc/org.ow2.asm/asm/latest/org/objectweb/asm/ClassWriter.html
Please read javadoc carefully before reviewing.
> Bump bytecode version to 1.8
>
>
> Key: GROOVY-9315
> URL: https://issues.apache.org/jira/browse/GROOVY-9315
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-rc-2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Groovy 3.0.0 requires Java 8+ and supports Java8 language features, so it's
> better to use its relevant class file version, i.e. 1.8
> In the old codebase, we can not manage the bytecode version well, for
> example, we use many bytecode versions to generate bytecode, some very old
> bytecode versions like {{1.3}} are still used.
> What I propose to do is manage the default bytecode code version in a place,
> same for its relevant compute mode and parse mode. If we want to change them,
> just modify only one place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] danielsun1106 closed pull request #1104: GROOVY-9319: Improve the performance of transforming meta methods
danielsun1106 closed pull request #1104: GROOVY-9319: Improve the performance of transforming meta methods URL: https://github.com/apache/groovy/pull/1104 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (GROOVY-8762) Invalid this reference in nested class
[
https://issues.apache.org/jira/browse/GROOVY-8762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-8762.
-
Fix Version/s: 4.x
Resolution: Fixed
> Invalid this reference in nested class
> --
>
> Key: GROOVY-8762
> URL: https://issues.apache.org/jira/browse/GROOVY-8762
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.15, 2.5.1
>Reporter: paolo di tommaso
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.x
>
>
> The following snippet throws an exception when trying to initialise the `y`
> attribute
> {code:java}
> class Foo {
> static class Bar extends Closure {
> private int x
> private int y
> Bar(int a) {
> super(null, null);
> x = a
> this.y = a
> }
>
> public int getMaximumNumberOfParameters() {
> throw new UnsupportedOperationException()
> }
> public Class[] getParameterTypes() {
> throw new UnsupportedOperationException()
> }
> public Object call(final Object... args) {
> throw new UnsupportedOperationException()
> }
> public Object call(final Object arguments) {
> throw new UnsupportedOperationException()
> }
> public Object call() {
> throw new UnsupportedOperationException()
> }
> }
> def doSomething() {
> new Bar(1)
> }
> }
> assert new Foo().doSomething()
> {code}
> Reported error:
> {code}
> java.lang.NullPointerException
> at Foo$Bar.(ConsoleScript8:12)
> at Foo.doSomething(ConsoleScript8:37)
> at Foo$doSomething.call(Unknown Source)
> at ConsoleScript8.run(ConsoleScript8:42)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-8762) Invalid this reference in nested class
[
https://issues.apache.org/jira/browse/GROOVY-8762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-8762:
---
Assignee: Eric Milles
> Invalid this reference in nested class
> --
>
> Key: GROOVY-8762
> URL: https://issues.apache.org/jira/browse/GROOVY-8762
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.15, 2.5.1
>Reporter: paolo di tommaso
>Assignee: Eric Milles
>Priority: Major
>
> The following snippet throws an exception when trying to initialise the `y`
> attribute
> {code:java}
> class Foo {
> static class Bar extends Closure {
> private int x
> private int y
> Bar(int a) {
> super(null, null);
> x = a
> this.y = a
> }
>
> public int getMaximumNumberOfParameters() {
> throw new UnsupportedOperationException()
> }
> public Class[] getParameterTypes() {
> throw new UnsupportedOperationException()
> }
> public Object call(final Object... args) {
> throw new UnsupportedOperationException()
> }
> public Object call(final Object arguments) {
> throw new UnsupportedOperationException()
> }
> public Object call() {
> throw new UnsupportedOperationException()
> }
> }
> def doSomething() {
> new Bar(1)
> }
> }
> assert new Foo().doSomething()
> {code}
> Reported error:
> {code}
> java.lang.NullPointerException
> at Foo$Bar.(ConsoleScript8:12)
> at Foo.doSomething(ConsoleScript8:37)
> at Foo$doSomething.call(Unknown Source)
> at ConsoleScript8.run(ConsoleScript8:42)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-8762) Invalid this reference in nested class
[
https://issues.apache.org/jira/browse/GROOVY-8762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981960#comment-16981960
]
Eric Milles commented on GROOVY-8762:
-
Because the inner class Bar extends Closure, WriterController thinks the
property expression "this.y" occurs within a closure and so writes out a Groovy
dynamic property access sequence.
{code:java}
public boolean isInClosure() {
return classNode.getOuterClass() != null
&& classNode.getSuperClass() == ClassHelper.CLOSURE_TYPE;
}
public boolean isInClosureConstructor() {
return constructorNode != null
&& classNode.getOuterClass() != null
&& classNode.getSuperClass() == ClassHelper.CLOSURE_TYPE;
}
{code}
> Invalid this reference in nested class
> --
>
> Key: GROOVY-8762
> URL: https://issues.apache.org/jira/browse/GROOVY-8762
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.15, 2.5.1
>Reporter: paolo di tommaso
>Priority: Major
>
> The following snippet throws an exception when trying to initialise the `y`
> attribute
> {code:java}
> class Foo {
> static class Bar extends Closure {
> private int x
> private int y
> Bar(int a) {
> super(null, null);
> x = a
> this.y = a
> }
>
> public int getMaximumNumberOfParameters() {
> throw new UnsupportedOperationException()
> }
> public Class[] getParameterTypes() {
> throw new UnsupportedOperationException()
> }
> public Object call(final Object... args) {
> throw new UnsupportedOperationException()
> }
> public Object call(final Object arguments) {
> throw new UnsupportedOperationException()
> }
> public Object call() {
> throw new UnsupportedOperationException()
> }
> }
> def doSomething() {
> new Bar(1)
> }
> }
> assert new Foo().doSomething()
> {code}
> Reported error:
> {code}
> java.lang.NullPointerException
> at Foo$Bar.(ConsoleScript8:12)
> at Foo.doSomething(ConsoleScript8:37)
> at Foo$doSomething.call(Unknown Source)
> at ConsoleScript8.run(ConsoleScript8:42)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-8693) Calling indirect default interface methods fails both dynamic/static compiled
[
https://issues.apache.org/jira/browse/GROOVY-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-8693:
---
Assignee: (was: Eric Milles)
> Calling indirect default interface methods fails both dynamic/static compiled
> -
>
> Key: GROOVY-8693
> URL: https://issues.apache.org/jira/browse/GROOVY-8693
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Christoph Frick
>Priority: Major
>
> Given _ Intr <|- Impl <| SubImpl_ where _Intr_ is an Java8
> interface with a default implementation, running _SubImpl_ fails both with
> _CompileDynamic:_
> {noformat}
> Exception in thread "main" groovy.lang.MissingMethodException: No signature
> of method: sut.SubImpl.doSomething() is applicable for argument types: ()
> values: []
> Possible solutions: doSomething(), toString(), toString()
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:72)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:148)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0(ScriptBytecodeAdapter.java:166)
> at sut.SubImpl.doSomething(SubImpl.groovy:6)
> at sut.Intr$doSomething.call(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
> at sut.Main.main(Main.groovy:8)
> {noformat}
> and -_Static_.
> {noformat}
> Exception in thread "main" java.lang.VerifyError: Bad invokespecial
> instruction: interface method reference is in an indirect superinterface.
> Exception Details:
> Location:
> sut/SubImpl.doSomething()V @1: invokespecial
> Reason:
> Error exists in the bytecode
> Bytecode:
> 0x000: 2ab7 0014 0157 2a12 16b8 001c 0157 b1
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
> at java.lang.Class.getDeclaredConstructors(Class.java:2020)
> at org.codehaus.groovy.reflection.CachedClass$2$1.run(CachedClass.java:88)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:86)
> at
> org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:81)
> at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:50)
> at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:37)
> at
> org.codehaus.groovy.reflection.CachedClass.getConstructors(CachedClass.java:311)
> at groovy.lang.MetaClassImpl.(MetaClassImpl.java:218)
> at groovy.lang.MetaClassImpl.(MetaClassImpl.java:228)
> at
> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createNormalMetaClass(MetaClassRegistry.java:171)
> at
> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomLookup(MetaClassRegistry.java:161)
> at
> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.create(MetaClassRegistry.java:144)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:288)
> at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:331)
> at
> org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass(MetaClassRegistryImpl.java:270)
> at
> org.codehaus.groovy.runtime.InvokerHelper.getMetaClass(InvokerHelper.java:976)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallConstructorSite(CallSiteArray.java:86)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:238)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:242)
> at sut.Main.main(Main.groovy:8)
> {noformat}
> See a full example here:
> https://github.com/christoph-frick/groovy-inheritance-vs-default-interface-method
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-8283) Field shadowing not considered in STC
[
https://issues.apache.org/jira/browse/GROOVY-8283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-8283:
---
Assignee: (was: Eric Milles)
> Field shadowing not considered in STC
> -
>
> Key: GROOVY-8283
> URL: https://issues.apache.org/jira/browse/GROOVY-8283
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.12
>Reporter: Daniil Ovchinnikov
>Priority: Major
>
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic class A {}
> @CompileStatic class B {}
> @CompileStatic class Parent {
> protected A ff = new A()
> A getFf() { ff }
> }
> @CompileStatic class Child extends Parent {
> protected B ff = new B()
> }
> @CompileStatic class Usage extends Child {
> def test() {
> println ff// A@id
> println getFf() // A@id
> println this.@ff // B@id
> }
> def test2() {
> I.wantsB(ff)//
> ScriptBytecodeAdapter.castToType(((Usage)this).getFf(), B.class)) is
> generated (wrong)
> I.wantsB(getFf()) // [STC] - Cannot find matching method I#wantsB(A)
> I.wantsB(this.@ff) // [STC] - Cannot find matching method I#wantsB(A)
> (wrong)
> }
> }
> @CompileStatic class I {
> static void wantsB(B b) {}
> }
> new Usage().test()
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-9318) SecureASTCustomizer: add support for allowing or blocking entire package trees
[
https://issues.apache.org/jira/browse/GROOVY-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-9318.
-
Fix Version/s: 4.x
Resolution: Fixed
> SecureASTCustomizer: add support for allowing or blocking entire package trees
> --
>
> Key: GROOVY-9318
> URL: https://issues.apache.org/jira/browse/GROOVY-9318
> Project: Groovy
> Issue Type: New Feature
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
> Fix For: 4.x
>
>
> Consider the following:
> {code:groovy}
> CompilerConfiguration configuration = new CompilerConfiguration()
> SecureASTCustomizer customizer = new SecureASTCustomizer()
> configuration.addCompilationCustomizers(customizer)
> customizer.starImportsBlacklist = ['javax.**']
> def shell = new GroovyShell(configuration)
> shell.evaluate('''
> import javax.swing.Action
> Action act
> ''')
> {code}
> This should throw SecurityException since all of "javax" packages have been
> blocked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-9317) Value record missing for assert on field expression
[
https://issues.apache.org/jira/browse/GROOVY-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-9317.
-
Fix Version/s: 4.x
Resolution: Fixed
> Value record missing for assert on field expression
> ---
>
> Key: GROOVY-9317
> URL: https://issues.apache.org/jira/browse/GROOVY-9317
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
> Fix For: 4.x
>
>
> Consider the following:
> {code:groovy}
> class C {
> private Object field
> void test() {
> assert this.@field != null
> }
> }
> new C().test()
> {code}
> When executed, the assert is displayed as follows (value for field expression
> is missing):
> {code}
> assert this.@field != null
>|
>false
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-8648) Compound assignment to attribute fails with ASM error
[
https://issues.apache.org/jira/browse/GROOVY-8648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-8648.
-
Fix Version/s: 4.x
Resolution: Fixed
> Compound assignment to attribute fails with ASM error
> -
>
> Key: GROOVY-8648
> URL: https://issues.apache.org/jira/browse/GROOVY-8648
> Project: Groovy
> Issue Type: Bug
> Components: class generator
>Affects Versions: 2.4.14, 2.5.0
>Reporter: John Wagenleitner
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.x
>
>
> The following will fail with 2.4.14 and above.
> {code:java}
> class Account {
> int balance = 0
> void credit(int add) {
> this.@balance += add
> }
> }
> def acct = new Account()
> acct.credit(3)
> assert acct.balance == 3
> {code}
> Fails with the following in 2.5.0
> {code:java}
> groovy.lang.GroovyRuntimeException: ASM reporting processing error for
> Account#credit with signature void credit(int)
> {code}
> And this starting in 2.4.14
> {code:java}
> java.lang.VerifyError: (class: Account, method: credit signature: (I)V)
> Unable to pop operand off an empty stack
> {code}
> Possibly related to the fixes for GROOVY-8385 and the operand stack not being
> marked to handle the compound assignment operators.
> Issue reported on the [dev mailing
> list|https://mail-archives.apache.org/mod_mbox/groovy-dev/201806.mbox/%3Cef1093fea2ceab17b52fc021631b7b2b5e86ca4e.camel%40winder.org.uk%3E].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-8648) Compound assignment to attribute fails with ASM error
[
https://issues.apache.org/jira/browse/GROOVY-8648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-8648:
---
Assignee: Eric Milles
> Compound assignment to attribute fails with ASM error
> -
>
> Key: GROOVY-8648
> URL: https://issues.apache.org/jira/browse/GROOVY-8648
> Project: Groovy
> Issue Type: Bug
> Components: class generator
>Affects Versions: 2.4.14, 2.5.0
>Reporter: John Wagenleitner
>Assignee: Eric Milles
>Priority: Major
>
> The following will fail with 2.4.14 and above.
> {code:java}
> class Account {
> int balance = 0
> void credit(int add) {
> this.@balance += add
> }
> }
> def acct = new Account()
> acct.credit(3)
> assert acct.balance == 3
> {code}
> Fails with the following in 2.5.0
> {code:java}
> groovy.lang.GroovyRuntimeException: ASM reporting processing error for
> Account#credit with signature void credit(int)
> {code}
> And this starting in 2.4.14
> {code:java}
> java.lang.VerifyError: (class: Account, method: credit signature: (I)V)
> Unable to pop operand off an empty stack
> {code}
> Possibly related to the fixes for GROOVY-8385 and the operand stack not being
> marked to handle the compound assignment operators.
> Issue reported on the [dev mailing
> list|https://mail-archives.apache.org/mod_mbox/groovy-dev/201806.mbox/%3Cef1093fea2ceab17b52fc021631b7b2b5e86ca4e.camel%40winder.org.uk%3E].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9315) Bump bytecode version to 1.8
[
https://issues.apache.org/jira/browse/GROOVY-9315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981695#comment-16981695
]
Eric Milles commented on GROOVY-9315:
-
Here is how WriterController is handling it:
```java
bytecodeVersion = chooseBytecodeVersion(invokedynamic,
config.isPreviewFeatures(), config.getTargetBytecode());
private static int chooseBytecodeVersion(final boolean invokedynamic, final
boolean previewFeatures, final String targetBytecode) {
Integer bytecodeVersion =
CompilerConfiguration.JDK_TO_BYTECODE_VERSION_MAP.get(targetBytecode);
if (invokedynamic && bytecodeVersion < Opcodes.V1_8) {
return Opcodes.V1_8;
} else {
if (null != bytecodeVersion) {
return previewFeatures ? bytecodeVersion | Opcodes.V_PREVIEW :
bytecodeVersion;
}
}
throw new GroovyBugError("Bytecode version ["+targetBytecode+"] is not
supported by the compiler");
}
```
> Bump bytecode version to 1.8
>
>
> Key: GROOVY-9315
> URL: https://issues.apache.org/jira/browse/GROOVY-9315
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-rc-2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Groovy 3.0.0 requires Java 8+ and supports Java8 language features, so it's
> better to use its relevant class file version, i.e. 1.8
> In the old codebase, we can not manage the bytecode version well, for
> example, we use many bytecode versions to generate bytecode, some very old
> bytecode versions like {{1.3}} are still used.
> What I propose to do is manage the default bytecode code version in a place,
> same for its relevant compute mode and parse mode. If we want to change them,
> just modify only one place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9315) Bump bytecode version to 1.8
[
https://issues.apache.org/jira/browse/GROOVY-9315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981695#comment-16981695
]
Eric Milles edited comment on GROOVY-9315 at 11/25/19 4:48 PM:
---
{code:java}
bytecodeVersion = chooseBytecodeVersion(invokedynamic,
config.isPreviewFeatures(), config.getTargetBytecode());
private static int chooseBytecodeVersion(final boolean invokedynamic, final
boolean previewFeatures, final String targetBytecode) {
Integer bytecodeVersion =
CompilerConfiguration.JDK_TO_BYTECODE_VERSION_MAP.get(targetBytecode);
if (invokedynamic && bytecodeVersion < Opcodes.V1_8) {
return Opcodes.V1_8;
} else {
if (null != bytecodeVersion) {
return previewFeatures ? bytecodeVersion | Opcodes.V_PREVIEW :
bytecodeVersion;
}
}
throw new GroovyBugError("Bytecode version ["+targetBytecode+"] is not
supported by the compiler");
}
{code}
was (Author: emilles):
Here is how WriterController is handling it:
```java
bytecodeVersion = chooseBytecodeVersion(invokedynamic,
config.isPreviewFeatures(), config.getTargetBytecode());
private static int chooseBytecodeVersion(final boolean invokedynamic, final
boolean previewFeatures, final String targetBytecode) {
Integer bytecodeVersion =
CompilerConfiguration.JDK_TO_BYTECODE_VERSION_MAP.get(targetBytecode);
if (invokedynamic && bytecodeVersion < Opcodes.V1_8) {
return Opcodes.V1_8;
} else {
if (null != bytecodeVersion) {
return previewFeatures ? bytecodeVersion | Opcodes.V_PREVIEW :
bytecodeVersion;
}
}
throw new GroovyBugError("Bytecode version ["+targetBytecode+"] is not
supported by the compiler");
}
```
> Bump bytecode version to 1.8
>
>
> Key: GROOVY-9315
> URL: https://issues.apache.org/jira/browse/GROOVY-9315
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-rc-2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Groovy 3.0.0 requires Java 8+ and supports Java8 language features, so it's
> better to use its relevant class file version, i.e. 1.8
> In the old codebase, we can not manage the bytecode version well, for
> example, we use many bytecode versions to generate bytecode, some very old
> bytecode versions like {{1.3}} are still used.
> What I propose to do is manage the default bytecode code version in a place,
> same for its relevant compute mode and parse mode. If we want to change them,
> just modify only one place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9315) Bump bytecode version to 1.8
[
https://issues.apache.org/jira/browse/GROOVY-9315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981687#comment-16981687
]
Eric Milles commented on GROOVY-9315:
-
You don't need to store the bytecode version in a local field. You have target
bytecode setting and can map to bytecode version using
JDK_TO_BYTECODE_VERSION_MAP.
Why do ClassReader and ClassWriter need different values?
My suggestion is to close this PR and do some more research before trying to
make a bytecode read or write change at the last minute. Once Groovy 3 reached
release candidate, I was under the impression that bug fixes were the only
changes.
> Bump bytecode version to 1.8
>
>
> Key: GROOVY-9315
> URL: https://issues.apache.org/jira/browse/GROOVY-9315
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-rc-2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Groovy 3.0.0 requires Java 8+ and supports Java8 language features, so it's
> better to use its relevant class file version, i.e. 1.8
> In the old codebase, we can not manage the bytecode version well, for
> example, we use many bytecode versions to generate bytecode, some very old
> bytecode versions like {{1.3}} are still used.
> What I propose to do is manage the default bytecode code version in a place,
> same for its relevant compute mode and parse mode. If we want to change them,
> just modify only one place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-8213) Closures are maybe not Threadsafe
[
https://issues.apache.org/jira/browse/GROOVY-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-8213:
---
Assignee: (was: John Wagenleitner)
> Closures are maybe not Threadsafe
> -
>
> Key: GROOVY-8213
> URL: https://issues.apache.org/jira/browse/GROOVY-8213
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.10
> Environment: Gradle 3.5
>Reporter: Björn Kautler
>Priority: Major
> Fix For: 2.4.13
>
>
> I just upgraded our Gradle build from 1.12 (including Groovy 1.8.6) to 3.5
> (including Groovy 2.4.10).
> Now I get a very strange behavior for stuff that is there for years already
> and it looks to me as if this is a Groovy bug, maybe a non-threadsafeness of
> Closures.
> I have a custom task that contains the following code:
> {code}
> def sourceFilesSize = getSourceFiles().files.size()
> def poolSize = Runtime.runtime.availableProcessors()
> def executor = new ThreadPoolExecutor(poolSize, poolSize, 0, SECONDS,
> new ArrayBlockingQueue([sourceFilesSize, 1].max()))
> def tasks = []
> inputs.outOfDate { toTransform ->
> tasks.add executor.submit {
> project.exec {
>if (gscPath) { // here starts
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> environment 'GSC', gscPath
> def tempDir = "$temporaryDir/${Thread.currentThread().name}"
> project.file(tempDir).mkdirs()
> environment 'TEMP', tempDir
>}
>executable executablePath
>def arguments = [toTransform.file.absolutePath]
>if ((sourceFilesSize == 1) && getDestinationFile()) {
> arguments << getDestinationFile().absolutePath
>} else if (destinationDirectory) {
> arguments << new File(destinationDirectory,
> fileNameMapping(toTransform.file.name)).absolutePath
>} else {
> arguments << new File(toTransform.file.parentFile,
> fileNameMapping(toTransform.file.name)).absolutePath
>}
>args arguments // here ends
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> }
> }
> }
> executor.shutdown()
> executor.awaitTermination 1, HOURS
> tasks*.get() // here is line 137
> {code}
> When this task is executed e. g. with five source files, sometimes all works
> fine, sometime the build fails with
> {noformat}
> ...
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.IllegalStateException: initialize must be called for meta class of
> class com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> at com.empic.build.tasks.Ghostscript.exec(Ghostscript.groovy:137)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
> ... 80 more
> Caused by: java.lang.IllegalStateException: initialize must be called for
> meta class of class
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> {noformat}
> Actually I was not able to reproduce the problem locally, but if I run the
> build on our CI server and attach a debugger, I indeed was able to reproduce
> the problem with a relatively high reproduction rate. (as in every second to
> third build approximately, opposed to once every 100 builds)
> I logged the current thread when the {{initialized}} property is set to
> {{true}} and when it is requested with non-suspending breakpoints, but this
> seems to have caused the timing to change enough already that I was not able
> to reproduce the error within approximately the first two dozens of tries.
> I was able to successfully break at the throwing of the
> {{IllegalStateException}} though. This happens in
> {{groovy.lang.MetaClassImpl.checkInitalised}}.
> The stacktrace at this point is:
> {noformat}
> "pool-2-thread-3@10709" prio=5 tid=0x47 nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at groovy.lang.MetaClassImpl.checkInitalised(MetaClassImpl.java:1647)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:257)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1027)
> at groovy.lang.Closure.call(Closure.java:414)
> at groovy.lang.Closure.call(Closure.java:408)
> at groovy.lang.Closure.run(Closure.java:495)
> at
>
[jira] [Reopened] (GROOVY-8213) Closures are maybe not Threadsafe
[
https://issues.apache.org/jira/browse/GROOVY-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reopened GROOVY-8213:
-
> Closures are maybe not Threadsafe
> -
>
> Key: GROOVY-8213
> URL: https://issues.apache.org/jira/browse/GROOVY-8213
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.10
> Environment: Gradle 3.5
>Reporter: Björn Kautler
>Assignee: John Wagenleitner
>Priority: Major
> Fix For: 2.4.13
>
>
> I just upgraded our Gradle build from 1.12 (including Groovy 1.8.6) to 3.5
> (including Groovy 2.4.10).
> Now I get a very strange behavior for stuff that is there for years already
> and it looks to me as if this is a Groovy bug, maybe a non-threadsafeness of
> Closures.
> I have a custom task that contains the following code:
> {code}
> def sourceFilesSize = getSourceFiles().files.size()
> def poolSize = Runtime.runtime.availableProcessors()
> def executor = new ThreadPoolExecutor(poolSize, poolSize, 0, SECONDS,
> new ArrayBlockingQueue([sourceFilesSize, 1].max()))
> def tasks = []
> inputs.outOfDate { toTransform ->
> tasks.add executor.submit {
> project.exec {
>if (gscPath) { // here starts
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> environment 'GSC', gscPath
> def tempDir = "$temporaryDir/${Thread.currentThread().name}"
> project.file(tempDir).mkdirs()
> environment 'TEMP', tempDir
>}
>executable executablePath
>def arguments = [toTransform.file.absolutePath]
>if ((sourceFilesSize == 1) && getDestinationFile()) {
> arguments << getDestinationFile().absolutePath
>} else if (destinationDirectory) {
> arguments << new File(destinationDirectory,
> fileNameMapping(toTransform.file.name)).absolutePath
>} else {
> arguments << new File(toTransform.file.parentFile,
> fileNameMapping(toTransform.file.name)).absolutePath
>}
>args arguments // here ends
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> }
> }
> }
> executor.shutdown()
> executor.awaitTermination 1, HOURS
> tasks*.get() // here is line 137
> {code}
> When this task is executed e. g. with five source files, sometimes all works
> fine, sometime the build fails with
> {noformat}
> ...
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.IllegalStateException: initialize must be called for meta class of
> class com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> at com.empic.build.tasks.Ghostscript.exec(Ghostscript.groovy:137)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
> ... 80 more
> Caused by: java.lang.IllegalStateException: initialize must be called for
> meta class of class
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> {noformat}
> Actually I was not able to reproduce the problem locally, but if I run the
> build on our CI server and attach a debugger, I indeed was able to reproduce
> the problem with a relatively high reproduction rate. (as in every second to
> third build approximately, opposed to once every 100 builds)
> I logged the current thread when the {{initialized}} property is set to
> {{true}} and when it is requested with non-suspending breakpoints, but this
> seems to have caused the timing to change enough already that I was not able
> to reproduce the error within approximately the first two dozens of tries.
> I was able to successfully break at the throwing of the
> {{IllegalStateException}} though. This happens in
> {{groovy.lang.MetaClassImpl.checkInitalised}}.
> The stacktrace at this point is:
> {noformat}
> "pool-2-thread-3@10709" prio=5 tid=0x47 nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at groovy.lang.MetaClassImpl.checkInitalised(MetaClassImpl.java:1647)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:257)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1027)
> at groovy.lang.Closure.call(Closure.java:414)
> at groovy.lang.Closure.call(Closure.java:408)
> at groovy.lang.Closure.run(Closure.java:495)
> at
>
[jira] [Commented] (GROOVY-9235) Please reopen GROOVY-8213
[ https://issues.apache.org/jira/browse/GROOVY-9235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981625#comment-16981625 ] Björn Kautler commented on GROOVY-9235: --- [~emilles] ? > Please reopen GROOVY-8213 > - > > Key: GROOVY-9235 > URL: https://issues.apache.org/jira/browse/GROOVY-9235 > Project: Groovy > Issue Type: Bug >Reporter: Björn Kautler >Priority: Major > > Please reopen GROOVY-8213, it is not fixed -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [groovy] martin-grofcik opened a new pull request #1106: double stars for static imports
martin-grofcik opened a new pull request #1106: double stars for static imports URL: https://github.com/apache/groovy/pull/1106 Does it make sense to support `**` for static imports too? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (GROOVY-9315) Bump bytecode version to 1.8
[
https://issues.apache.org/jira/browse/GROOVY-9315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981217#comment-16981217
]
Daniel Sun edited comment on GROOVY-9315 at 11/25/19 8:23 AM:
--
bq. That place should be CompilerConfiguration.setTargetBytecode.
{{CompilerConfiguration#targetBytecode}} is something like 1.4, 1.8, which is
can not be used in ASM API directly. So we have to map the {{targetBytecode}}
to ASM's targetBytecode, e.g. {{Opcodes.V1_4}}, {{Opcodes.V1_8}}. The mapping
logic is implemented in {{CompilerConfiguration.setTargetBytecode}} too:
{code:java}
public void setTargetBytecode(String version) {
setTargetBytecodeIfValid(version);
}
private void setTargetBytecodeIfValid(String version) {
if (JDK_TO_BYTECODE_VERSION_MAP.containsKey(version)) {
this.targetBytecode = version;
this.asmTargetBytecode =
JDK_TO_BYTECODE_VERSION_MAP.get(this.targetBytecode); // set ASM targetBytecode
}
}
{code}
As for {{asmTargetBytecode}}, it has only getter.
bq. What is the difference between "parse mode" and "compute mode"?
compute mode is for {{ClassWriter}}, e.g. {{ClassWriter.COMPUTE_FRAMES}}
and parse mode is for {{ClassReader}}, e.g. {{ClassReader.SKIP_FRAMES}}
bq. Can this wait for Groovy 3.0.1 or Groovy 4?
If you have more suggestions, we should have time to tweak the PR before Groovy
3.0.0-rc-2 release.
was (Author: daniel_sun):
bq. That place should be CompilerConfiguration.setTargetBytecode.
{{CompilerConfiguration#targetBytecode}} is something like 1.4, 1.8, which is
can not be used in ASM API directly. So we have to map the {{targetBytecode}}
to ASM's targetBytecode, e.g. {{Opcodes.V1_4}}, {{Opcodes.V1_8}}.
bq. What is the difference between "parse mode" and "compute mode"?
compute mode is for {{ClassWriter}}, e.g. {{ClassWriter.COMPUTE_FRAMES}}
and parse mode is for {{ClassReader}}, e.g. {{ClassReader.SKIP_FRAMES}}
bq. Can this wait for Groovy 3.0.1 or Groovy 4?
If you have more suggestions, we should have time to tweak the PR before Groovy
3.0.0-rc-2 release.
> Bump bytecode version to 1.8
>
>
> Key: GROOVY-9315
> URL: https://issues.apache.org/jira/browse/GROOVY-9315
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-rc-2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Groovy 3.0.0 requires Java 8+ and supports Java8 language features, so it's
> better to use its relevant class file version, i.e. 1.8
> In the old codebase, we can not manage the bytecode version well, for
> example, we use many bytecode versions to generate bytecode, some very old
> bytecode versions like {{1.3}} are still used.
> What I propose to do is manage the default bytecode code version in a place,
> same for its relevant compute mode and parse mode. If we want to change them,
> just modify only one place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
