[jira] [Updated] (GROOVY-8396) illegal reflective access
[ https://issues.apache.org/jira/browse/GROOVY-8396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-8396: -- Affects Version/s: (was: 2.4.14) > illegal reflective access > - > > Key: GROOVY-8396 > URL: https://issues.apache.org/jira/browse/GROOVY-8396 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.4.13 > Environment: MacOS >Reporter: Jeff Pape >Priority: Major > > discovery:~ jeffpape$ groovy -v > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.codehaus.groovy.reflection.CachedClass > (file:/usr/local/opt/groovy/libexec/lib/groovy-2.4.12.jar) to method > java.lang.Object.finalize() > WARNING: Please consider reporting this to the maintainers of > org.codehaus.groovy.reflection.CachedClass > 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.4.12 JVM: 9.0.1 Vendor: Oracle Corporation OS: Mac OS X > discovery:~ jeffpape$ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8396) illegal reflective access
[ https://issues.apache.org/jira/browse/GROOVY-8396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-8396: -- Affects Version/s: 2.4.13 > illegal reflective access > - > > Key: GROOVY-8396 > URL: https://issues.apache.org/jira/browse/GROOVY-8396 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.4.13 > Environment: MacOS >Reporter: Jeff Pape >Priority: Major > > discovery:~ jeffpape$ groovy -v > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.codehaus.groovy.reflection.CachedClass > (file:/usr/local/opt/groovy/libexec/lib/groovy-2.4.12.jar) to method > java.lang.Object.finalize() > WARNING: Please consider reporting this to the maintainers of > org.codehaus.groovy.reflection.CachedClass > 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.4.12 JVM: 9.0.1 Vendor: Oracle Corporation OS: Mac OS X > discovery:~ jeffpape$ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GROOVY-8396) illegal reflective access
[ https://issues.apache.org/jira/browse/GROOVY-8396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-8396. - Resolution: Duplicate > illegal reflective access > - > > Key: GROOVY-8396 > URL: https://issues.apache.org/jira/browse/GROOVY-8396 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.4.14 > Environment: MacOS >Reporter: Jeff Pape >Priority: Major > > discovery:~ jeffpape$ groovy -v > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.codehaus.groovy.reflection.CachedClass > (file:/usr/local/opt/groovy/libexec/lib/groovy-2.4.12.jar) to method > java.lang.Object.finalize() > WARNING: Please consider reporting this to the maintainers of > org.codehaus.groovy.reflection.CachedClass > 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.4.12 JVM: 9.0.1 Vendor: Oracle Corporation OS: Mac OS X > discovery:~ jeffpape$ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-8447) It is allowed to define local variable of void type
[
https://issues.apache.org/jira/browse/GROOVY-8447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328293#comment-16328293
]
Paul King edited comment on GROOVY-8447 at 1/17/18 5:45 AM:
Actually this was already fixed on the 2_5_X branch via GROOVY-8046 with
slightly better error messages. For this example:
{code:java}
class MyClass {
void field
}
void localVar = 1
println localVar
{code}
It used to say:
{noformat}
3 compilation errors:
The field 'field' has invalid type void
at line: 2, column: 3
The parameter 'value' in method 'void setField(void)' has invalid type void
at line: -1, column: -1
The variable 'localVar' has invalid type void
at line: 5, column: 1
{noformat}
Now we get:
{noformat}
1 compilation error:
void is not allowed here at line: 2, column: 3
{noformat}
[~daniel_sun], do you think we can improve error messages with the new parser?
Or not easy? I'll have a look next week if you don't know off the top of your
head and don't have time to investigate.
was (Author: paulk):
Actually this was already fixed on the 2_5_X branch via GROOVY-8046 with
slightly better error messages. For this example:
{code:java}
class MyClass {
void field
}
void localVar = 1
println localVar
{code}
It used to say:
{noformat}
3 compilation errors:
The field 'field' has invalid type void
at line: 2, column: 3
The parameter 'value' in method 'void setField(void)' has invalid type void
at line: -1, column: -1
The variable 'localVar' has invalid type void
at line: 5, column: 1
{noformat}
Now we get:
{noformat}
1 compilation error:
void is not allowed here at line: 2, column: 3
{noformat}
Daniel, do you think we can improve error messages with the new parser? Or not
easy? I'll have a look next week if you don't know off the top of your head and
don't have time to investigate.
> It is allowed to define local variable of void type
> ---
>
> Key: GROOVY-8447
> URL: https://issues.apache.org/jira/browse/GROOVY-8447
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.13
>Reporter: Daniil Ovchinnikov
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 2.6.0-alpha-3, 3.0.0-alpha-2
>
>
> {code:title=bugs.groovy}
> void ff = 1
> println ff
> {code}
> {noformat}
> java.lang.ClassFormatError: Field "ff" in class bugs has illegal signature "V"
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8447) It is allowed to define local variable of void type
[
https://issues.apache.org/jira/browse/GROOVY-8447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328293#comment-16328293
]
Paul King commented on GROOVY-8447:
---
Actually this was already fixed on the 2_5_X branch via GROOVY-8046 with
slightly better error messages. For this example:
{code:java}
class MyClass {
void field
}
void localVar = 1
println localVar
{code}
It used to say:
{noformat}
3 compilation errors:
The field 'field' has invalid type void
at line: 2, column: 3
The parameter 'value' in method 'void setField(void)' has invalid type void
at line: -1, column: -1
The variable 'localVar' has invalid type void
at line: 5, column: 1
{noformat}
Now we get:
{noformat}
1 compilation error:
void is not allowed here at line: 2, column: 3
{noformat}
Daniel, do you think we can improve error messages with the new parser? Or not
easy? I'll have a look next week if you don't know off the top of your head and
don't have time to investigate.
> It is allowed to define local variable of void type
> ---
>
> Key: GROOVY-8447
> URL: https://issues.apache.org/jira/browse/GROOVY-8447
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.13
>Reporter: Daniil Ovchinnikov
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 2.6.0-alpha-3, 3.0.0-alpha-2
>
>
> {code:title=bugs.groovy}
> void ff = 1
> println ff
> {code}
> {noformat}
> java.lang.ClassFormatError: Field "ff" in class bugs has illegal signature "V"
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8451) Non-Map-Based Named Parameter Support
mgroovy created GROOVY-8451:
---
Summary: Non-Map-Based Named Parameter Support
Key: GROOVY-8451
URL: https://issues.apache.org/jira/browse/GROOVY-8451
Project: Groovy
Issue Type: Improvement
Reporter: mgroovy
* Groovy should support named parameters as available in many other languages:
https://en.wikipedia.org/wiki/Named_parameter
* The suggested syntax and semantics are the ones used by the Kotlin
programming language
https://kotlinlang.org/docs/reference/functions.html#named-arguments
since
## using the assignment operator to define named parameter values
*** Seems a very organic choice in the Java family of languages
*** Differentiates the syntax clearly from the alternate/existing Groovy map
based named parameter support
## The design decisions are relatively straightforward
## Kotlin syntax is close to Groovy (apart from some odd deviations), so what
works there should work in Groovy
* Features:
** Parameters are assigned a value prioritized in the following order:
### positional value
### named parameter value
### default value
** Parameters which do not have a default value must be given when calling the
method
** All non-named parameters must come before named-parameters
** Named parameters can be given in any order
* Example:
{code}
void foo(final x0, final x1, final x2 = defVal2, final x3 = defVal3, final x4 =
defVal4) { /* ... */ }
// x0 = val0, x1 = val1, x2 = val2, x3 = defVal3, x4 = val4
foo(val0, x2 = val2, x4 = val4, x1 = val1)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8113) Groovy script/template engine produce memory leak
[
https://issues.apache.org/jira/browse/GROOVY-8113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327145#comment-16327145
]
Vellington Penjinkilas commented on GROOVY-8113:
Do we have any solution for this memory ? Getting the same while doing
GroovyPageTemplateEngine
> Groovy script/template engine produce memory leak
> --
>
> Key: GROOVY-8113
> URL: https://issues.apache.org/jira/browse/GROOVY-8113
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine, Templating
>Affects Versions: 2.4.8
> Environment: Groovy 2.4.8, Oracle Java JDK 8u121
>Reporter: Artyom Kravchenko
>Priority: Major
> Attachments: merged_path.png, object_explorer.png
>
>
> There is a simple way to produce OutOfMemoryException if run infinite
> numbers of groovy scripts or evaluate groovy templates.
> Simple test to reproduce a memory leak(run groovy script and make template
> inside the script):
> set max heap size: -Xmx7m
> {code:java}
> import javax.script.*;
> import java.util.HashMap;
> import java.util.Map;
> public class OutOfMemoryTest {
> private static String TEMPLATE = "Dear ${fullName} please go away at
> ${time}";
> private static String SCRIPT = "def run(args) {\n" +
> "def bindings = ['fullName' : 'Ali Baba', 'time' : new Date()]\n"
> +
> "println
> args.templateEngine.createTemplate(args.template).make(bindings).toString()\n"
> +
> "}";
> public static void main(String... args) {
> //
> GroovySystem.getMetaClassRegistry().getMetaClassCreationHandler().setDisableCustomMetaClassLookup(true);
> while(true) {
> ScriptEngineManager engineManager = new ScriptEngineManager();
> ScriptEngine engine = engineManager.getEngineByName("groovy");
> try {
> engine.eval(SCRIPT);
> } catch (ScriptException e) {
> throw new RuntimeException(e);
> }
> groovy.text.SimpleTemplateEngine templateEngine = new
> groovy.text.SimpleTemplateEngine();
> Invocable inv = (Invocable) engine;
> Map params = new HashMap<>();
> params.put("template", TEMPLATE);
> params.put("templateEngine", templateEngine);
> Object[] runArgs = { params };
> try {
> inv.invokeFunction("run", runArgs);
> } catch (ScriptException | NoSuchMethodException e) {
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> The main cause of issue is Java class loader. Two instances:
> sun.misc.Launcher.AppClassLoader and sun.misc.Launcher.ExtClassLoader
> (parent for first one), each of them has a strong reference:
> {code:java}
> ConcurrentHashMap parallelLockMap
> {code}
> It collects all loaded classes (and never releases their) for application
> including newly created script/template classes.
> The main reason of introduction of this reference described here:
> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
> For each iteration of my test I see that parallelLockMap grows with 6 new
> entries:
> {code:java}
> groovy.runtime.metaclass.Script94MetaClass
> Script94BeanInfo
> Script94Customizer
> groovy.runtime.metaclass.SimpleTemplateScript94MetaClass
> SimpleTemplateScript94BeanInfo
> SimpleTemplateScript94Customizer
> {code}
> See memory snapshots(attached): objects_explorer, merged_path.
> I have found a partial solution of the issue, if I add this code line to my
> test:
> {code:java}
>
> GroovySystem.getMetaClassRegistry().getMetaClassCreationHandler().setDisableCustomMetaClassLookup(true);
> {code}
> I see that classes like:
> {code:java}
> groovy.runtime.metaclass.Script94MetaClass
> groovy.runtime.metaclass.SimpleTemplateScript94MetaClass
> {code}
> goes away (groovy engine don't ask ClassLoader to find this classes on class
> path therefore such classes are not collected by ClassLoader) but classes
> like
> {code:java}
> Script94BeanInfo
> Script94Customizer
> SimpleTemplateScript94BeanInfo
> SimpleTemplateScript94Customizer
> {code}
> still has affect on memory.
> Dear developers, could you please point me any advice/workarounds for this
> issue. It will be fine to get rig this issue in future releases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8449) Inconsistency in accessing uppercase properties in @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniil Ovchinnikov updated GROOVY-8449:
---
Description:
{code:java|title=bugs.groovy}
class Fields {
def Field = "field"
def getField() { "getter" }
}
def usageCompileDynamic() {
new Fields().Field
}
@CompileStatic
def usageCompileStatic() {
new Fields().Field
}
println usageCompileDynamic() // field
println usageCompileStatic() // getter{code}
was:
{code:title=bugs.groovy}
class Fields {
def Field = "field"
def getField() { "getter" }
}
@CompileStatic
def usageCompileStatic() {
new Fields().Field
}
def usageCompileDynamic() {
new Fields().Field
}
println usageCompileDynamic() // field
println usageCompileStatic() // getter{code}
> Inconsistency in accessing uppercase properties in @CompileStatic
> -
>
> Key: GROOVY-8449
> URL: https://issues.apache.org/jira/browse/GROOVY-8449
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
>Reporter: Daniil Ovchinnikov
>Priority: Major
>
> {code:java|title=bugs.groovy}
> class Fields {
> def Field = "field"
> def getField() { "getter" }
> }
> def usageCompileDynamic() {
> new Fields().Field
> }
> @CompileStatic
> def usageCompileStatic() {
> new Fields().Field
> }
> println usageCompileDynamic() // field
> println usageCompileStatic() // getter{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
