[jira] [Commented] (GROOVY-11516) Improve consistency of treatment for internal properties
[
https://issues.apache.org/jira/browse/GROOVY-11516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17895581#comment-17895581
]
Jochen Theodorou commented on GROOVY-11516:
---
I do agree that $ is often used to specify something internal. But normally
then something else is supposed to be used instead. The issue sounds
like:{code:Java}
new Foo()."amountIn$" = 20
{code}should no longer be possible. But since you only modify getProperties(),
setting the then "hidden property" should still work. But how will you realize
the variant in which you do want to print out amountIn$ for @ToString with
allNames=true? There is no API for that.
Also for @ToString I would think about a functional variant.
{code:java}
@ToString(includeFields=true, includeNames=true, filterNames={name ->
!name.contains('$')})
{code}
Don't take it as a solution, just as food for thought. But the point I am
aiming for is that you want some kind of filtering not only in ToString, but
also for toJson and maybe many other situations... so maybe we should even go
as far as having some kind of {code:Java}
@Internal(name -> name.contains('$'){code}
Or to come back to "normally then something else is supposed to be used
instead":
{code:Java}@NameTransformer(name -> name.contains($')? null:name){code}
Allowing you to control the output...
This can then be used by getProperties(), toJson and toString, though then we
would also have to discuss if that forms a valid name for setting the property.
> Improve consistency of treatment for internal properties
>
>
> Key: GROOVY-11516
> URL: https://issues.apache.org/jira/browse/GROOVY-11516
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Labels: breaking
>
> In numerous places, property names containing a "$" are deemed internal but
> not MetaClassImpl#getProperties. This means for instance that
> JsonOutput.toJson() currently outputs such internal properties.
> After this change, such properties would not normally be returned. No test
> fails after such a change indicating that this is an edge case we haven't
> covered previously.
> This would be a breaking change if anyone is really on the existing edge case
> behavior. If necessary, we could use a system property to re-enable the
> system behavior. We already have a system property
> "groovy.permissive.property.access". We could use
> "groovy.dollar.property.access" as well but I wasn't planning to add this
> unless we get feedback that some folks need it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11516) Improve consistency of treatment for internal properties
[
https://issues.apache.org/jira/browse/GROOVY-11516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17895201#comment-17895201
]
Jochen Theodorou commented on GROOVY-11516:
---
What about class Foo { def "amountIn$"} ?
> Improve consistency of treatment for internal properties
>
>
> Key: GROOVY-11516
> URL: https://issues.apache.org/jira/browse/GROOVY-11516
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Priority: Major
> Labels: breaking
>
> In numerous places, property names containing a "$" are deemed internal but
> not MetaClassImpl#getProperties. This means for instance that
> JsonOutput.toJson() currently outputs such internal properties.
> After this change, such properties would not normally be returned. No test
> fails after such a change indicating that this is an edge case we haven't
> covered previously.
> This would be a breaking change if anyone is really on the existing edge case
> behavior. If necessary, we could use a system property to re-enable the
> system behavior. We already have a system property
> "groovy.permissive.property.access". We could use
> "groovy.dollar.property.access" as well but I wasn't planning to add this
> unless we get feedback that some folks need it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11508) Multiple traits with related generic types cannot be used
[
https://issues.apache.org/jira/browse/GROOVY-11508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17892860#comment-17892860
]
Jochen Theodorou commented on GROOVY-11508:
---
[~jdaugherty]
I think that we are talking about a trait is a bit of a false flag in the end.
This code here
{code:java}
interface GormEntity {}
class Child implements GormEntity {}
class Parent extends Child implements GormEntity {}
{code}
Has no traits, no (static) methods nothing, still the Java compiler does not
accept this. The connection to traits comes in play if you do not forget that
there is the trait GormEntity for Groovy, but for the JVM this consists of the
interface of the same name and some helper classes. Which means we get exactly
the above situation, even if you remove all the otherwise generated code.
And for the reasoning behind this I have this here
[https://bugs.openjdk.org/browse/JDK-8030724] as an interesting read.
Then there is the issue with the injected method getAll. In case of
{code:java}
trait GormEntity {
static List getAll() {null}
}
class Parent implements GormEntity {}
{code}
Here Integer is not the class Integer, it is the generics placeholder like you
normally use T:
{code:java}
trait GormEntity {
static List getAll() {null}
}
class Parent implements GormEntity {}
{code}
Since the base type for D is Object using GormEntity is equal to
GormEntity
Now coming back to the original problem According to
[http://docs.groovy-lang.org/docs/groovy-2.3.0/html/documentation/core-traits.html#_default_conflict_resolution]
we have a conflict resolution specified in case of two traits providing a
method with equal signature. That means in case of X implements
GormEntity, GormEntity we would have a getAll returning
List and in the reverse case List. Let us assume we have
{code:java}
trait GormEntity {
List getAll() {null}
}
trait GormEntity2 {
List getAll() {null}
}
class Child implements GormEntity{}
class Parent extends Child implements GormEntity2 {}
{code}
So without the static modifier. Then we get a List, that looks like
List in Child and a List, that looks like List in
Parent, overriding the one in child, because the method signatures are equal
after type erasure. That means Parent will have the method from GormEntity2.
Now assume this in Java:
{code:java}
Parent parent = new Parent()
Child child = parent
List lc = child.getAll()
List ld = parent.getAll()
{code}
How can calling the same method produce one time List and another time
List? It cannot, and the Java compiler would refuse compiling the line
for lc.. Therefore I am not really too keen on allowing the implementation of
multiple parametrized interfaces of same name with different parameter
configurations. In theory it could be allowed unless there is a conflict, but
then there is the recompilation issue... feels like a can of worms to reopen
here.
Which means for me that the case of a static modifier is actually something
where we have to take different aspects into consideration. One of them being
that static methods are not really inherited like in the last variant.
Parent.getAll() can call a different method than Child.getAll(). And
[http://docs.groovy-lang.org/docs/groovy-2.3.0/html/documentation/core-traits.html#_static_methods_properties_and_fields]
states that static methods are experimental.
My suggestion would be to modify the way static aspects work by add an
annotation preventing the trait interface to be added to the class receiving
the trait.
This would solve the problem for the static methods by simply putting them in a
trait and use the annotation for the marker interface to not be used. Looking
at
https://github.com/grails/grails-data-mapping/blob/9.0.x/grails-datastore-gorm/src/main/groovy/org/grails/datastore/gorm/GormEntity.groovy
I see two more groups of methods though... MOP related methods without
generics, which are no problem... but then also methods like save(). Or as you
mentioned already, refresh().
There would be in theory a solution using extension methods. Of course that
means they are not callable from Java, not normally.
> Multiple traits with related generic types cannot be used
> -
>
> Key: GROOVY-11508
> URL: https://issues.apache.org/jira/browse/GROOVY-11508
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 4.0.0
>Reporter: James Daugherty
>Assignee: Eric Milles
>Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> When updating Grails from Groovy 3.x to 4.x we discovered that GROOVY-5106
> prevents us from updating to Groovy 4 for the
> [grails-data-mapping|https://github.com/grails/grails-data-mapping] (GORM)
> proje
[jira] [Commented] (GROOVY-11470) type unsafety when using flow typing and wildcard
[
https://issues.apache.org/jira/browse/GROOVY-11470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879639#comment-17879639
]
Jochen Theodorou commented on GROOVY-11470:
---
yes, that should be a problem of intersection. the type in the if and outside
need to be interjected after the if-block, so I guess something like
Comparable should have been the type for x at the point
of assignent to p, which is obviously not compatible
> type unsafety when using flow typing and wildcard
> -
>
> Key: GROOVY-11470
> URL: https://issues.apache.org/jira/browse/GROOVY-11470
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
>
> I have the following program
> {code:java}
> class Test {
> public static Comparable m() {
> return 1;
> }
> public static void main(String[] args) {
> def x = m()
> if (true) {
> x = ""
> }
> Comparable p = x
> p.compareTo(1)
> }
> } {code}
> h3. Actual behavior
> The code compiles, but I receive a ClassCastException at runtime
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: class
> java.lang.Integer cannot be cast to class java.lang.String (java.lang.Integer
> and java.lang.String are in module java.base of loader 'bootstrap')
> at java.base/java.lang.String.compareTo(String.java:144)
> at Test.main(test.groovy:16)
> {code}
> h3. Expected behavior
> The code should have been rejected, as the type of variable x is not
> Comparable.
> I suppose that the problem lies in the implementation of intersection types,
> and not in the implementation of flow-sensitive analysis.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11415) Bytecode for identity
[
https://issues.apache.org/jira/browse/GROOVY-11415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877976#comment-17877976
]
Jochen Theodorou commented on GROOVY-11415:
---
[~emilles] the first 2 commits look right to me, they are no breaking change
they just inline the code from ScriptBytecodeAdapte. The third commit though
makes === equal to == for primitives, which includes widening. This would be
new. To be equal again the third commit should be changed to check if let and
right are of the same primitive type and then go into
BinaryExpressionMultiTypeDispatcher. If left and right are of different
primitive type, then the result would be always false and align with the old
implementation again. This last commit is just an optimization of a special
case. It seems at least.
In fact I would even consider going as far as adding a compile time check,
which tests that if both sides are of different primitive types for === we give
a compilation error.
Now if one side is primitive and the other its wrapper like int/Integer, then
=== depends on if the Integer for the int is cached or not. But that is the
same as before. So (100 === Integer.valueOf(100)) == false, but we
want (100 === 100) == true. And this last variant may actually fail
before Groovy while it should pass now. That is the only change I can think of
besides the widening
> Bytecode for identity
> -
>
> Key: GROOVY-11415
> URL: https://issues.apache.org/jira/browse/GROOVY-11415
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 5.0.0-alpha-9, 4.0.22
>
>
> The bytecode for {{===}} and {{!==}} is to invoke static method, e.g.
> \{{compareIdentical}}, \{{compareNotIdentical}}.
> We could generate better bytecode by leveraging \{{IF_ACMPEQ}},
> \{{IF_ACMPNE}}, which is same to the bytecode generated by Java compiler.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11409) Spring Boot JPA Repository Class is not autowired in Groovy
[
https://issues.apache.org/jira/browse/GROOVY-11409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877967#comment-17877967
]
Jochen Theodorou commented on GROOVY-11409:
---
[~msangel] it is a URLClassLoader for the script discovery, but it does not
provide a way to load .class files from somewhere. The compiler compiles the
scripts to memory in bytecode and then provides them to defineClass. From that
point on the class is loaded and the bytecode forgotten. The loader could be
extended to save the classes, or keep them in memory. There is the option of
setting an output path in the compiler configuration given to the class loader,
which is of course much more easy. But this will still require a script, that
loads the main script for Spring Boot via GroovyShell or GroovyClassLoader
> Spring Boot JPA Repository Class is not autowired in Groovy
> ---
>
> Key: GROOVY-11409
> URL: https://issues.apache.org/jira/browse/GROOVY-11409
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.21
> Environment: linux
>Reporter: msangel
>Priority: Critical
> Attachments: bugreport.7z
>
>
> I have a code that works in java. its sample spring-boot application:
>
> {code:java}
> package com.example.demo;
> import lombok.Getter;
> import lombok.Setter;
> import lombok.extern.slf4j.Slf4j;
> import org.springframework.beans.factory.annotation.Autowired;
> import org.springframework.boot.SpringApplication;
> import org.springframework.boot.autoconfigure.SpringBootApplication;
> import org.springframework.boot.context.event.ApplicationReadyEvent;
> import org.springframework.context.event.EventListener;
> import org.springframework.data.jpa.repository.config.EnableJpaRepositories;
> import org.springframework.data.repository.CrudRepository;
> import org.springframework.stereotype.Repository;
> import org.springframework.transaction.annotation.Isolation;
> import org.springframework.transaction.annotation.Transactional;
> import javax.persistence.*;
> @SpringBootApplication
> @EnableJpaRepositories(considerNestedRepositories = true)
> @Slf4j
> public class DemoApplication {
> @Getter @Setter
> @Entity
> @Table(name = "record")
> public static class Record {
>@Id
>@GeneratedValue(strategy = GenerationType.IDENTITY)
>private long id;
>private String data;
> }
> @Repository
> @Transactional(isolation = Isolation.SERIALIZABLE)
> interface RecordRepository extends CrudRepository {
> }
> @Autowired
> private DemoApplication.RecordRepository recordRepository;
> @EventListener(ApplicationReadyEvent.class)
> public void ready() {
>Iterable all = recordRepository.findAll();
>if (all.iterator().hasNext()) {
> throw new IllegalStateException("There should be no records");
>}
>recordRepository.save(new DemoApplication.Record());
>all = recordRepository.findAll();
>if (!all.iterator().hasNext()) {
> throw new IllegalStateException("There should be records");
>}
>log.info("All good");
> }
> public static void main(String[] args) {
>SpringApplication.run(DemoApplication.class, args).close();
> }
> }
> {code}
> And its property file (application.yaml):
>
>
> {code:java}
> server:
> port: 8080
> spring:
> sql:
> init:
> platform: sqlite
> mode: always
> datasource:
> url: "jdbc:sqlite::memory:"
> username:
> password:
> driver-class-name: org.sqlite.JDBC
> jpa:
> database-platform: org.sqlite.hibernate.dialect.SQLiteDialect
> show-sql: false
> defer-datasource-initialization: true
> hibernate:
> ddl-auto: create
> jdbc:
> time_zone: UTC
> open-in-view: false
> {code}
>
>
> Running it works as expected, "All good" is shown into console.
> After converting the same code to groovy this code fail. The error is:
>
> {code:java}
> No qualifying bean of type
> 'com.example.demo2.DemoApplication$RecordRepository' available: expected at
> least 1 bean which qualifies as autowire candidate. Dependency annotations:
> {@org.springframework.beans.factory.annotation.Autowired(required=true)}
> {code}
> So, the spring is not seeing static nested class IF it is in groovy.
>
> This is the groove code I run:
>
> {code:java}
> package com.example.demo2
> @GrabConfig
> @Grab(group = 'org.springframework.boot', module = 'spring-boot-starter-web',
> version = '2.7.18')
> @Grab(group = 'org.xerial', module = 'sqlite-jdbc', version = '3.45.3.0')
> @Grab(group = 'org.springframework.boot', module =
> 'spring-boot-starter-data-jpa', version = '2.7.18')
> @Grab(group = 'com.github.gwenn', module = 'sqlite-dialect', version =
> "0.
[jira] [Commented] (GROOVY-11409) Spring Boot JPA Repository Class is not autowired in Groovy
[
https://issues.apache.org/jira/browse/GROOVY-11409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876176#comment-17876176
]
Jochen Theodorou commented on GROOVY-11409:
---
[~msangel] I think it may not be enough to provide some indicator in
getResources, Spring needs to be actually able to load the bytecode of those
classes. After a class has been defined, there is afaik no access to the
bytecode anymore unless you have the code saved somewhere. Since the class
files do not exist, not even in memory, there is nothing to load the bytecode
from.
> Spring Boot JPA Repository Class is not autowired in Groovy
> ---
>
> Key: GROOVY-11409
> URL: https://issues.apache.org/jira/browse/GROOVY-11409
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.21
> Environment: linux
>Reporter: msangel
>Priority: Critical
> Attachments: bugreport.7z
>
>
> I have a code that works in java. its sample spring-boot application:
>
> {code:java}
> package com.example.demo;
> import lombok.Getter;
> import lombok.Setter;
> import lombok.extern.slf4j.Slf4j;
> import org.springframework.beans.factory.annotation.Autowired;
> import org.springframework.boot.SpringApplication;
> import org.springframework.boot.autoconfigure.SpringBootApplication;
> import org.springframework.boot.context.event.ApplicationReadyEvent;
> import org.springframework.context.event.EventListener;
> import org.springframework.data.jpa.repository.config.EnableJpaRepositories;
> import org.springframework.data.repository.CrudRepository;
> import org.springframework.stereotype.Repository;
> import org.springframework.transaction.annotation.Isolation;
> import org.springframework.transaction.annotation.Transactional;
> import javax.persistence.*;
> @SpringBootApplication
> @EnableJpaRepositories(considerNestedRepositories = true)
> @Slf4j
> public class DemoApplication {
> @Getter @Setter
> @Entity
> @Table(name = "record")
> public static class Record {
>@Id
>@GeneratedValue(strategy = GenerationType.IDENTITY)
>private long id;
>private String data;
> }
> @Repository
> @Transactional(isolation = Isolation.SERIALIZABLE)
> interface RecordRepository extends CrudRepository {
> }
> @Autowired
> private DemoApplication.RecordRepository recordRepository;
> @EventListener(ApplicationReadyEvent.class)
> public void ready() {
>Iterable all = recordRepository.findAll();
>if (all.iterator().hasNext()) {
> throw new IllegalStateException("There should be no records");
>}
>recordRepository.save(new DemoApplication.Record());
>all = recordRepository.findAll();
>if (!all.iterator().hasNext()) {
> throw new IllegalStateException("There should be records");
>}
>log.info("All good");
> }
> public static void main(String[] args) {
>SpringApplication.run(DemoApplication.class, args).close();
> }
> }
> {code}
> And its property file (application.yaml):
>
>
> {code:java}
> server:
> port: 8080
> spring:
> sql:
> init:
> platform: sqlite
> mode: always
> datasource:
> url: "jdbc:sqlite::memory:"
> username:
> password:
> driver-class-name: org.sqlite.JDBC
> jpa:
> database-platform: org.sqlite.hibernate.dialect.SQLiteDialect
> show-sql: false
> defer-datasource-initialization: true
> hibernate:
> ddl-auto: create
> jdbc:
> time_zone: UTC
> open-in-view: false
> {code}
>
>
> Running it works as expected, "All good" is shown into console.
> After converting the same code to groovy this code fail. The error is:
>
> {code:java}
> No qualifying bean of type
> 'com.example.demo2.DemoApplication$RecordRepository' available: expected at
> least 1 bean which qualifies as autowire candidate. Dependency annotations:
> {@org.springframework.beans.factory.annotation.Autowired(required=true)}
> {code}
> So, the spring is not seeing static nested class IF it is in groovy.
>
> This is the groove code I run:
>
> {code:java}
> package com.example.demo2
> @GrabConfig
> @Grab(group = 'org.springframework.boot', module = 'spring-boot-starter-web',
> version = '2.7.18')
> @Grab(group = 'org.xerial', module = 'sqlite-jdbc', version = '3.45.3.0')
> @Grab(group = 'org.springframework.boot', module =
> 'spring-boot-starter-data-jpa', version = '2.7.18')
> @Grab(group = 'com.github.gwenn', module = 'sqlite-dialect', version =
> "0.1.4")
> @Grab(group = 'jakarta.persistence', module = 'jakarta.persistence-api',
> version = '2.2.2')
> @GrabExclude(group = 'javax.persistence', module='javax.persistence-api')
> @Grab(group = 'org.jboss.spec.javax.transaction', module =
>
[jira] [Commented] (GROOVY-11442) Could not find class for Transformation Processor
[ https://issues.apache.org/jira/browse/GROOVY-11442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867563#comment-17867563 ] Jochen Theodorou commented on GROOVY-11442: --- I forgot to mention... this is during compilation, not while running an application. This means you need to start gradle itself in debug mode, since gradle will execute the groovy compiler... well... I guess a worker is doing that actually... so you may have to debug the gradle worker. > Could not find class for Transformation Processor > - > > Key: GROOVY-11442 > URL: https://issues.apache.org/jira/browse/GROOVY-11442 > Project: Groovy > Issue Type: Bug > Components: ast builder >Affects Versions: 4.0.22 >Reporter: Pruteanu Dragos >Priority: Major > > In this project: https://github.com/wise-coders/groovyfx., a fork of > [GroovyFX][http://groovyfx.org/] (see [source > code][https://github.com/groovyfx-project/groovyfx]). > Upgrading to OpenJDK 17 and Gradle 7.6 I get this error (which did not happen > under Java 8): > ``` > Could not find class for Transformation Processor > groovyx.javafx.beans.FXBindableASTTransformation declared by > groovyx.javafx.beans.FXBindable > ``` > The > [FXBindableASTTransformation][https://github.com/groovyfx-project/groovyfx/blob/master/src/main/groovy/groovyx/javafx/beans/FXBindableASTTransformation.java] > is used as annotation in > [FXBindable][https://github.com/groovyfx-project/groovyfx/blob/master/src/main/groovy/groovyx/javafx/beans/FXBindable.java]. > How can I prevent this error? > You can test it by executing > ``` > cd groovyfx > gradlew build > gradlew runAccordionDemo > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11442) Could not find class for Transformation Processor
[
https://issues.apache.org/jira/browse/GROOVY-11442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867345#comment-17867345
]
Jochen Theodorou commented on GROOVY-11442:
---
ok, ok.. let us take a step back. And repeat...
{code:java}
Could not find class for Transformation Processor
groovyx.javafx.beans.FXBindableASTTransformation declared by
groovyx.javafx.beans.FXBindable
{code}
this means there is code annotated with FXBindable, which is a groovy transform
from groovyfx, and this transform has the processor
FXBindableASTTransformation, which is also from groovyfx. And they are compiled
and should be in the same jar/module. For Groovy to not to find it, it would
mean the class loader for the transformations does not contain this jar.
{color:#00}ASTTransformationCollectorCodeVisitor#{color}loadTransformClass
is responsible for this. so something must set a transformation context and
this context is wrong or incomplete. What I can see is that only the master
branch of groovyfx claims some compatibility to Java11 and when I tried it , it
did build, but I cannot run any demo because of
{noformat}
Extension of type 'ModularityExtension' does not exist.{noformat}
I did not try in the IDE. so all I can suggest is to debug
{color:#00}ASTTransformationCollectorCodeVisitor and find out what is given
as tranform classpath and why.{color}
> Could not find class for Transformation Processor
> -
>
> Key: GROOVY-11442
> URL: https://issues.apache.org/jira/browse/GROOVY-11442
> Project: Groovy
> Issue Type: Bug
> Components: ast builder
>Affects Versions: 4.0.22
>Reporter: Pruteanu Dragos
>Priority: Major
>
> In this project: https://github.com/wise-coders/groovyfx., a fork of
> [GroovyFX][http://groovyfx.org/] (see [source
> code][https://github.com/groovyfx-project/groovyfx]).
> Upgrading to OpenJDK 17 and Gradle 7.6 I get this error (which did not happen
> under Java 8):
> ```
> Could not find class for Transformation Processor
> groovyx.javafx.beans.FXBindableASTTransformation declared by
> groovyx.javafx.beans.FXBindable
> ```
> The
> [FXBindableASTTransformation][https://github.com/groovyfx-project/groovyfx/blob/master/src/main/groovy/groovyx/javafx/beans/FXBindableASTTransformation.java]
> is used as annotation in
> [FXBindable][https://github.com/groovyfx-project/groovyfx/blob/master/src/main/groovy/groovyx/javafx/beans/FXBindable.java].
> How can I prevent this error?
> You can test it by executing
> ```
> cd groovyfx
> gradlew build
> gradlew runAccordionDemo
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11442) Could not find class for Transformation Processor
[ https://issues.apache.org/jira/browse/GROOVY-11442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17866649#comment-17866649 ] Jochen Theodorou commented on GROOVY-11442: --- I believe the gradle plugin I mentioned does these kinds of things for you. Check out [https://openjfx.io/openjfx-docs/#modular] it has at the end also suggestions for a non-modular version with and without gradle. Maye you are missing one of the jars > Could not find class for Transformation Processor > - > > Key: GROOVY-11442 > URL: https://issues.apache.org/jira/browse/GROOVY-11442 > Project: Groovy > Issue Type: Bug > Components: ast builder >Affects Versions: 4.0.22 >Reporter: Pruteanu Dragos >Priority: Major > > In this project: https://github.com/wise-coders/groovyfx., a fork of > [GroovyFX][http://groovyfx.org/] (see [source > code][https://github.com/groovyfx-project/groovyfx]). > Upgrading to OpenJDK 17 and Gradle 7.6 I get this error (which did not happen > under Java 8): > ``` > Could not find class for Transformation Processor > groovyx.javafx.beans.FXBindableASTTransformation declared by > groovyx.javafx.beans.FXBindable > ``` > The > [FXBindableASTTransformation][https://github.com/groovyfx-project/groovyfx/blob/master/src/main/groovy/groovyx/javafx/beans/FXBindableASTTransformation.java] > is used as annotation in > [FXBindable][https://github.com/groovyfx-project/groovyfx/blob/master/src/main/groovy/groovyx/javafx/beans/FXBindable.java]. > How can I prevent this error? > You can test it by executing > ``` > cd groovyfx > gradlew build > gradlew runAccordionDemo > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11442) Could not find class for Transformation Processor
[ https://issues.apache.org/jira/browse/GROOVY-11442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17866467#comment-17866467 ] Jochen Theodorou commented on GROOVY-11442: --- JavaFX is not part of the JDK anymore, you have to add it extra - for example from [https://openjfx.io/] there is also a gradle plugin under [https://openjfx.io/openjfx-docs/#gradle] mentioned > Could not find class for Transformation Processor > - > > Key: GROOVY-11442 > URL: https://issues.apache.org/jira/browse/GROOVY-11442 > Project: Groovy > Issue Type: Bug > Components: ast builder >Affects Versions: 4.0.22 >Reporter: Pruteanu Dragos >Priority: Major > > In this project: https://github.com/wise-coders/groovyfx., a fork of > [GroovyFX][http://groovyfx.org/] (see [source > code][https://github.com/groovyfx-project/groovyfx]). > Upgrading to OpenJDK 17 and Gradle 7.6 I get this error (which did not happen > under Java 8): > ``` > Could not find class for Transformation Processor > groovyx.javafx.beans.FXBindableASTTransformation declared by > groovyx.javafx.beans.FXBindable > ``` > The > [FXBindableASTTransformation][https://github.com/groovyfx-project/groovyfx/blob/master/src/main/groovy/groovyx/javafx/beans/FXBindableASTTransformation.java] > is used as annotation in > [FXBindable][https://github.com/groovyfx-project/groovyfx/blob/master/src/main/groovy/groovyx/javafx/beans/FXBindable.java]. > How can I prevent this error? > You can test it by executing > ``` > cd groovyfx > gradlew build > gradlew runAccordionDemo > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11371) unsafe conversion of array of reference type to an array of primitive type
[
https://issues.apache.org/jira/browse/GROOVY-11371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860211#comment-17860211
]
Jochen Theodorou commented on GROOVY-11371:
---
[~emilles] why is a compiletime error not better?
> unsafe conversion of array of reference type to an array of primitive type
> --
>
> Key: GROOVY-11371
> URL: https://issues.apache.org/jira/browse/GROOVY-11371
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Assignee: Eric Milles
>Priority: Minor
>
> I have the following program
> {code:java}
> class Test {
> public static void main(String[] args) {
> double[] z = new Double[]{null};
> }
> } {code}
> h3. Actual behavior
> The compiler accepts the program. However, I get the following exception at
> runtime.
>
> {code:java}
> Exception in thread "main" java.lang.IllegalArgumentException
> at java.base/java.lang.reflect.Array.set(Native Method)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.asArray(DefaultTypeTransformation.java:459)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:228)
> at
> org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:336)
> at Test.main(test.groovy:3)
> {code}
> h3. Expected behavior
> The compiler should reject the program: Double[] is not convertible to
> double[].
> h3. Notes
> Tested against master (commit: 8ba8e8264fc3edeb9c70b52937edb97b0246a5d5)
> Groovy 4.0.10 rejects the program as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11337) Bump asciidoctorj-diagram to 2.3.0
[
https://issues.apache.org/jira/browse/GROOVY-11337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825403#comment-17825403
]
Jochen Theodorou commented on GROOVY-11337:
---
The arrows can maybe be prolonged with by using more arrow line elements.. ->
can be --> or ---> and plantuml is maybe displaying the in different lengths...
in the end it depends on the layout manager if it does respect that or not.
The original can maybe also fixed by installing graphviz/dot on the container
running the conversion. Something like
{code:java}
apk add --update --no-cache graphviz ttf-freefont
{code}
if it would be docker...
> Bump asciidoctorj-diagram to 2.3.0
> --
>
> Key: GROOVY-11337
> URL: https://issues.apache.org/jira/browse/GROOVY-11337
> Project: Groovy
> Issue Type: Dependency upgrade
>Reporter: Daniel Sun
>Assignee: Paul King
>Priority: Major
> Fix For: 5.0.0-alpha-8
>
> Attachments: image-2024-03-11-06-06-04-300.png,
> image-2024-03-11-06-07-12-504.png, image-2024-03-11-20-23-46-948.png
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11337) Bump asciidoctorj-diagram to 2.3.0
[ https://issues.apache.org/jira/browse/GROOVY-11337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825240#comment-17825240 ] Jochen Theodorou commented on GROOVY-11337: --- If you add "!pragma layout smetana" to the plantuml parts (top), then it should no longer use GraphViz. There is a GraphViz/dot in the plantuml jar, but only if the right one is used. > Bump asciidoctorj-diagram to 2.3.0 > -- > > Key: GROOVY-11337 > URL: https://issues.apache.org/jira/browse/GROOVY-11337 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Attachments: image-2024-03-11-06-06-04-300.png, > image-2024-03-11-06-07-12-504.png > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11311) Groovy Closure not retaining param annotations, but only for the default single object param case
[
https://issues.apache.org/jira/browse/GROOVY-11311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820629#comment-17820629
]
Jochen Theodorou commented on GROOVY-11311:
---
>From a dynamic Groovy only perspective the call methods are usually not even
>called for generated closures. Instead we call directly the doCall methods.
>The call methods are just helpers for calls made from Java. So I expect all
>important information to be on them.
>From a static Groovy perspective we know at compile time of course only the
>call methods call(), call(Object) and call(Object[]). They may do dynamic
>method calls to the real doCall methods. Of course this does not provide any
>type safety because for {int i ->i} we have a doCall(int) method, but also a
>call() method, which would fail if called. for {int i=1 ->i} we have of course
>two doCall methods doCall() and doCall(int), now call() is ok. call("foo") or
>call(1,2,3) is of course still not ok and will fail at runtime. We can
>overwrite the call methods to do direct method calls and safe the dynamic
>invocation, but I would still not add the annotation decorators there.
> Groovy Closure not retaining param annotations, but only for the default
> single object param case
> -
>
> Key: GROOVY-11311
> URL: https://issues.apache.org/jira/browse/GROOVY-11311
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.8, 4.0.4
>Reporter: Val E
>Assignee: Eric Milles
>Priority: Minor
> Attachments: ClosureAnnotationsTest.groovy
>
>
> In trying to process Groovy closure param annotations, via Java reflection, I
> realized that there is one narrow case where the param annotations are not
> preserved in the generated call method.
> This happens only for the case of a single Object param type. All other
> variations retain the annotation, it can be a single param of a different
> type, or multiple params of Object type. I think this may have something to
> do with handling the default 'it' param
> ex:
> {code:java}
> {@TESTANNO def x-> } //wont retain @TESTANNO
> {code}
> {code:java}
> {@TESTANNO Object x-> } //wont retain @TESTANNO
> {code}
> {code:java}
> {@TESTANNO Integer x-> } //will retain @TESTANNO
> {code}
> {code:java}
> {@TESTANNO def x, @TESTANNO def y-> }//will retain @TESTANNO on both x and y
> {code}
>
> Attached a basic groovy script to demonstrate.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11313) Closure owner seems to be overwritten
[
https://issues.apache.org/jira/browse/GROOVY-11313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820513#comment-17820513
]
Jochen Theodorou commented on GROOVY-11313:
---
[~emilles] Looks like I forgot to make an example with owner comming from
another closure:
{code:Java}
def cl = { owner -> {return {owner}}}
assert cl(1)() == 1
{code}
The inner owner reference is not supposed to be resolved against the owner
getter of the outer closure, not even if owner comes from more outside, as long
as owner is a local variable. And of course I also expect this to work
(independent of the resolving strategy):
{code:Java}
def foo = 'bar'
def cl = { return {return {foo}}}
assert cl(1)() == foo
{code}
There should be no getter created for foo, since foo is a context variable
encapsulated in a holder, given to the closure at construction time. Therefore
I do not understand the change you did for this. But that is not your fault - I
see those getter actually exist for a longer time already. But really they
should not, exactly because of the name clash. There cannot be a getOwner
method for owner as property of the Closure and for owner as referenced local
variable. Either those getter are required, then this name clash is a problem
and your fix is probably a good temporary solution... or the getter are not
required, then we should not create them.
> Closure owner seems to be overwritten
> -
>
> Key: GROOVY-11313
> URL: https://issues.apache.org/jira/browse/GROOVY-11313
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.18
>Reporter: Tomás Crespo García
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.21, 4.0.19, 5.0.0-alpha-6
>
>
> I had a Groovy script with nested closures that used {{owner}} as the name of
> the outer closure's parameter (even though {{owner}} might conflict with the
> closure [owner|https://groovy-lang.org/closures.html#_owner_of_a_closure]):
> {code:java}
> import groovy.sql.GroovyRowResult
>
> runAll()
>
> void runAll() {
> List owners = [new GroovyRowResult([user_id: 1])]
> List pets = [new GroovyRowResult([id: 1])]
>
> owners.each { owner ->
> myMethod(1)
> pets.each { pet ->
> myMethod(2)
> println(owner.user_id)
> }
> }
> }
>
> void myMethod(int i) {
> println("Running my method ${i}")
> } {code}
> The same script worked as I expected in Groovy 3.x, but, in Groovy 4.0.18, it
> fails with the following error:
> {code:java}
> Exception in thread "main" groovy.lang.MissingPropertyException: No such
> property: myMethod for class: groovy.sql.GroovyRowResult
> at groovy.sql.GroovyRowResult.getProperty(GroovyRowResult.java:55)
> at groovy.sql.GroovyRowResult.get(GroovyRowResult.java:157)
> at groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1389)
> at groovy.lang.MetaClassImpl.doInvokeMethod(MetaClassImpl.java:1335)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1088)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1007)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:645)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:628)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeOnDelegationObjects(ClosureMetaClass.java:391)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:328)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1007)
> at
> org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:321)
> at Script1$_runAll_closure1$_closure2.doCall(Script1.groovy:16)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:343)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:328) {code}
> It seems that {{myMethod}} in the inner closure is trying to get resolved as
> a property of {{{}GroovyRowResult{}}}, which is the type of the {{owner}}
> parameter of the outer closure. The moment I rename {{owner}} to something
> else or transform the inner {{each}} to a {{for}} loop, the script works. It
> doesn't fail either if I don't try to access any property of {{owner}} inside
> the inner closure (such as {{{}owner.user_id{}}}).
>
> Is this expected?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11301) References to inaccesible methods with static compilation leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820103#comment-17820103
]
Jochen Theodorou commented on GROOVY-11301:
---
This can also be reproduced using the compilestatic annotation. I compared the
java generated output with what we create and found that there seems to be a
difference in what we give the lambda factory. In Java we have this helper
method:
{code:Java}
private static java.lang.String lambda$main$0();
descriptor: ()Ljava/lang/String;
flags: (0x100a) ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC
Code:
stack=1, locals=0, args_size=0
0: invokestatic #3 // Method
Test$A.m:()Ljava/lang/String;
3: areturn
LineNumberTable:
line 8: 0
{code} and a bootstrap method like this {code:Java}
#22 REF_invokeStatic
java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
Method arguments:
#23 ()Ljava/lang/Object;
#24 REF_invokeStatic Test.lambda$main$0:()Ljava/lang/String;
#25 ()Ljava/lang/String;
{code}
as can be seen, the method handle reference to the local helper method is given
to LambdaMetafactory.
What we do is:
{code:Java}
#45 REF_invokeStatic
java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
Method arguments:
#30 ()Ljava/lang/Object;
#37 REF_invokeStatic Test$A.m:()Ljava/lang/String;
#38 ()Ljava/lang/String;
{code}
which is trying to give a handle to Test.A#m() to the LambdaFactory. Since we
use the general public Lookup object access to there is forbidden. We need to
either use a lookup created from the class itself (not sure if Test is enough
or if Test.A is required) or the helper method.
> References to inaccesible methods with static compilation leads to runtime
> error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
> Attachments: Test$A.class, Test.class
>
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11301) References to inaccesible methods with static compilation leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17819822#comment-17819822
]
Jochen Theodorou commented on GROOVY-11301:
---
Ok, thanks. I can reproduce the issue correctly now. I think the issue is that
we use the wrong lookup object or this. [~daniel_sun]?
> References to inaccesible methods with static compilation leads to runtime
> error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
> Attachments: Test$A.class, Test.class
>
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11313) Closure owner seems to be overwritten
[
https://issues.apache.org/jira/browse/GROOVY-11313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17819818#comment-17819818
]
Jochen Theodorou commented on GROOVY-11313:
---
in { owner -> owner} owner refers to a local variable named owner, shadowing
the getOwner. local variables take precedence, because of lexical scope. If you
see a Closure as class then you expect the same rules to apply:
{code:Java}
class X {
def getFoo(){1}
def m(){foo}
def m2(foo){foo}
def m3(){
def foo = 42
return foo
}
}
assert new X().m() == 1
assert new X().m2("foo") == "foo"
assert new X().m3() == 42
{code}
Following these examples I see not why owner in a Closure should get resolved
to getOwner if there is a local variable of the same name.
{code:Java}
def owner = 1
def cl = {owner}
assert cl() == 1
def cl2 = {return {owner}}
assert cl2()() == 1
{code}
And frankly I even expect this:
{code:Java}
class X {
def owner = 22
def m() {return {owner}}
}
assert new X().m() == 22
{code}
But I am aware that this probably never worked. And changing it would break
things now. Out of delegate, owner and thisObject there is really only delegate
the one that can change and might not be available through other means. So from
inside a Closure we would really only to take care of that. But in the end the
MOP gets in the way for this last one. But the others are supposed to work.
> Closure owner seems to be overwritten
> -
>
> Key: GROOVY-11313
> URL: https://issues.apache.org/jira/browse/GROOVY-11313
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.18
>Reporter: Tomás Crespo García
>Priority: Major
>
> I had a Groovy script with nested closures that used {{owner}} as the name of
> the outer closure's parameter (even though {{owner}} might conflict with the
> closure [owner|https://groovy-lang.org/closures.html#_owner_of_a_closure]):
> {code:java}
> import groovy.sql.GroovyRowResult
>
> runAll()
>
> void runAll() {
> List owners = [new GroovyRowResult([user_id: 1])]
> List pets = [new GroovyRowResult([id: 1])]
>
> owners.each { owner ->
> myMethod(1)
> pets.each { pet ->
> myMethod(2)
> println(owner.user_id)
> }
> }
> }
>
> void myMethod(int i) {
> println("Running my method ${i}")
> } {code}
> The same script worked as I expected in Groovy 3.x, but, in Groovy 4.0.18, it
> fails with the following error:
> {code:java}
> Exception in thread "main" groovy.lang.MissingPropertyException: No such
> property: myMethod for class: groovy.sql.GroovyRowResult
> at groovy.sql.GroovyRowResult.getProperty(GroovyRowResult.java:55)
> at groovy.sql.GroovyRowResult.get(GroovyRowResult.java:157)
> at groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1389)
> at groovy.lang.MetaClassImpl.doInvokeMethod(MetaClassImpl.java:1335)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1088)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1007)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:645)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:628)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeOnDelegationObjects(ClosureMetaClass.java:391)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:328)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1007)
> at
> org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:321)
> at Script1$_runAll_closure1$_closure2.doCall(Script1.groovy:16)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:343)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:328) {code}
> It seems that {{myMethod}} in the inner closure is trying to get resolved as
> a property of {{{}GroovyRowResult{}}}, which is the type of the {{owner}}
> parameter of the outer closure. The moment I rename {{owner}} to something
> else or transform the inner {{each}} to a {{for}} loop, the script works. It
> doesn't fail either if I don't try to access any property of {{owner}} inside
> the inner closure (such as {{{}owner.user_id{}}}).
>
> Is this expected?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11301) References to inaccesible methods with static compilation leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818296#comment-17818296
]
Jochen Theodorou edited comment on GROOVY-11301 at 2/18/24 3:02 PM:
[~theosot] sorry for the delay... the problem is that the stack trace does not
show anything strange so far.. You are also not compiling as named module, but
even then they would be in the same module so module access should not matter.
I think there are currently only two things left. (1) try a newer/different JDK
version. (2) upload the class files so I can compare it with what I get locally.
was (Author: blackdrag):
[~theosot] sorry for the delay... the problem is that the stack trace does not
show anything strange so far.. You are also not compiling as named module, but
even then they would be in the same module so module access should not matter.
I think there are currently only two things left. (1) try a newer/different JDK
version. (2) upload the class file so I can compare it with what I get locally.
> References to inaccesible methods with static compilation leads to runtime
> error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11301) References to inaccesible methods with static compilation leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818296#comment-17818296
]
Jochen Theodorou commented on GROOVY-11301:
---
[~theosot] sorry for the delay... the problem is that the stack trace does not
show anything strange so far.. You are also not compiling as named module, but
even then they would be in the same module so module access should not matter.
I think there are currently only two things left. (1) try a newer/different JDK
version. (2) upload the class file so I can compare it with what I get locally.
> References to inaccesible methods with static compilation leads to runtime
> error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GROOVY-11312) Short notation for Boolean methods fails
[
https://issues.apache.org/jira/browse/GROOVY-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou closed GROOVY-11312.
-
Resolution: Won't Fix
This is an intentional change from GROOVY-10708 and related issues.
> Short notation for Boolean methods fails
>
>
> Key: GROOVY-11312
> URL: https://issues.apache.org/jira/browse/GROOVY-11312
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.18
>Reporter: Alan
>Assignee: Jochen Theodorou
>Priority: Major
>
> The following code succeeds
>
> {code:java}
> class Hello {
> public static boolean isBye() {
> return true
> }
> }
> Hello.bye {code}
>
> But the following fails
> {code:java}
> class Hello {
> public static Boolean isBye() {
> return true
> }
> }
> Hello.bye {code}
> with the exception
> {code:java}
> groovy.lang.MissingPropertyException: No such property: bye for class: Hello
> {code}
> Same is true when trying to access instance methods.
>
> Notice the only difference is the return type: Boolean vs boolean
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GROOVY-11312) Short notation for Boolean methods fails
[
https://issues.apache.org/jira/browse/GROOVY-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou reassigned GROOVY-11312:
-
Assignee: Jochen Theodorou
> Short notation for Boolean methods fails
>
>
> Key: GROOVY-11312
> URL: https://issues.apache.org/jira/browse/GROOVY-11312
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.18
>Reporter: Alan
>Assignee: Jochen Theodorou
>Priority: Major
>
> The following code succeeds
>
> {code:java}
> class Hello {
> public static boolean isBye() {
> return true
> }
> }
> Hello.bye {code}
>
> But the following fails
> {code:java}
> class Hello {
> public static Boolean isBye() {
> return true
> }
> }
> Hello.bye {code}
> with the exception
> {code:java}
> groovy.lang.MissingPropertyException: No such property: bye for class: Hello
> {code}
> Same is true when trying to access instance methods.
>
> Notice the only difference is the return type: Boolean vs boolean
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11311) Groovy Closure not retaining param annotations, but only for the default single object param case
[
https://issues.apache.org/jira/browse/GROOVY-11311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817182#comment-17817182
]
Jochen Theodorou commented on GROOVY-11311:
---
I am a bit surprised because you check the call method. I was under the
impression we generate only a doCall method, which I am sure is happening...
yes, verified that.
Dow anyone remember why we decided to create call-methods additionally to the
doCall-methods?
> Groovy Closure not retaining param annotations, but only for the default
> single object param case
> -
>
> Key: GROOVY-11311
> URL: https://issues.apache.org/jira/browse/GROOVY-11311
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.8, 4.0.4
>Reporter: Val E
>Priority: Major
> Attachments: ClosureAnnotationsTest.groovy
>
>
> In trying to process Groovy closure param annotations, via Java reflection, I
> realized that there is one narrow case where the param annotations are not
> preserved in the generated call method.
> This happens only for the case of a single Object param type. All other
> variations retain the annotation, it can be a single param of a different
> type, or multiple params of Object type. I think this may have something to
> do with handling the default 'it' param
> ex:
> {code:java}
> {@TESTANNO def x-> } //wont retain @TESTANNO
> {code}
> {code:java}
> {@TESTANNO Object x-> } //wont retain @TESTANNO
> {code}
> {code:java}
> {@TESTANNO Integer x-> } //will retain @TESTANNO
> {code}
> {code:java}
> {@TESTANNO def x, @TESTANNO def y-> }//will retain @TESTANNO on both x and y
> {code}
>
> Attached a basic groovy script to demonstrate.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11301) References to inaccesible methods leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812410#comment-17812410
]
Jochen Theodorou commented on GROOVY-11301:
---
[~theosot] for me it does not only compile, it does also execute without error.
Could you please provide the full stack trace and your Java version?
> References to inaccesible methods leads to runtime error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11301) References to inaccesible methods leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812393#comment-17812393
]
Jochen Theodorou edited comment on GROOVY-11301 at 1/30/24 4:16 PM:
Even though Test.A::m is a private method, A is an inner class of Test and
thus Test would have access to the method in Java. Also this does not fail in
groovy to any 3 or 4 version of Groovy. It also works for Groovy 5 alpha 1. If
it fails for master it must be something more recent
Trying out master with 191231a832efd2e2fc49391c01f8d176944d68e3 I can also not
reproduce the issue
was (Author: blackdrag):
Even though Test.A::m is a private method, A is an inner class of Test and
thus Test would have access to the method in Java. Also this does not fail in
groovy to any 3 or 4 version of Groovy. It also works for Groovy 5 alpha 1. If
it fails for master it must be something more recent
> References to inaccesible methods leads to runtime error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11301) References to inaccesible methods leads to runtime error
[
https://issues.apache.org/jira/browse/GROOVY-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812393#comment-17812393
]
Jochen Theodorou commented on GROOVY-11301:
---
Even though Test.A::m is a private method, A is an inner class of Test and
thus Test would have access to the method in Java. Also this does not fail in
groovy to any 3 or 4 version of Groovy. It also works for Groovy 5 alpha 1. If
it fails for master it must be something more recent
> References to inaccesible methods leads to runtime error
>
>
> Key: GROOVY-11301
> URL: https://issues.apache.org/jira/browse/GROOVY-11301
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
>
> I have the following ill-typed program
> {code}
> import java.util.function.Supplier;
> public class Test {
> static class A {
> private static String m() { return null; }
> }
> public static void main(String[] args) {
> Supplier x = A::m;
> }
> }
> {code}
> h3. Actual behaviour
> The compiler accepts the program, but I receive the following runtime error,
> because I access a private method.
> {code}
> Exception in thread "main" java.lang.IllegalAccessError: class Test tried to
> access private method 'java.lang.String Test$A.m()' (Test and Test$A are in
> unnamed module of loader 'app')
> at Test.main(groovy51.groovy:9)
> {code}
> h3. Expected behavior
> The program should have been rejected by the compiler.
> Tested against master (commit: 191231a832efd2e2fc49391c01f8d176944d68e3)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11229) Support pattern matching and destructure
[ https://issues.apache.org/jira/browse/GROOVY-11229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806751#comment-17806751 ] Jochen Theodorou commented on GROOVY-11229: --- [~emilles][~daniel_sun] The de-structuring also give access to x and y? That is something still available through o or p of course, but the jep441 also targets further nesting. So yes, the Java16 version is a bit useless to us, the Java21 version though I see differently. Well... to be frank I find this feature massively overrated. And there is more coming of this in the future from Java... > Support pattern matching and destructure > > > Key: GROOVY-11229 > URL: https://issues.apache.org/jira/browse/GROOVY-11229 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Priority: Major > > See also: > [https://openjdk.org/jeps/394] > [https://openjdk.java.net/jeps/440] > [https://openjdk.org/jeps/441] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.
[ https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804416#comment-17804416 ] Jochen Theodorou commented on GROOVY-11271: --- [~emilles] See https://blog.mrhaki.com/2013/11/groovy-goodness-cache-methods.html. in case of for example @Memoized(maxCacheSize = 2) a LRU of size 2 is used. If now many threads read the memoized results and change the order of what is last recently used, this can result in the described problem. > ConcurrentCommonCache causes memory leaks. > -- > > Key: GROOVY-11271 > URL: https://issues.apache.org/jira/browse/GROOVY-11271 > Project: Groovy > Issue Type: Bug > Components: ast builder >Affects Versions: 4.0.7 >Reporter: cong yang >Priority: Critical > > ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a > thread-safe data structure. However, CommonCache uses the underlying > LinkedHashMap, which causes conflicts when using the LRU algorithm because > the LinkedHashMap.get method modifies the internal linked list. This > conflicts with the read lock used by the get method in ConcurrentCommonCache > when multiple threads access it. Due to multithreading conflicts, the maximum > cache size of 64 becomes ineffective, ultimately causing memory leaks. > Additionally, we have already encountered memory leaks in our production > environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.
[ https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804244#comment-17804244 ] Jochen Theodorou commented on GROOVY-11271: --- [~daniel_sun] This is correct, but then it is not much better than a synchronized collection > ConcurrentCommonCache causes memory leaks. > -- > > Key: GROOVY-11271 > URL: https://issues.apache.org/jira/browse/GROOVY-11271 > Project: Groovy > Issue Type: Bug > Components: ast builder >Affects Versions: 4.0.7 >Reporter: cong yang >Priority: Critical > > ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a > thread-safe data structure. However, CommonCache uses the underlying > LinkedHashMap, which causes conflicts when using the LRU algorithm because > the LinkedHashMap.get method modifies the internal linked list. This > conflicts with the read lock used by the get method in ConcurrentCommonCache > when multiple threads access it. Due to multithreading conflicts, the maximum > cache size of 64 becomes ineffective, ultimately causing memory leaks. > Additionally, we have already encountered memory leaks in our production > environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.
[ https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804198#comment-17804198 ] Jochen Theodorou commented on GROOVY-11271: --- to add ore details: https://github.com/apache/groovy/blob/5a3cf7c86feacc6f257cc72942e6ef8789920cf4/src/main/java/org/codehaus/groovy/runtime/memoize/CommonCache.java#L67 This creates a CommonCache where accessOrder is set to true and then any get call on the underlying LinkedHashMap can cause a write change, not covered appropriately by the checks. [~sunlan] This looks like a bigger change will be required to fix this > ConcurrentCommonCache causes memory leaks. > -- > > Key: GROOVY-11271 > URL: https://issues.apache.org/jira/browse/GROOVY-11271 > Project: Groovy > Issue Type: Bug > Components: ast builder >Affects Versions: 4.0.7 >Reporter: cong yang >Priority: Critical > > ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a > thread-safe data structure. However, CommonCache uses the underlying > LinkedHashMap, which causes conflicts when using the LRU algorithm because > the LinkedHashMap.get method modifies the internal linked list. This > conflicts with the read lock used by the get method in ConcurrentCommonCache > when multiple threads access it. Due to multithreading conflicts, the maximum > cache size of 64 becomes ineffective, ultimately causing memory leaks. > Additionally, we have already encountered memory leaks in our production > environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11263) Analyze dead code
[
https://issues.apache.org/jira/browse/GROOVY-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17801466#comment-17801466
]
Jochen Theodorou commented on GROOVY-11263:
---
[~daniel_sun] "It's better to avoid such dead code." I agree that it does not
make sense here and that in general you do not want to have that. But I do find
it quite nice to be able to just "return" when testing out things and not
having to comment out all the code
> Analyze dead code
> -
>
> Key: GROOVY-11263
> URL: https://issues.apache.org/jira/browse/GROOVY-11263
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Priority: Major
>
> Groovy allows dead code after {{return}}, e.g.
> {code:java}
> def m() {
>return
>def a = 1
> }
> {code}
> It's better to avoid such dead code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11230) ProxyGenerator creates a lot of AtomicReference instances regardless of "groovy.adapter.cache.default.size" setting
[ https://issues.apache.org/jira/browse/GROOVY-11230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787643#comment-17787643 ] Jochen Theodorou commented on GROOVY-11230: --- [~emilles] your change looks on first glance like you replace the LRUCache with a LinkedHashMap. I advice against this as LinkedHashMap is not thread safe and this scenario looks like it could have data races. > ProxyGenerator creates a lot of AtomicReference instances regardless of > "groovy.adapter.cache.default.size" setting > --- > > Key: GROOVY-11230 > URL: https://issues.apache.org/jira/browse/GROOVY-11230 > Project: Groovy > Issue Type: Improvement > Components: groovy-runtime >Reporter: Eric Milles >Assignee: Eric Milles >Priority: Major > > ProxyGenerator uses LRUCache which uses ConcurrentLinkedHashMap. This > creates a 2d array of AtomicReference that is sized based on number of > processor cores, not cache sizing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-8299) Generate bytecode for interface with default, private and static methods
[ https://issues.apache.org/jira/browse/GROOVY-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786021#comment-17786021 ] Jochen Theodorou commented on GROOVY-8299: -- What is missing is "GROOVY-10060 Support static & private interface methods". As for the default methods itself, they are now the same as in Java. This includes Java using them from Groovy or reverse, Groovy/Java calling them defined in Java or Groovy and joint compilation. > Generate bytecode for interface with default, private and static methods > > > Key: GROOVY-8299 > URL: https://issues.apache.org/jira/browse/GROOVY-8299 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Daniel Sun >Assignee: Jochen Theodorou >Priority: Major > Labels: default-methods > Time Spent: 8h > Remaining Estimate: 0h > > Currently the interface with default methods is based on the traits, we > should provide real default methods introduced by Java8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GROOVY-11222) Cannot parse methods that return types starting with lowercase letters
[
https://issues.apache.org/jira/browse/GROOVY-11222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou closed GROOVY-11222.
-
Resolution: Won't Fix
We decided to make a breaking change in Groovy 4 here. Thus this is no bug and
expected. The GSL only talks about identifiers, not class names. I guess it
needs an update here. the reason for this change is that there are problems
with the name resolution leading to very long compilation times in which the
compiler basically looks for non-existing classes. This is because for example
"def foo = String" is valid in Groovy. It is not the only example causing
problems, just the most easy to understand. Using 3rd party libraries or
generated code in groovy, that is not following the conventions can be worked
around. Groovy supports import aliases. Thus you can do "import
com.generated.something.foo as Foo" and if you then do "def foo = Foo" it will
resolve to the class com.generated.something.foo. This alias can be used
anywhere, also in implements or extends.
> Cannot parse methods that return types starting with lowercase letters
> --
>
> Key: GROOVY-11222
> URL: https://issues.apache.org/jira/browse/GROOVY-11222
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 5.0.0-alpha-2, 4.0.15
>Reporter: Lyuben Atanasov
>Assignee: Jochen Theodorou
>Priority: Major
>
> According to the language specification, it is allowed to have class names
> that start with a lowercase letter:
> {quote}Identifiers start with a letter, a dollar or an underscore. They
> cannot start with a number.
> A letter can be in the following ranges:
> * 'a' to 'z' (lowercase ascii letter)
> * 'A' to 'Z' (uppercase ascii letter)
> * '\u00C0' to '\u00D6'
> * '\u00D8' to '\u00F6'
> * '\u00F8' to '\u00FF'
> * '\u0100' to '\uFFFE'{quote}
> This is the same as in Java.
> Defining types that start with lowercase letters works fine. As far as I can
> tell, I can also use such types as method arguments. What I cannot do, is to
> have methods that return types starting with lowercase letters.
> Here's a failing example:
> {code:groovy}
> public class person {
> private String firstName;
> private String lastName;
>
> person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public person createPerson(String firstName, String lastName) {
> return new person(firstName, lastName);
> }
>
> }
> {code}
> When parsing this code, it fails with the following error:
> {noformat}
> Script_b41cda4fe6804e170255542089871d79.groovy: 13: Unexpected input: '(' @
> line 13, column 31.
>public person createPerson(String firstName, String lastName) {
> ^
> 1 error
> {noformat}
> If I change the class name to start with a capital letter, everything works:
> {code:groovy}
> public class Person {
> private String firstName;
> private String lastName;
>
> Person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public Person createPerson(String firstName, String lastName) {
> return new Person(firstName, lastName);
> }
>
> }
> {code}
> So it looks like there is a discrepancy between the language specification
> and the grammar definition. I looked into the grammar and managed to extract
> the following relevant lines from it, which should make the issue evident:
> {code:java}
> methodDeclaration[int t, int ct]
> : modifiersOpt typeParameters? (returnType[$ct] nls)?
> methodName formalParameters
> (
> DEFAULT nls elementValue
> |
> (nls THROWS nls qualifiedClassNameList)?
> (nls methodBody)?
> )?
> ;
>
> returnType[int ct]
> :
> standardType
> | VOID
> ;
>
> standardType
> options { baseContext = type; }
> : annotationsOpt
> (
> primitiveType
> |
> standardClassOrInterfaceType
> )
> emptyDimsOpt
> ;
>
> standardClassOrInterfaceType
> options { baseContext = classOrInterfaceType; }
> : qualifiedStandardClassName typeArguments?
> ;
>
> qualifiedStandardClassName
> : qualifiedNameElements className (DOT className)*
> ;
>
> className
> : CapitalizedIdentifier
> ;
> {code}
> Here, it is allowed only to have a CapitalizedIdentifier as the class name.
> There is an obvious simple fix:
> {code:java}
> className
> : CapitalizedIdentifier | Identifier
> ;
> {code}
> This should make the parser
[jira] [Assigned] (GROOVY-11222) Cannot parse methods that return types starting with lowercase letters
[
https://issues.apache.org/jira/browse/GROOVY-11222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou reassigned GROOVY-11222:
-
Assignee: Jochen Theodorou
> Cannot parse methods that return types starting with lowercase letters
> --
>
> Key: GROOVY-11222
> URL: https://issues.apache.org/jira/browse/GROOVY-11222
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 5.0.0-alpha-2, 4.0.15
>Reporter: Lyuben Atanasov
>Assignee: Jochen Theodorou
>Priority: Major
>
> According to the language specification, it is allowed to have class names
> that start with a lowercase letter:
> {quote}Identifiers start with a letter, a dollar or an underscore. They
> cannot start with a number.
> A letter can be in the following ranges:
> * 'a' to 'z' (lowercase ascii letter)
> * 'A' to 'Z' (uppercase ascii letter)
> * '\u00C0' to '\u00D6'
> * '\u00D8' to '\u00F6'
> * '\u00F8' to '\u00FF'
> * '\u0100' to '\uFFFE'{quote}
> This is the same as in Java.
> Defining types that start with lowercase letters works fine. As far as I can
> tell, I can also use such types as method arguments. What I cannot do, is to
> have methods that return types starting with lowercase letters.
> Here's a failing example:
> {code:groovy}
> public class person {
> private String firstName;
> private String lastName;
>
> person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public person createPerson(String firstName, String lastName) {
> return new person(firstName, lastName);
> }
>
> }
> {code}
> When parsing this code, it fails with the following error:
> {noformat}
> Script_b41cda4fe6804e170255542089871d79.groovy: 13: Unexpected input: '(' @
> line 13, column 31.
>public person createPerson(String firstName, String lastName) {
> ^
> 1 error
> {noformat}
> If I change the class name to start with a capital letter, everything works:
> {code:groovy}
> public class Person {
> private String firstName;
> private String lastName;
>
> Person(String firstName, String lastName) {
> this.firstName = firstName;
> this.lastName = lastName;
> }
> }
> public class PersonFactory {
> public Person createPerson(String firstName, String lastName) {
> return new Person(firstName, lastName);
> }
>
> }
> {code}
> So it looks like there is a discrepancy between the language specification
> and the grammar definition. I looked into the grammar and managed to extract
> the following relevant lines from it, which should make the issue evident:
> {code:java}
> methodDeclaration[int t, int ct]
> : modifiersOpt typeParameters? (returnType[$ct] nls)?
> methodName formalParameters
> (
> DEFAULT nls elementValue
> |
> (nls THROWS nls qualifiedClassNameList)?
> (nls methodBody)?
> )?
> ;
>
> returnType[int ct]
> :
> standardType
> | VOID
> ;
>
> standardType
> options { baseContext = type; }
> : annotationsOpt
> (
> primitiveType
> |
> standardClassOrInterfaceType
> )
> emptyDimsOpt
> ;
>
> standardClassOrInterfaceType
> options { baseContext = classOrInterfaceType; }
> : qualifiedStandardClassName typeArguments?
> ;
>
> qualifiedStandardClassName
> : qualifiedNameElements className (DOT className)*
> ;
>
> className
> : CapitalizedIdentifier
> ;
> {code}
> Here, it is allowed only to have a CapitalizedIdentifier as the class name.
> There is an obvious simple fix:
> {code:java}
> className
> : CapitalizedIdentifier | Identifier
> ;
> {code}
> This should make the parser work in the same way as expected after reading
> the language spec. I am not sure, however, whether this won't break anything
> else.
> In order to avoid any unnecessary discussions about naming conventions: I am
> aware that by convention it is not OK to start a type name with anything
> other than a capital letter, but there are valid cases where it is desired to
> have such names (e.g. generated code based on external input, DSLs).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11204) Incorrect overload selection for subclasses
[
https://issues.apache.org/jira/browse/GROOVY-11204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781840#comment-17781840
]
Jochen Theodorou commented on GROOVY-11204:
---
I actually wonder if that was a good decision. I think the problem back then
was that if you have foo(C1) and foo(I1) where a class implements Interface I1
and extends C1, you normally want to have foo(I1). Java would give here a
method selection error. But In Groovy we are working with the runtime type, not
the compile time type, which makes a bit more difficult. Its probably not very
obvious with this explanation
> Incorrect overload selection for subclasses
> ---
>
> Key: GROOVY-11204
> URL: https://issues.apache.org/jira/browse/GROOVY-11204
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 4.0.12
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Major
>
> I'm writing a Spring Security configurer and trying to add it to my
> configuration using {{apply(C)}}, but the Groovy compiler selects the wrong
> overload, and necessary initialization is not performed.
> {code:groovy}
> @Grab('org.springframework.security:spring-security-config:5.7.11')
> import
> org.springframework.security.config.annotation.authentication.builders.*
> import org.springframework.security.config.annotation.web.configurers.*
> import org.springframework.security.config.annotation.web.builders.*
> @Grab('org.springframework.security:spring-security-web:5.7.11')
> import org.springframework.security.web.*
> @Grab('javax.servlet:servlet-api:2.5')
> // AbstractHttpConfigurer extends SecurityConfigurerAdapter
> class MyConfigurer extends AbstractHttpConfigurer
> {}
> SecurityFilterChain securityFilterChain(HttpSecurity http) {
> http.apply(new MyConfigurer())
> // ^ should select apply(SecurityConfigurerAdapter), but selects
> apply(SecurityConfigurer)
> .and()
> .build()
> }
> securityFilterChain(new HttpSecurity({ }, new AuthenticationManagerBuilder({
> }), [:]))
> {code}
> This is probably a result of an edge case in the generics, since the bounds
> on the overloads are determined by type parameters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11208) No parse error for interface method with default value
[
https://issues.apache.org/jira/browse/GROOVY-11208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780603#comment-17780603
]
Jochen Theodorou commented on GROOVY-11208:
---
That syntax looks wrong. What bytecode is produced from that?
> No parse error for interface method with default value
> --
>
> Key: GROOVY-11208
> URL: https://issues.apache.org/jira/browse/GROOVY-11208
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr4
>Reporter: Eric Milles
>Priority: Major
>
> I noticed this syntax mentioned here:
> https://groovy.apache.org/wiki/GEP-12.html
> Is this supposed to be valid for some case or is it defunct?
> {code:groovy}
> interface I {
> def m() default { 1 }
> }
> {code}
> It does not produce any parser or compiler errors. But I don't think the
> default value saved in {{MethodNode}} is used for anything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11193) Methods referenced by super cannot be found and are not executed
[
https://issues.apache.org/jira/browse/GROOVY-11193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17778786#comment-17778786
]
Jochen Theodorou commented on GROOVY-11193:
---
[~emilles] I am not so much worried about having one version of Groovy for
compilation and another for test execution, I am worried about a library
compiled with Groovy 2 or 3 no longer working in Groovy 4. For smoothing this
over: How about a new method in ScriptBytecodeInterface like
invokeMethodOnSuperN2. I am not fully aware of what you changed. But when I
implemented the calls for default methods I noticed some "strange" (aka logic
that looks unfamiliar even though it should have been) code for the caller
class. My goal would actually be to replace the calls for super in Groovy 5
with invokedynamic.
> Methods referenced by super cannot be found and are not executed
>
>
> Key: GROOVY-11193
> URL: https://issues.apache.org/jira/browse/GROOVY-11193
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Marek Parfianowicz
>Assignee: Eric Milles
>Priority: Major
> Attachments: bug.zip
>
>
> When one method calls another method from a parent class via {{super}}
> keyword, the code is not executed at all.
> I tested this in version 4.0.0 and 4.0.14 - in both it fails. (x)
> It works correctly in 3.0.19. (/)
> It also fails in 2.5.23, but with a runtime exception -
> "{color:#172b4d}java.lang.AbstractMethodError" (x){color}
> Code to reproduce:
>
> {code:java}
> class MyClassBase {
> void setUp() {
> System.out.println("Called MyTestBase.setUp")
> }
> }{code}
>
> {code:java}
> class MyClass extends MyClassBase {
> void setUp() {
> super.setUp()
> System.out.println("Called MyTest.setUp")
> }
> static void main(String[] args) {
> System.out.println("About to create MyClass")
> MyClass my = new MyClass();
> my.setUp()
> }
> } {code}
> Output for Groovy 4.0.14:
> {noformat}
> [INFO] --- exec-maven-plugin:3.0.0:java (default) @ bug ---
> About to create MyClass
> [WARNING]
> groovy.lang.MissingMethodException: No signature of method:
> MyClassBase.setUp() is applicable for argument types: () values: []
> Possible solutions: setUp(), getAt(java.lang.String),
> tap(groovy.lang.Closure), sleep(long), sleep(long, groovy.lang.Closure),
> dump()
> 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 MyClass.setUp (MyClass.groovy:3)
> at MyClass$setUp.call (Unknown Source)
> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall
> (CallSiteArray.java:45)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call
> (AbstractCallSite.java:125)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call
> (AbstractCallSite.java:130)
> at MyClass.main (MyClass.groovy:10)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:254)
> at java.lang.Thread.run (Thread.java:750)
> {noformat}
> Please see the attached bug.zip sample project.
>
> Workaround:
> Use {{@CompileStatic}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11193) Methods referenced by super cannot be found and are not executed
[
https://issues.apache.org/jira/browse/GROOVY-11193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17778163#comment-17778163
]
Jochen Theodorou commented on GROOVY-11193:
---
[~emilles]is that only for groovy-eclipse or also with normal Groovy? If this
is in general - did we mention this in breaking changes?
> Methods referenced by super cannot be found and are not executed
>
>
> Key: GROOVY-11193
> URL: https://issues.apache.org/jira/browse/GROOVY-11193
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Marek Parfianowicz
>Assignee: Eric Milles
>Priority: Major
> Attachments: bug.zip
>
>
> When one method calls another method from a parent class via {{super}}
> keyword, the code is not executed at all.
> I tested this in version 4.0.0 and 4.0.14 - in both it fails. (x)
> It works correctly in 3.0.19. (/)
> It also fails in 2.5.23, but with a runtime exception -
> "{color:#172b4d}java.lang.AbstractMethodError" (x){color}
> Code to reproduce:
>
> {code:java}
> class MyClassBase {
> void setUp() {
> System.out.println("Called MyTestBase.setUp")
> }
> }{code}
>
> {code:java}
> class MyClass extends MyClassBase {
> void setUp() {
> super.setUp()
> System.out.println("Called MyTest.setUp")
> }
> static void main(String[] args) {
> System.out.println("About to create MyClass")
> MyClass my = new MyClass();
> my.setUp()
> }
> } {code}
> Output for Groovy 4.0.14:
> {noformat}
> [INFO] --- exec-maven-plugin:3.0.0:java (default) @ bug ---
> About to create MyClass
> [WARNING]
> groovy.lang.MissingMethodException: No signature of method:
> MyClassBase.setUp() is applicable for argument types: () values: []
> Possible solutions: setUp(), getAt(java.lang.String),
> tap(groovy.lang.Closure), sleep(long), sleep(long, groovy.lang.Closure),
> dump()
> 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 MyClass.setUp (MyClass.groovy:3)
> at MyClass$setUp.call (Unknown Source)
> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall
> (CallSiteArray.java:45)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call
> (AbstractCallSite.java:125)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call
> (AbstractCallSite.java:130)
> at MyClass.main (MyClass.groovy:10)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:254)
> at java.lang.Thread.run (Thread.java:750)
> {noformat}
> Please see the attached bug.zip sample project.
>
> Workaround:
> Use {{@CompileStatic}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11194) groovyc missing features from the library compiler
[
https://issues.apache.org/jira/browse/GROOVY-11194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775756#comment-17775756
]
Jochen Theodorou commented on GROOVY-11194:
---
Actually I think we are missing quite a bit documentation in that area.
--configscript can be used to pass a comma separated list of config scripts to
the compiler. Those are groovy scripts used to configure the compiler. Sigh...
I think one of the best references would be
https://blog.mrhaki.com/2016/01/groovy-goodness-customising-groovy.html We
really really miss doccumentation here! Anyway... the script is basically a
normal groovy script which has "configuration" as the current compiler
configuration object (see CompilerConfiguration) and you can set here the
values you are missing. There are additional helper methods like
withConfiguration to make some things a bit more easy, but I think you won't
need those.
Normally I would instead suggest to extend the command line interface to
support these options as has been done for GroovyMain. But then this would
maybe not be available for all the versions you intend to target. The config
script solution should work from Groovy 2.4.0+
> groovyc missing features from the library compiler
> --
>
> Key: GROOVY-11194
> URL: https://issues.apache.org/jira/browse/GROOVY-11194
> Project: Groovy
> Issue Type: New Feature
> Components: command line processing, Compiler
>Affects Versions: 3.0.19, 5.0.0-alpha-2, 4.0.15
>Reporter: Benjamin Marwell
>Priority: Critical
>
> Hello groovy team,
> no version of the groovy distribution supports any of those features on the
> {{groovyc}} command line, which are available when invoking the groovy
> compiler via library means:
> * setDebug( boolean )
> * setVerbose( boolean )
> * setWarningLevel( int )
> * setTolerance( int )
> * invokeDynamic via optimizationOptions.put("indy", true);
> optimizationOptions.put("int", false);
> * parallel Parsing via optimizationOptions.put("parallelParse", true);
> This is important when gplus-maven-plugin shall run in fork mode. Draft PR:
> https://github.com/groovy/GMavenPlus/pull/283
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11194) groovyc missing features from the library compiler
[
https://issues.apache.org/jira/browse/GROOVY-11194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775594#comment-17775594
]
Jochen Theodorou commented on GROOVY-11194:
---
verbose is unused btw.
The only way to set this kind of options for the FilesystemCompiler right now
is using a config script.
> groovyc missing features from the library compiler
> --
>
> Key: GROOVY-11194
> URL: https://issues.apache.org/jira/browse/GROOVY-11194
> Project: Groovy
> Issue Type: New Feature
> Components: command line processing, Compiler
>Affects Versions: 3.0.19, 5.0.0-alpha-2, 4.0.15
>Reporter: Benjamin Marwell
>Priority: Critical
>
> Hello groovy team,
> no version of the groovy distribution supports any of those features on the
> {{groovyc}} command line, which are available when invoking the groovy
> compiler via library means:
> * setDebug( boolean )
> * setVerbose( boolean )
> * setWarningLevel( int )
> * setTolerance( int )
> * invokeDynamic via optimizationOptions.put("indy", true);
> optimizationOptions.put("int", false);
> * parallel Parsing via optimizationOptions.put("parallelParse", true);
> This is important when gplus-maven-plugin shall run in fork mode. Draft PR:
> https://github.com/groovy/GMavenPlus/pull/283
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-9801) Stub generator omits default interface methods
[
https://issues.apache.org/jira/browse/GROOVY-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-9801.
--
Fix Version/s: 5.0.0-alpha-2
Resolution: Fixed
> Stub generator omits default interface methods
> --
>
> Key: GROOVY-9801
> URL: https://issues.apache.org/jira/browse/GROOVY-9801
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 3.0.6
>Reporter: Christopher Smith
>Assignee: Jochen Theodorou
>Priority: Major
> Fix For: 5.0.0-alpha-2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When presented with a Groovy interface that has a default method (shiny and
> new!) the stub generator omits the "default" part, leading to compilation
> failures in Java classes due to unimplemented abstract methods.
> {code:groovy}
> interface HasDefaultMethod {
> default void method() { }
> }
> {code}
> {code:java}
> import java.lang.*;
> import java.util.*;
> import java.io.*;
> import java.net.*;
> import groovy.lang.*;
> import groovy.util.*;
> @groovy.transform.Trait() public interface HasDefaultMethod
> {
> ;
> void method();
> }
> {code}
> (The stray semicolon is also odd but doesn't appear to be pathological.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-8859) traits allow access to private fields and static methods but not instance methods
[
https://issues.apache.org/jira/browse/GROOVY-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765031#comment-17765031
]
Jochen Theodorou commented on GROOVY-8859:
--
For me option 2 is good
> traits allow access to private fields and static methods but not instance
> methods
> -
>
> Key: GROOVY-8859
> URL: https://issues.apache.org/jira/browse/GROOVY-8859
> Project: Groovy
> Issue Type: Question
> Components: Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
> Labels: trait, traits
>
> It seems that private in a trait is akin to protected in a class. For
> example a class that implements a trait may access private fields (through
> namespace syntax) and properties and call private static methods. And it may
> use Type.super.method() to disambiguate methods if necessary. *Why, however,
> can a class that implements a trait not call private instance methods?* This
> is not really covered in the language specification.
> {code:groovy}
> trait T {
> private void privit() {
> println 'private'
> }
> public void publik() {
> println 'public'
> }
> }
> class C implements T {
> def m() {
> publik()
> privit()
> }
> }
> new C().m()
> {code}
> This fails with missing method. But if static modifier is added to privit,
> it succeeds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GROOVY-9801) Stub generator omits default interface methods
[
https://issues.apache.org/jira/browse/GROOVY-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou reassigned GROOVY-9801:
Assignee: Jochen Theodorou
> Stub generator omits default interface methods
> --
>
> Key: GROOVY-9801
> URL: https://issues.apache.org/jira/browse/GROOVY-9801
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 3.0.6
>Reporter: Christopher Smith
>Assignee: Jochen Theodorou
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When presented with a Groovy interface that has a default method (shiny and
> new!) the stub generator omits the "default" part, leading to compilation
> failures in Java classes due to unimplemented abstract methods.
> {code:groovy}
> interface HasDefaultMethod {
> default void method() { }
> }
> {code}
> {code:java}
> import java.lang.*;
> import java.util.*;
> import java.io.*;
> import java.net.*;
> import groovy.lang.*;
> import groovy.util.*;
> @groovy.transform.Trait() public interface HasDefaultMethod
> {
> ;
> void method();
> }
> {code}
> (The stray semicolon is also odd but doesn't appear to be pathological.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GROOVY-8299) Generate bytecode for interface with default, private and static methods
[ https://issues.apache.org/jira/browse/GROOVY-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou reassigned GROOVY-8299: Assignee: Jochen Theodorou > Generate bytecode for interface with default, private and static methods > > > Key: GROOVY-8299 > URL: https://issues.apache.org/jira/browse/GROOVY-8299 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Daniel Sun >Assignee: Jochen Theodorou >Priority: Major > Labels: default-methods > > Currently the interface with default methods is based on the traits, we > should provide real default methods introduced by Java8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-10258) NPE: Pinpoint Exact Location in Call Chain
[
https://issues.apache.org/jira/browse/GROOVY-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17758530#comment-17758530
]
Jochen Theodorou commented on GROOVY-10258:
---
>From my reading this is an internal solution where the JVM inspects bytecode
>to produce the message. And it looks like this cannot be influenced through
>Groovy. WE would have to spin our own solution and that would be expensive. If
>I am wrong anyone, please feel free to correct me on this. I too would like to
>have this, but currently it looks like having too much impact on performance.
> NPE: Pinpoint Exact Location in Call Chain
> --
>
> Key: GROOVY-10258
> URL: https://issues.apache.org/jira/browse/GROOVY-10258
> Project: Groovy
> Issue Type: Improvement
>Reporter: mgroovy
>Priority: Major
>
> Groovy should output the exact location where a NullPointerException occurred
> inside a call chain in the NPE message, if possible pretty printed.
> The JVM has been improved in this regard since OpenJDK 14:
> https://openjdk.java.net/jeps/358
> https://www.baeldung.com/java-14-nullpointerexception
> https://bugs.openjdk.java.net/browse/JDK-8233014
> The messages produced alas look pretty ugly for @CompileStatic Groovy (see
> below), due to its predominant use of properties instead of fields, and the
> original goal of JEP 358 to print the complete call chain (access path) seems
> to have been dropped, so it is not particularily helpful in some situations
> (see examples below).
> In Groovy 3.0.9 under OpenJDK 16:
> {code}
> @Newify(pattern=/[A-Z][A-Za-z0-9_]*/)
> //@CompileStatic
> class HelpfulNullPointerExceptionTest {
> static class X {
> X x; String s
> X(X x, String s = null) { this.x = x; this.s = s }
> @Override String toString() { "X($s,$x)" }
> }
> @Test
> void nullPointerInCallChain() {
> final x = X(X(X(X(null,"X-Men"
> println "x.x.x.x=$x.x.x.x"
> x.x.x = null
> /*
> * OpenJDK 16 (Eclipse jdk-16.0.2.7-hotspot) (Note:
> -XX:+ShowCodeDetailsInExceptionMessages is now always on by default)
> ** @CompileDynamic: java.lang.NullPointerException: Cannot get
> property 'x' on null object
> ** @CompileStatic: java.lang.NullPointerException: Cannot invoke
> "simple.groovy.HelpfulNullPointerExceptionTest$X.getX()" because the return
> value of "simple.groovy.HelpfulNullPointerExceptionTest$X.getX()" is null
> ** Would hope for something like (or its pretty-printed
> equivalent): java.lang.NullPointerException: Cannot get property 'x.x.x.x' on
> null object
> */
> println "x.x.x.x=$x.x.x.x"
> }
> @Canonical static class A { String a }
> @Canonical static class B { A a }
> @Canonical static class C { B b }
> @Canonical static class D { C c }
> @Test
> void nullPointerInCallChain2() {
> final x = D(C(B(A("aha!"
> println "x.c.b.a=$x.c.b.a"
> /*
> * OpenJDK 16 (Eclipse jdk-16.0.2.7-hotspot)
> ** @CompileDynamic: java.lang.NullPointerException: Cannot get
> property 'b' on null object
> ** @CompileStatic: java.lang.NullPointerException: Cannot invoke
> "simple.groovy.HelpfulNullPointerExceptionTest$C.getB()" because the return
> value of "simple.groovy.HelpfulNullPointerExceptionTest$D.getC()" is null
> ** Would hope for something like (or its pretty-printed
> equivalent): java.lang.NullPointerException: Cannot get property 'x.c.b.a' on
> null object
> */
> x.c = null
> println "x.c.b.a=$x.c.b.a"
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-4284) etablish a way to check for default meta class without creating it first
[ https://issues.apache.org/jira/browse/GROOVY-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-4284. -- Assignee: Jochen Theodorou Resolution: Fixed there is currently no use for that > etablish a way to check for default meta class without creating it first > > > Key: GROOVY-4284 > URL: https://issues.apache.org/jira/browse/GROOVY-4284 > Project: Groovy > Issue Type: Improvement > Components: groovy-runtime >Reporter: Jochen Theodorou >Assignee: Jochen Theodorou >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-10816) @NamedVariant does not work on methods on a trait or default methods on an interface
[
https://issues.apache.org/jira/browse/GROOVY-10816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-10816:
--
Labels: default-methods named-parameters (was: named-parameters)
> @NamedVariant does not work on methods on a trait or default methods on an
> interface
>
>
> Key: GROOVY-10816
> URL: https://issues.apache.org/jira/browse/GROOVY-10816
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.6
>Reporter: Robert Elliot
>Priority: Minor
> Labels: default-methods, named-parameters
>
> The following code fails to compile:
> {code:groovy}
> import groovy.transform.NamedVariant
> trait Foo {
> @NamedVariant
> def foo(String username = "sdf", String email = "ghj") {}
> }
> {code}
> with this error:
> {{Groovyc: Error during @NamedVariant processing. Class Foo$Trait$Helper
> already has a named-arg method of type
> [org.codehaus.groovy.ast.Parameter@15247533[name: namedArgs, type:
> java.util.Map, hasDefaultValue: false]]}}
> It works fine as a class.
> It fails as an interface with a default method.
> Perhaps this is intended, but if so I failed to find any documentation
> specifying that {{@NamedVariant}} only works with classes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-8299) Generate bytecode for interface with default, private and static methods
[ https://issues.apache.org/jira/browse/GROOVY-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou updated GROOVY-8299: - Labels: default-methods (was: ) > Generate bytecode for interface with default, private and static methods > > > Key: GROOVY-8299 > URL: https://issues.apache.org/jira/browse/GROOVY-8299 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Daniel Sun >Priority: Major > Labels: default-methods > > Currently the interface with default methods is based on the traits, we > should provide real default methods introduced by Java8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-3141) Ranges should be able to be used as Keys in Maps
[
https://issues.apache.org/jira/browse/GROOVY-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-3141.
--
Assignee: Jochen Theodorou
Resolution: Won't Fix
I think the use is too specific. If people still think this should be done I am
happy to reopen the issue
> Ranges should be able to be used as Keys in Maps
>
>
> Key: GROOVY-3141
> URL: https://issues.apache.org/jira/browse/GROOVY-3141
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Reporter: Matthew Corby-Eaglen
>Assignee: Jochen Theodorou
>Priority: Minor
>
> Consider this:
> {code}
> def rangeMap = [(0..10) : "hello", (11..15) : "goodbye"]
> assertTrue(rangeMap.get(12) == "goodbye")
> {code}
> Currently you get null from the map, because 12 does not match the range as a
> key to the map.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-3032) GroovyScriptEngine needs SecurityPermissions
[ https://issues.apache.org/jira/browse/GROOVY-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-3032. -- Assignee: Jochen Theodorou Resolution: Won't Fix I am actually sorry to close this. But I think it makes no sense to implement this no that SecurityManager is phased out and no replacement is known. > GroovyScriptEngine needs SecurityPermissions > > > Key: GROOVY-3032 > URL: https://issues.apache.org/jira/browse/GROOVY-3032 > Project: Groovy > Issue Type: Improvement > Components: GroovyScriptEngine >Affects Versions: 1.5.6 > Environment: Any >Reporter: Matthew Corby-Eaglen >Assignee: Jochen Theodorou >Priority: Minor > Attachments: groovysecurity.diff > > > The GroovyScriptEngine requires some means of preventing certain objects from > running certain scripts. This would be useful for multi-user environments who > can log in and execute scripts via the shell. > An external wrapper would not work well because the GSE resolves scripts at > run time, and the URL of the scripts cannot be exposed before hand. > I suppose a change at the Script object level might be more appropriate, but > this would be effective. > Patch included. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-2734) Expose a method which allows the programmer to know that a script is out of date
[ https://issues.apache.org/jira/browse/GROOVY-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-2734. -- Assignee: Jochen Theodorou Resolution: Incomplete > Expose a method which allows the programmer to know that a script is out of > date > > > Key: GROOVY-2734 > URL: https://issues.apache.org/jira/browse/GROOVY-2734 > Project: Groovy > Issue Type: Improvement > Components: GroovyScriptEngine >Affects Versions: 1.5.4 >Reporter: Cédric Champeau >Assignee: Jochen Theodorou >Priority: Major > Attachments: gse-isoutofdate.patch > > > Following this thread : > http://www.nabble.com/GroovyScriptEngine-improvement---to16586229.html > Attached is a patch which exposes a new method, isCacheEntryOutOfDate(String > scriptName), which allows the developper to know whether a script will be > reloaded or not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-8536) StaticTypeCheckingSupport.ExtensionMethodCache is private
[ https://issues.apache.org/jira/browse/GROOVY-8536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-8536. -- Assignee: Jochen Theodorou Resolution: Fixed > StaticTypeCheckingSupport.ExtensionMethodCache is private > - > > Key: GROOVY-8536 > URL: https://issues.apache.org/jira/browse/GROOVY-8536 > Project: Groovy > Issue Type: Bug >Reporter: Jochen Theodorou >Assignee: Jochen Theodorou >Priority: Major > Labels: easyfix > > StaticTypeCheckingSupport exposes the protected constant > EXTENSION_METHOD_CACHE, but the type is ExtensionMethodCache, which is an > inner static and private class. For this constant to be useable it should not > be private and the cache class needs to be exposed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11161) Support extension methods inside the same compilation unit
[
https://issues.apache.org/jira/browse/GROOVY-11161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757646#comment-17757646
]
Jochen Theodorou commented on GROOVY-11161:
---
I changed to static compilation because non-static Groovy does not care about
extension methods until runtime. As for static compilation... there are
actually type checking extensions. That could be used if the list of methods is
known.
The other way would be of course that kind of annotation and then the type
checker (or a type checking extension) would have to search for these nodes and
use them... ah I think it is not fully the same if I think of overloads. there
might be already a fitting method, just an extension method would be maybe more
fitting. then methodMissing would not be done in the TypeCheckingExtension.
That means this would have to go even deeper. ..
As funny as it sounds it would probably the most easy to first compile without
static compilation and then again with, while using the precompiled extension
methods.
So far I found nothing of this very attractive.
> Support extension methods inside the same compilation unit
> --
>
> Key: GROOVY-11161
> URL: https://issues.apache.org/jira/browse/GROOVY-11161
> Project: Groovy
> Issue Type: Wish
> Components: Static compilation, Static Type Checker
>Affects Versions: 4.0.14
>Reporter: Christopher Smith
>Priority: Major
>
> Currently, the Groovy compiler supports extension methods only if they are
> previously compiled and provided to the current compilation run on the
> classpath. I have several projects where using extension methods to make
> project-specific micro-DSLs would substantially improve
> readability/maintainability, but because the extension methods need to refer
> to business objects, I would have to slice up the project into a pile of
> micro-projects.
> It would be very useful to be able to have a "bootstrap" mechanism to declare
> extension methods within the same project they're applied to, in the same way
> that annotations can be declared inside the same project. Either having an
> annotation {{@ProvidesExtensionMethods}} or providing a {{META-INF}} file
> (maybe being able to employ the usual mechanism for "forward extension
> declarations"?) would accomplish what I think I'm looking for.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11161) Support extension methods inside the same compilation unit
[
https://issues.apache.org/jira/browse/GROOVY-11161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-11161:
--
Component/s: Static compilation
Static Type Checker
(was: Compiler)
> Support extension methods inside the same compilation unit
> --
>
> Key: GROOVY-11161
> URL: https://issues.apache.org/jira/browse/GROOVY-11161
> Project: Groovy
> Issue Type: Wish
> Components: Static compilation, Static Type Checker
>Affects Versions: 4.0.14
>Reporter: Christopher Smith
>Priority: Major
>
> Currently, the Groovy compiler supports extension methods only if they are
> previously compiled and provided to the current compilation run on the
> classpath. I have several projects where using extension methods to make
> project-specific micro-DSLs would substantially improve
> readability/maintainability, but because the extension methods need to refer
> to business objects, I would have to slice up the project into a pile of
> micro-projects.
> It would be very useful to be able to have a "bootstrap" mechanism to declare
> extension methods within the same project they're applied to, in the same way
> that annotations can be declared inside the same project. Either having an
> annotation {{@ProvidesExtensionMethods}} or providing a {{META-INF}} file
> (maybe being able to employ the usual mechanism for "forward extension
> declarations"?) would accomplish what I think I'm looking for.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-7408) Reflection failed when the system time is before the last modified time of the groovy script
[ https://issues.apache.org/jira/browse/GROOVY-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-7408. -- Assignee: Jochen Theodorou Resolution: Incomplete I am closing this for now as incomplete. Anybody please feel to reopen this if needed. To really solve the issue I would require a minimal working example though > Reflection failed when the system time is before the last modified time of > the groovy script > > > Key: GROOVY-7408 > URL: https://issues.apache.org/jira/browse/GROOVY-7408 > Project: Groovy > Issue Type: Bug > Components: GroovyScriptEngine >Affects Versions: 1.8.3, 2.4.1 > Environment: redhat 6.0 >Reporter: Ethan Zhang >Assignee: Jochen Theodorou >Priority: Major > > Hi, > I use GroovyScriptEngine to run a groovy script from java program. Inside the > groovy script, I use Class.forName to load another groovy class. However, if > the operating system time is behind the groovy file last modified time, > following exception will be thrown: > java.lang.NoSuchMethodException: scripts.A.(scripts.A, > java.lang.String, java.lang.String, java.lang.String) > at java.lang.Class.getConstructor0(Unknown Source) > at java.lang.Class.getConstructor(Unknown Source) > at java_lang_Class$getConstructor$1.call(Unknown Source) > at > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:110) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:122) > at scripts.B.create(B.groovy:41) > at scripts.B$create.call(Unknown Source) > at > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:110) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:114) > at scripts.enrich.run(enrich.groovy:38) > at groovy.util.GroovyScriptEngine.run(GroovyScriptEngine.java:589) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-8660) Unexpected MethodSelectionException with implicit null argument
[
https://issues.apache.org/jira/browse/GROOVY-8660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-8660:
-
Affects Version/s: 4.0.13
> Unexpected MethodSelectionException with implicit null argument
> ---
>
> Key: GROOVY-8660
> URL: https://issues.apache.org/jira/browse/GROOVY-8660
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-2, 2.4.15, 2.5.0, 4.0.13
>Reporter: Daniil Ovchinnikov
>Priority: Major
> Labels: varargs
>
> {code:groovy}
> class OnlySingle {
> def foo(a) { "single param: $a" }
> }
> println new OnlySingle().foo()
> // as expected: 'single param: null'
> class OnlyVararg {
> def foo(a, ... b) { "vararg param: $a, $b" }
> }
> println new OnlyVararg().foo()
> // as expected: 'MME: No signature of method: OnlyVararg.foo() is applicable
> for argument types: () values: []'
> class Both {
> def foo(a) { "single param: $a" }
> def foo(a, ... b) { "vararg param: $a, $b" }
> }
> println new Both().foo()
> // unexpected:
> // MethodSelectionException: Could not find which method foo() to invoke from
> this list:
> // public java.lang.Object Both#foo(java.lang.Object)
> // public transient java.lang.Object Both#foo(java.lang.Object,
> [Ljava.lang.Object;)
> {code}
> If the exception is expected then {{OnlyVararg}} case should work too.
> If the exception is unexpected then {{Both#foo(Object)}} should be selected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-5116) Groovy enforces the use of the the dangerous permission java.util.PropertyPermission "*" "read,write" when using a SecurityManager
[
https://issues.apache.org/jira/browse/GROOVY-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-5116.
--
Assignee: Jochen Theodorou
Resolution: Won't Fix
I think it is fair to close this issue. GroovyMain is not a suitable entry
point for anything but the commandline groovy scripts.
> Groovy enforces the use of the the dangerous permission
> java.util.PropertyPermission "*" "read,write" when using a SecurityManager
> --
>
> Key: GROOVY-5116
> URL: https://issues.apache.org/jira/browse/GROOVY-5116
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 1.8.3
>Reporter: Benjamin Wolff
>Assignee: Jochen Theodorou
>Priority: Major
> Labels: contrib
>
> In several occurrences in the code, the system properties are accessed in
> this manner:
> groovy.grape.Grape.java
> {code}
> private static boolean enableGrapes =
> Boolean.valueOf(System.getProperties().getProperty("groovy.grape.enable",
> "true"));
> {code}
> The use of System.getProperties() forces the use of this permission in the
> SecurityManager: {noformat} java.util.PropertyPermission "*"
> "read,write"{noformat}
> This is not really desired in security sensitive environments. It is not
> possible to use more fine-grained permission declaration like e.g.:
> {noformat} java.util.PropertyPermission "groovy.*" "read,write"{noformat}
> This problem could be easily avoided by accessing the properties in this
> manner:
> {code}
> private static boolean enableGrapes =
> Boolean.valueOf(System.getProperty("groovy.grape.enable", "true"));
> {code}
> Without the use of System.getProperties() it is not mandatory to set the
> dangerous write permission on all system properties and more fine-grained
> security permissions like in the example could be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-9113) Unreachable code was not flagged by groovy compiler
[
https://issues.apache.org/jira/browse/GROOVY-9113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-9113:
-
Component/s: Compiler
Static compilation
Static Type Checker
(was: groovy-jdk)
> Unreachable code was not flagged by groovy compiler
> ---
>
> Key: GROOVY-9113
> URL: https://issues.apache.org/jira/browse/GROOVY-9113
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler, Static compilation, Static Type Checker
>Affects Versions: 2.4.6
> Environment: Groovy Version: 2.4.6 JVM: 1.8.0_91 Vendor: Oracle
> Corporation OS: Windows 10
>Reporter: Ashish
>Priority: Major
>
> The {{break}} statement after {{return'1'}} was not flagged as unreachable by
> groovy
> {code:java}
> switch(x) {
> case ['Front', 'Steer']:
> return '1'
> break
> case 'Drive':
> return '2'
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-9113) Unreachable code was not flagged by groovy compiler
[
https://issues.apache.org/jira/browse/GROOVY-9113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-9113:
-
Component/s: (was: Static compilation)
(was: Static Type Checker)
> Unreachable code was not flagged by groovy compiler
> ---
>
> Key: GROOVY-9113
> URL: https://issues.apache.org/jira/browse/GROOVY-9113
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 2.4.6
> Environment: Groovy Version: 2.4.6 JVM: 1.8.0_91 Vendor: Oracle
> Corporation OS: Windows 10
>Reporter: Ashish
>Priority: Major
>
> The {{break}} statement after {{return'1'}} was not flagged as unreachable by
> groovy
> {code:java}
> switch(x) {
> case ['Front', 'Steer']:
> return '1'
> break
> case 'Drive':
> return '2'
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-9113) Unreachable code was not flagged by groovy compiler
[
https://issues.apache.org/jira/browse/GROOVY-9113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-9113:
-
Issue Type: Improvement (was: Bug)
> Unreachable code was not flagged by groovy compiler
> ---
>
> Key: GROOVY-9113
> URL: https://issues.apache.org/jira/browse/GROOVY-9113
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-jdk
>Affects Versions: 2.4.6
> Environment: Groovy Version: 2.4.6 JVM: 1.8.0_91 Vendor: Oracle
> Corporation OS: Windows 10
>Reporter: Ashish
>Priority: Major
>
> The {{break}} statement after {{return'1'}} was not flagged as unreachable by
> groovy
> {code:java}
> switch(x) {
> case ['Front', 'Steer']:
> return '1'
> break
> case 'Drive':
> return '2'
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-6324) Cannot call closure like a method in type checked mode
[
https://issues.apache.org/jira/browse/GROOVY-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757489#comment-17757489
]
Jochen Theodorou commented on GROOVY-6324:
--
[~emilles] For a local variable we add information if we assign a closure to
it. Then we can use that information to determine if the call using that
variable is valid or not. But here it is a field, maybe even a precompiled
class in Java. There is no assignment we can trace. Where to get the meta
information we require? I think for this to compile a annotation like we use it
for DGM would be required. Not sure if the same annotation could be used or
should be used.
> Cannot call closure like a method in type checked mode
> --
>
> Key: GROOVY-6324
> URL: https://issues.apache.org/jira/browse/GROOVY-6324
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.2.0-beta-1, 2.3.0, 2.4.0-rc-1
>Reporter: Peter Niederwieser
>Priority: Major
>
> {{Closure closure = ...; closure()}} doesn't work in type-checked mode.
> Instead, one has to use {{closure.call()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-6519) removing direct usage of Binding from script
[ https://issues.apache.org/jira/browse/GROOVY-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757459#comment-17757459 ] Jochen Theodorou commented on GROOVY-6519: -- Actually this depends a bit on if we want to allow a script base class with different constructors than Script uses or not. If we do, then I am against this. If we don't then maybe > removing direct usage of Binding from script > > > Key: GROOVY-6519 > URL: https://issues.apache.org/jira/browse/GROOVY-6519 > Project: Groovy > Issue Type: Sub-task >Reporter: Jochen Theodorou >Priority: Major > > Instead of forcing Script to use Binding as a wrapper always, we can > introduce a loose connection by dynamic invocation then. This way it is > possible to use any object for the binding and it becomes more like a > delegate in Closure. The delegate has of course influence on the semantics > here. If a map is used, there won't be an exception in case an unused > variable is read in the script for example. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-6228) Add asConcurrent(List/Map) method to Collections
[ https://issues.apache.org/jira/browse/GROOVY-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757449#comment-17757449 ] Jochen Theodorou commented on GROOVY-6228: -- [~paulk] DGM is more your area, what should we do here? > Add asConcurrent(List/Map) method to Collections > > > Key: GROOVY-6228 > URL: https://issues.apache.org/jira/browse/GROOVY-6228 > Project: Groovy > Issue Type: Improvement > Components: groovy-jdk >Reporter: Thierry De Leeuw >Priority: Minor > > Wouldn't it be better to replace/provide a new methods to get a > ConcurrentHashMap, instead of a collections.SynchronizedMap as it is a lot > more efficient? > If the "original" map is a TreeMap, of course, there is no equivalent in > Concurrent, so fallback to Synchronized seems a good compromise. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-6209) Weird error message with lower case class names
[
https://issues.apache.org/jira/browse/GROOVY-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-6209.
--
Assignee: Jochen Theodorou
Resolution: Won't Fix
The result of these discussions over the years turned into Groovy not trying to
resolve such cases at all. And since a workaround exists I close the issue
> Weird error message with lower case class names
> ---
>
> Key: GROOVY-6209
> URL: https://issues.apache.org/jira/browse/GROOVY-6209
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.1.5, 2.2.0-beta-1
>Reporter: Dr. Russel Winder
>Assignee: Jochen Theodorou
>Priority: Major
>
> The code:
> {code}
> class test {
> static void main(args) {
> test t = new test()
> }
> }
> {code}
> results in the error message:
> {noformat}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> /home/users/russel/tmp/BSkyB_2013-06-18/test.groovy: 3: Apparent variable 't'
> was found in a static scope but doesn't refer to a local variable, static
> field or class. Possible causes:
> You attempted to reference a variable in the binding or an instance variable
> from a static context.
> You misspelled a classname or statically imported field. Please check the
> spelling.
> You attempted to use a method 't' but left out brackets in a place not
> allowed by the grammar.
> @ line 3, column 10.
>test t = new test()
> ^
> 1 error
> {noformat}
> Editing the code g/test/s//Test/g means the code compiles and executes fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-5881) Type inference breaks in longer transitive generic structures
[
https://issues.apache.org/jira/browse/GROOVY-5881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-5881:
-
Affects Version/s: 4.0.13
> Type inference breaks in longer transitive generic structures
> -
>
> Key: GROOVY-5881
> URL: https://issues.apache.org/jira/browse/GROOVY-5881
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.0.6, 2.3.0, 2.4.0-beta-3, 4.0.13
>Reporter: Dimitar Dimitrov
>Priority: Major
>
> {code}
> class Test {
> @CompileStatic
> void printProgress(Map> markers, int i) {
> for (e in markers.entrySet()) {
> if (i%e.key==0) { print e.value(i) ; break }
> }
> }
> }
> {code}
> Fails to compile with: {{Groovyc: [Static type checking] - Cannot find
> matching method java.util.Map$Entry#value(int). Please check if the declared
> type is right and if the method exists.}}
> The following fixes the problem, though it should not be necesarry to do
> explicit 'call'.
> {code}
> class Test {
> @CompileStatic
> void printProgress(Map> markers, int i) {
> for (e in markers.entrySet()) {
> print e.value.call(i)
> }
> }
> }
> {code}
> For comparison, the following passes:
> {code}
> class Test {
> @CompileStatic
> void printProgress(Set> markers, int i) {
> for (e in markers) {
> print e(i)
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-5727) Ovverriding 3rd Party libraries shipped
[ https://issues.apache.org/jira/browse/GROOVY-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-5727. -- Fix Version/s: 2.5.0 Assignee: Jochen Theodorou Resolution: Fixed This seems to be fixed since at least 2.5.0, probably earlier > Ovverriding 3rd Party libraries shipped > --- > > Key: GROOVY-5727 > URL: https://issues.apache.org/jira/browse/GROOVY-5727 > Project: Groovy > Issue Type: Improvement > Components: Groovysh >Affects Versions: 2.0.4 >Reporter: deas >Assignee: Jochen Theodorou >Priority: Major > Labels: contrib > Fix For: 2.5.0 > > > Groovy 2.0.4 ships various 3rd party libraries, e.g. servlet-api-2.4.jar and > jsp-api-2.0.jar. These can get in the way and I see no reasonable way to use > user defined versions in groovysh. Of course you can introduce a custom > classloader searching locally before delegating to the parent or just remove > the library shipped to get it out of the way, but I feel there should be a > groovier way. Maybe you should just omit shipping these libraries. > A concrete situation where I encountered this problem was when I wanted a > groovy script to launch jetty with servlet 3.0 support, pulling in various > dependencies with Grape. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-5502) If/else branch does not always infer the variable type
[
https://issues.apache.org/jira/browse/GROOVY-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-5502:
-
Affects Version/s: 3.0.19
4.0.14
2.5.23
2.0.0
> If/else branch does not always infer the variable type
> --
>
> Key: GROOVY-5502
> URL: https://issues.apache.org/jira/browse/GROOVY-5502
> Project: Groovy
> Issue Type: Improvement
> Components: Static Type Checker
>Affects Versions: 2.0.0, 2.5.23, 4.0.14, 3.0.19
>Reporter: Ariel Morelli Andres
>Priority: Minor
>
> Suppose we have the following code:
> {code}
> class A {
> void m() {
> }
> }
> class B extends A {
> }
> class C extends A {
> }
> @groovy.transform.TypeChecked
> class Test {
>void m() {
> def var = new Object() //If instead I put just "def var" it works as
> spected
> if (true) {
> var = new B()
> }
> else {
> var = new C()
> }
> var.m() //fails here
>}
> }
> {code}
> In this case, after the if/else structure we can infer that var is instanceOf
> A.
> But, the initialization seems to confuse the type inference.
> [Static type checking] - Cannot find matching method java.lang.Object#mA()
> at line: 23, column: 7
> If instead of {code}def var = new Object(){code} we put just {code}def
> var{code}, then the inference works fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-5404) Compiler exception for invalid operator
[
https://issues.apache.org/jira/browse/GROOVY-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-5404.
--
Fix Version/s: 1.8.8
(was: 4.x)
Assignee: Jochen Theodorou
Resolution: Fixed
I am closing the issue because the bug behind got fixed and the message is now
different as well
> Compiler exception for invalid operator
> ---
>
> Key: GROOVY-5404
> URL: https://issues.apache.org/jira/browse/GROOVY-5404
> Project: Groovy
> Issue Type: Improvement
> Components: class generator
>Affects Versions: 1.8.6
>Reporter: Jan Stette
>Assignee: Jochen Theodorou
>Priority: Minor
> Fix For: 1.8.8
>
>
> A script containing this:
> print "Foo" ===~ ".*"
> ...causes the stack trace below from the compiler. It's not valid code of
> course, but the compiler should give a normal error message to the user.
> Stack trace:
> >>> a serious error occurred: BUG! exception in phase 'class generation' in
> >>> source unit '<...>Foo.groovy' Operation: ("===" at 2:13: "===" ) not
> >>> supported
> >>> stacktrace:
> BUG! exception in phase 'class generation' in source unit
> '/Users/jans/src/courses/nlp-class/week4/pa4-ner/java/GroovyTest.groovy'
> Operation: ("===" at 2:13: "===" ) not supported
> at
> org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.eval(BinaryExpressionHelper.java:246)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitBinaryExpression(AsmClassGenerator.java:521)
> at
> org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:49)
> at
> org.codehaus.groovy.classgen.asm.CallSiteWriter.makeCallSite(CallSiteWriter.java:301)
> at
> org.codehaus.groovy.classgen.asm.InvocationWriter.makeCall(InvocationWriter.java:187)
> at
> org.codehaus.groovy.classgen.asm.InvocationWriter.makeCall(InvocationWriter.java:89)
> at
> org.codehaus.groovy.classgen.asm.InvocationWriter.makeInvokeMethodCall(InvocationWriter.java:73)
> at
> org.codehaus.groovy.classgen.asm.InvocationWriter.writeInvokeMethod(InvocationWriter.java:292)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitMethodCallExpression(AsmClassGenerator.java:657)
> at
> org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:75)
> at
> org.codehaus.groovy.classgen.asm.StatementWriter.writeReturn(StatementWriter.java:577)
> at
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeReturn(OptimizingStatementWriter.java:316)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitReturnStatement(AsmClassGenerator.java:499)
> at
> org.codehaus.groovy.ast.stmt.ReturnStatement.visit(ReturnStatement.java:47)
> at
> org.codehaus.groovy.classgen.asm.StatementWriter.writeBlockStatement(StatementWriter.java:80)
> at
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeBlockStatement(OptimizingStatementWriter.java:155)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:449)
> at
> org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:101)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:112)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:313)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:270)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:123)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:390)
> at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1056)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:50)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:174)
> at
> org.codehaus.groovy.control.CompilationUnit$14.call(CompilationUnit.java:767)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:967)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:546)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:524)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:501)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:480)
> at
> org.codehaus.groovy.tools.FileSystemCompiler.co
[jira] [Resolved] (GROOVY-5117) remove all references to java.util.logging from within groovy
[ https://issues.apache.org/jira/browse/GROOVY-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-5117. -- Assignee: Jochen Theodorou Resolution: Won't Fix I am closing this issue for now, since JUL bridges exist. If [~rzorzorzo] sees things different I invite him to reopen the discussion here. > remove all references to java.util.logging from within groovy > - > > Key: GROOVY-5117 > URL: https://issues.apache.org/jira/browse/GROOVY-5117 > Project: Groovy > Issue Type: Improvement > Environment: using groovy as script engine embedded within another > application/framework >Reporter: ron >Assignee: Jochen Theodorou >Priority: Major > > java does not allow multiple configurations of logging. > java logging is initialized on class load. > some applications (for example jboss 7) assume that they are the only ones to > initialize the logging and will crash if java logging has already been > initialized. > solution: add and use groovy logging class, which, depending on system > property configuration, may or may not use java.util.logging. > remove all references to java.util.logging from all groovy classes (for > example, org.codehaus.groovy.runtime.*) > -- Ron > http://sourceforge.net/projects/yajsw/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-5357) The accessor pair can't be provided from different sources
[
https://issues.apache.org/jira/browse/GROOVY-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-5357.
--
Fix Version/s: 4.0.0
3.0.3
Assignee: Jochen Theodorou
Resolution: Fixed
Closed as fixed per user comment
> The accessor pair can't be provided from different sources
> --
>
> Key: GROOVY-5357
> URL: https://issues.apache.org/jira/browse/GROOVY-5357
> Project: Groovy
> Issue Type: Sub-task
> Components: groovy-runtime
>Reporter: OC
>Assignee: Jochen Theodorou
>Priority: Major
> Fix For: 4.0.0, 3.0.3
>
>
> When one of the accessor pair is added through a mixin or metaclass, Groovy
> behaves as if the other one did not exist.
> Explanation kindly provided by Paul: "MetaClassImpl finds a MetaBeanProperty
> containing just the getter. When only a getter is found there is an incorrect
> assumption that a setter doesn't exist in the underlying class."
> {code}
> class Foo {
> void setVal(v) { println "setVal: $v" }
> }
> @Category(Foo) class Getter {
> def getVal() { println "getVal" }
> }
> class Test {
> static def main(av) {
> Foo.mixin Getter
> def f = new Foo()
> f.setVal('foo')
> f.val = null // => groovy.lang.ReadOnlyPropertyException: Cannot set
> readonly property: val for class: Foo
> }
> }
> {code}
> or
> {code}
> class Foo {
> void setVal(v) { println "setVal: $v" }
> }
> class Test {
> static def main(av) {
> Foo.metaClass.getVal={-> println "getval" }
> def f = new Foo()
> f.setVal('foo')
> f.val = null // => groovy.lang.ReadOnlyPropertyException: Cannot set
> readonly property: val for class: Foo
> }
> }
> {code}
> or
> {code}
> class Foo {
> def getVal() { println "getVal" }
> }
> class Test {
> static def main(av) {
> Foo.metaClass.setVal={v-> }
> def f = new Foo()
> f.getVal()
> f.val
> }
> }
> {code}
> etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-5399) Automatically provide instance methods on objects when another class has a static method with the object as first argument
[
https://issues.apache.org/jira/browse/GROOVY-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-5399.
--
Assignee: Jochen Theodorou
Resolution: Won't Fix
With default methods on interfaces Java more and more adds methods to
interfaces, that formerly would have gone in helper classes like Arrays and
Collections. I still think adding these kind of methods to DGM on demand is
better, but the need will probably also arise less. Thus it should be save to
close this feature request
> Automatically provide instance methods on objects when another class has a
> static method with the object as first argument
> --
>
> Key: GROOVY-5399
> URL: https://issues.apache.org/jira/browse/GROOVY-5399
> Project: Groovy
> Issue Type: New Feature
> Components: Compiler
>Reporter: Dr. Russel Winder
>Assignee: Jochen Theodorou
>Priority: Major
>
> The script:
> {code}
> number = 27
> println number.toHexString ( )
> {code}
> results in the message:
> {quote}
> Caught: groovy.lang.MissingMethodException: No signature of method:
> java.lang.Integer.toHexString() is applicable for argument types: () values:
> []
> Possible solutions: toHexString(int), toString(), toString(), toString(),
> toString(int), toString(int, int)
> groovy.lang.MissingMethodException: No signature of method:
> java.lang.Integer.toHexString() is applicable for argument types: () values:
> []
> Possible solutions: toHexString(int), toString(), toString(), toString(),
> toString(int), toString(int, int)
> at toHexString_Problem.run(toHexString_Problem.groovy:5)
> {quote}
> The reason is that _toHexString_ is defined as a static method on the types
> and not within the GroovyJDK. I believe that it is more usable for
> prograqmmers, more appropriate to a dynamic language, and generally more
> Groovy to allow the method to operate on a reference to an object and only
> raise an exception if the object is not of an appropriate type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-4985) null and .with{}
[
https://issues.apache.org/jira/browse/GROOVY-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-4985.
--
Assignee: Jochen Theodorou
Resolution: Duplicate
duplicate of GROOVY-4526
> null and .with{}
>
>
> Key: GROOVY-4985
> URL: https://issues.apache.org/jira/browse/GROOVY-4985
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.8.0
>Reporter: Nikita Y Volkov
>Assignee: Jochen Theodorou
>Priority: Major
> Attachments: 4985.patch
>
>
> Currently this fails:{code}
> null.with { assert it == null }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-4526) NullObject paradoxes
[
https://issues.apache.org/jira/browse/GROOVY-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-4526.
--
Fix Version/s: 1.8.0
Assignee: Jochen Theodorou
Resolution: Fixed
the issue got forgotten. The associated PR has been merged 10 years ago already
> NullObject paradoxes
>
>
> Key: GROOVY-4526
> URL: https://issues.apache.org/jira/browse/GROOVY-4526
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.7.5, 1.8-beta-2
>Reporter: Nikita Y Volkov
>Assignee: Jochen Theodorou
>Priority: Major
> Fix For: 1.8.0
>
>
> {code}
> def theNull = NullObject.getNullObject()
> assert theNull// first paradox
> assert theNull instanceof NullObject
> assert theNull.equals(null)
> assert theNull != null// second paradox
> assert null.getClass() == NullObject
> assert !(null instanceof NullObject) // third paradox
> {code}
> I have bumped into this paradox after debugging the following script:
> {code}
> new File('inexestent-folder/').listFiles().with { files ->
> assert files
> assert files in NullObject
> println "This shouldn't happen"
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-3825) Byte code generator (used by GroovyScriptEngine, GroovyShell & GroovyClassLoader) flag invalid methods
[ https://issues.apache.org/jira/browse/GROOVY-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-3825. -- Assignee: Jochen Theodorou Resolution: Fixed This has been fixed a long time ago. Should there still be cases for this we have to look at them specifically and in a new issue > Byte code generator (used by GroovyScriptEngine, GroovyShell & > GroovyClassLoader) flag invalid methods > -- > > Key: GROOVY-3825 > URL: https://issues.apache.org/jira/browse/GROOVY-3825 > Project: Groovy > Issue Type: Improvement > Components: class generator >Affects Versions: 1.6.5, 1.7-beta-2 >Reporter: jwb >Assignee: Jochen Theodorou >Priority: Minor > Labels: ClassFormatError > > When generating code for the Groovy compiler, one frequently exceeds the > Class file format limit on method size. The resulting ClassFormatError from > the ClassLoader doesn't effectively point at the problem. In addition, the > Error is not a type of Exception and so is not picked up by conventional > logging. > Ideally, the methods that generate class files would abort code-generation > and throw a type of Exception when the generated method exceeds the limit > imposed by the class file format. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-9718) Illegal reflective access operation to constructor sun.security.pkcs11.wrapper.CK_C_INITIALIZE_ARGS
[
https://issues.apache.org/jira/browse/GROOVY-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou resolved GROOVY-9718.
--
Assignee: Jochen Theodorou
Resolution: Won't Fix
This is a problem in with OpenWebstart and the module system, not Groovy as such
> Illegal reflective access operation to constructor
> sun.security.pkcs11.wrapper.CK_C_INITIALIZE_ARGS
> ---
>
> Key: GROOVY-9718
> URL: https://issues.apache.org/jira/browse/GROOVY-9718
> Project: Groovy
> Issue Type: Bug
> Components: jdk conflict
>Affects Versions: 3.0.5
> Environment: OS: Linux Ubuntu 20.04.1 (Xubuntu flavor)
> JRE version: OpenJDK Runtime Environment 11.0.8 64-Bit
> Groovy Version: 3.0.5
>Reporter: Rolando Chaparro Fox
>Assignee: Jochen Theodorou
>Priority: Major
>
> Hello,
> The following piece of code triggers a Warning in Java 11:
> {code:java}
> import sun.security.pkcs11.wrapper.CK_C_INITIALIZE_ARGS as ModuleInitArgs
> // This CK_C_INITIALIZE_ARGS constructor call triggers the warning
> ModuleInitArgs initArgs = new ModuleInitArgs()
> {code}
> This is the Warning:
> {noformat}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.ReflectionUtils
> (file:/home/rchfox/somewhere/groovy-3.0.5.jar) to
> constructor sun.security.pkcs11.wrapper.CK_C_INITIALIZE_ARGS()
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.reflection.ReflectionUtils
> 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{noformat}
> The above constructor call works fine, nonetheless .
> Not quite sure, but apparently CK_C_INITIALIZE_ARGS has no explicit
> constructor. Here the source code at openjdk.java.net:
> [CK_C_INITIALIZE_ARGS.java|http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_C_INITIALIZE_ARGS.java]
> What I know is that this "constructor" call did not trigger any warning in
> Java <= 1.8.
> *Side note #1*: I kind of understand the Java designers' mindset. I guess
> that the idea behind this is not exposing implemented functionality required
> by callers of a function/method/constructor, so that the calling code
> awkwardly re-implements the same functionality in terms of those calls.
> Probably the OpenJDK crypto team guys expect nobody should ever need to
> invoke the CK_C_INITIALIZE_ARGS constructor. However, in my case in
> particular, I haven't found yet any sound programmatic alternative to
> implement the functionality I need.
> *Side note #2*: I managed to bypass this issue using the new {{--add-opens}}
> JVM argument (available since Java 9), as suggested in Oracle's [Migration
> Guide|https://docs.oracle.com/en/java/javase/11/migrate].
> However, I still need to solve this issue by other means because my app (a
> JavaFX/GroovyFX Application) is launched through JWS/JNLP, using the
> OpenWebStart implementation, which in turns has a bug right now that prevents
> me using the new {{--add-opens}} JVM argument, as I've just reported
> [here|https://github.com/karakun/OpenWebStart/issues/322].
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-1367) allow cloning of the AST
[ https://issues.apache.org/jira/browse/GROOVY-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-1367. -- Resolution: Won't Fix The real need for this did never arise, so closing this > allow cloning of the AST > > > Key: GROOVY-1367 > URL: https://issues.apache.org/jira/browse/GROOVY-1367 > Project: Groovy > Issue Type: Sub-task > Components: Compiler >Reporter: Jochen Theodorou >Assignee: Jochen Theodorou >Priority: Major > > to allow cloning of the AST we need a cloning method that makes a deep copy. > Expressions have the transform method, but that may not return a new > instance. But for reusing AST parts in another AST we have to make a deep > copy. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GROOVY-1367) allow cloning of the AST
[ https://issues.apache.org/jira/browse/GROOVY-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou reassigned GROOVY-1367: Assignee: Jochen Theodorou > allow cloning of the AST > > > Key: GROOVY-1367 > URL: https://issues.apache.org/jira/browse/GROOVY-1367 > Project: Groovy > Issue Type: Sub-task > Components: Compiler >Reporter: Jochen Theodorou >Assignee: Jochen Theodorou >Priority: Major > > to allow cloning of the AST we need a cloning method that makes a deep copy. > Expressions have the transform method, but that may not return a new > instance. But for reusing AST parts in another AST we have to make a deep > copy. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-9493) JSR 223 regression: not working under OpenJ9 since version 3.0.0
[ https://issues.apache.org/jira/browse/GROOVY-9493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou resolved GROOVY-9493. -- Resolution: Not A Bug It seems the issue is no longer one as it seems a new release of J9 fixed the issue > JSR 223 regression: not working under OpenJ9 since version 3.0.0 > > > Key: GROOVY-9493 > URL: https://issues.apache.org/jira/browse/GROOVY-9493 > Project: Groovy > Issue Type: Bug > Components: groovy-jsr223 >Affects Versions: 3.0.0, 3.0.1, 3.0.2 >Reporter: Danilo Pianini >Assignee: Jochen Theodorou >Priority: Major > > Since version 3.0.0, Groovy fails at running JSR 223 scripts under OpenJ9. > The issue does not appear under OpenJDK. > > The following is the result of the attempted evaluation of the script `1` > under OpenJ9 12. The failure is reproducible with OpenJ9 11 and OpenJ9 14. > Inside `GroovyScriptEngineImpl`, parameter `script` has value `"1"` (meaning > a string of length 1 with the sole number 1 as content). > > ``` > java.lang.NullPointerExceptionjava.lang.NullPointerException at > groovy.lang.GroovyClassLoader$InnerLoader.setDefaultAssertionStatus(GroovyClassLoader.java:617) > at > java.base/java.lang.ClassLoader.initializeClassLoaderAssertStatus(ClassLoader.java:1990) > at java.base/java.lang.ClassLoader.(ClassLoader.java:344) at > java.base/java.lang.ClassLoader.(ClassLoader.java:284) at > java.base/java.security.SecureClassLoader.(SecureClassLoader.java:77) > at java.base/java.net.URLClassLoader.(URLClassLoader.java:232) at > groovy.lang.GroovyClassLoader.(GroovyClassLoader.java:158) at > groovy.lang.GroovyClassLoader.(GroovyClassLoader.java:147) at > groovy.lang.GroovyClassLoader$InnerLoader.(GroovyClassLoader.java:472) > at > groovy.lang.GroovyClassLoader.lambda$createCollector$4(GroovyClassLoader.java:671) > at groovy.lang.GroovyClassLoader$$Lambda$397.283EE5D0.run(Unknown > Source) at > java.base/java.security.AccessController.doPrivileged(AccessController.java:678) > at groovy.lang.GroovyClassLoader.createCollector(GroovyClassLoader.java:671) > at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:385) at > groovy.lang.GroovyClassLoader.lambda$parseClass$3(GroovyClassLoader.java:332) > at groovy.lang.GroovyClassLoader$$Lambda$345.284B4BF0.provide(Unknown > Source) at > org.codehaus.groovy.runtime.memoize.StampedCommonCache.compute(StampedCommonCache.java:163) > at > org.codehaus.groovy.runtime.memoize.StampedCommonCache.getAndPut(StampedCommonCache.java:154) > at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:330) at > groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:314) at > groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:257) at > org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.getScriptClass(GroovyScriptEngineImpl.java:336) > at > org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:153) > at > java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:233) > at > it.unibo.alchemist.loader.variables.JSR223Variable.getWith(JSR223Variable.kt:39) > at it.unibo.alchemist.loader.YamlLoader.(YamlLoader.java:287) at > it.unibo.alchemist.loader.YamlLoader.(YamlLoader.java:220) at > it.unibo.alchemist.SimulationLauncher.launch(SimulationLauncher.kt:42) at > it.unibo.alchemist.Launcher$DefaultImpls.invoke(Launcher.kt:20) at > it.unibo.alchemist.SimulationLauncher.invoke(SimulationLauncher.kt:27) at > it.unibo.alchemist.Alchemist.main(Alchemist.kt:115) at > TestCLIKt$runWithOptions$exit$1.invoke(TestCLI.kt:48) at > TestCLIKt$runWithOptions$exit$1.invoke(TestCLI.kt) at > TestCLIKt.runCatchingExit(TestCLI.kt:38) at > TestCLIKt.runWithOptions(TestCLI.kt:47) at > TestCLI$1$2.invokeSuspend(TestCLI.kt:69) at TestCLI$1$2.invoke(TestCLI.kt) at > io.kotlintest.runner.jvm.TestCaseExecutor$executeTest$supervisorJob$1$invokeSuspend$$inlined$map$lambda$1.invokeSuspend(TestCaseExecutor.kt:121) > at > kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) > at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:56) at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:831) > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GROOVY-9493) JSR 223 regression: not working under OpenJ9 since version 3.0.0
[ https://issues.apache.org/jira/browse/GROOVY-9493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Theodorou reassigned GROOVY-9493: Assignee: Jochen Theodorou > JSR 223 regression: not working under OpenJ9 since version 3.0.0 > > > Key: GROOVY-9493 > URL: https://issues.apache.org/jira/browse/GROOVY-9493 > Project: Groovy > Issue Type: Bug > Components: groovy-jsr223 >Affects Versions: 3.0.0, 3.0.1, 3.0.2 >Reporter: Danilo Pianini >Assignee: Jochen Theodorou >Priority: Major > > Since version 3.0.0, Groovy fails at running JSR 223 scripts under OpenJ9. > The issue does not appear under OpenJDK. > > The following is the result of the attempted evaluation of the script `1` > under OpenJ9 12. The failure is reproducible with OpenJ9 11 and OpenJ9 14. > Inside `GroovyScriptEngineImpl`, parameter `script` has value `"1"` (meaning > a string of length 1 with the sole number 1 as content). > > ``` > java.lang.NullPointerExceptionjava.lang.NullPointerException at > groovy.lang.GroovyClassLoader$InnerLoader.setDefaultAssertionStatus(GroovyClassLoader.java:617) > at > java.base/java.lang.ClassLoader.initializeClassLoaderAssertStatus(ClassLoader.java:1990) > at java.base/java.lang.ClassLoader.(ClassLoader.java:344) at > java.base/java.lang.ClassLoader.(ClassLoader.java:284) at > java.base/java.security.SecureClassLoader.(SecureClassLoader.java:77) > at java.base/java.net.URLClassLoader.(URLClassLoader.java:232) at > groovy.lang.GroovyClassLoader.(GroovyClassLoader.java:158) at > groovy.lang.GroovyClassLoader.(GroovyClassLoader.java:147) at > groovy.lang.GroovyClassLoader$InnerLoader.(GroovyClassLoader.java:472) > at > groovy.lang.GroovyClassLoader.lambda$createCollector$4(GroovyClassLoader.java:671) > at groovy.lang.GroovyClassLoader$$Lambda$397.283EE5D0.run(Unknown > Source) at > java.base/java.security.AccessController.doPrivileged(AccessController.java:678) > at groovy.lang.GroovyClassLoader.createCollector(GroovyClassLoader.java:671) > at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:385) at > groovy.lang.GroovyClassLoader.lambda$parseClass$3(GroovyClassLoader.java:332) > at groovy.lang.GroovyClassLoader$$Lambda$345.284B4BF0.provide(Unknown > Source) at > org.codehaus.groovy.runtime.memoize.StampedCommonCache.compute(StampedCommonCache.java:163) > at > org.codehaus.groovy.runtime.memoize.StampedCommonCache.getAndPut(StampedCommonCache.java:154) > at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:330) at > groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:314) at > groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:257) at > org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.getScriptClass(GroovyScriptEngineImpl.java:336) > at > org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:153) > at > java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:233) > at > it.unibo.alchemist.loader.variables.JSR223Variable.getWith(JSR223Variable.kt:39) > at it.unibo.alchemist.loader.YamlLoader.(YamlLoader.java:287) at > it.unibo.alchemist.loader.YamlLoader.(YamlLoader.java:220) at > it.unibo.alchemist.SimulationLauncher.launch(SimulationLauncher.kt:42) at > it.unibo.alchemist.Launcher$DefaultImpls.invoke(Launcher.kt:20) at > it.unibo.alchemist.SimulationLauncher.invoke(SimulationLauncher.kt:27) at > it.unibo.alchemist.Alchemist.main(Alchemist.kt:115) at > TestCLIKt$runWithOptions$exit$1.invoke(TestCLI.kt:48) at > TestCLIKt$runWithOptions$exit$1.invoke(TestCLI.kt) at > TestCLIKt.runCatchingExit(TestCLI.kt:38) at > TestCLIKt.runWithOptions(TestCLI.kt:47) at > TestCLI$1$2.invokeSuspend(TestCLI.kt:69) at TestCLI$1$2.invoke(TestCLI.kt) at > io.kotlintest.runner.jvm.TestCaseExecutor$executeTest$supervisorJob$1$invokeSuspend$$inlined$map$lambda$1.invokeSuspend(TestCaseExecutor.kt:121) > at > kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) > at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:56) at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:831) > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11158) Explore whether we should deprecate/delete any generated callsite caching related classes
[ https://issues.apache.org/jira/browse/GROOVY-11158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756090#comment-17756090 ] Jochen Theodorou commented on GROOVY-11158: --- I created https://github.com/apache/groovy/pull/1934 to give an impression of the impact of the callsite caching code. > Explore whether we should deprecate/delete any generated callsite caching > related classes > - > > Key: GROOVY-11158 > URL: https://issues.apache.org/jira/browse/GROOVY-11158 > Project: Groovy > Issue Type: Task >Reporter: Paul King >Priority: Major > Fix For: 5.x > > > See the mailing list discussion: > https://lists.apache.org/thread/hvfxv7j9bnrj6l48c1hnd7px4qhdn7b7 > We want to retain any classes needed for backwards compatibility, e.g. > classes embedded in the bytecode generated from older groovy versions. But we > should deprecate classes as appropriate. Some may be possible to delete > altogether. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11159) ClassNode: separate type definition information
[ https://issues.apache.org/jira/browse/GROOVY-11159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755952#comment-17755952 ] Jochen Theodorou commented on GROOVY-11159: --- I would do for example TypeReference, ClassNode and maybe something like ResolvedClass. in class A extends B, A would become a ClassNode with all the fields and methods, B would be a TypeReference maybe to be resolved by the compiler. If B is backed by a to be compiled class, it points to a ClassNode, otherwise it would point to a ResolvedClass. And maybe I would even have another class you can use to get all the fields and methods from, which you get from ResolvedClass and maybe also ClassNode. Then we could move the lazy init to that part Of course ClassNode would not need the lazy init anymore in this scenario. Well, just an idea. and of course it will break about every transform there is. > ClassNode: separate type definition information > --- > > Key: GROOVY-11159 > URL: https://issues.apache.org/jira/browse/GROOVY-11159 > Project: Groovy > Issue Type: Improvement >Reporter: Eric Milles >Priority: Minor > > ClassNode is used to represent type definitions as well as type references. > There are a lot of data members that apply only to type definitions. > However, every reference pays the cost. ClassNode could have a single > reference to another class (essentially a struct) that holds all the > definition information. With this, type references would only have one > reference (initialized to null) instead of all those fields. > Fields: > * modifiers > * syntheticPublic > * superClass > * interfaces > * mixins > * objectInitializers > * constructors > * methods > * methodsList > * fields > * properties > * fieldIndex > * module > * compileUnit > * staticClass > * scriptBody > * script > * innerClasses > * transformInstances? > * lazyInitDone > * lazyInitLock > * clazz > * permittedSubclasses > * recordComponents -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11154) Script subclasses cannot have constructors with arguments
[
https://issues.apache.org/jira/browse/GROOVY-11154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755621#comment-17755621
]
Jochen Theodorou commented on GROOVY-11154:
---
Thinking out loud: How and when do you identify the unused constructors?
Normally I would have said that we add the constructors much later, like we do
for normal classes. But GROOVY-8096 sounds like a problem for that. We could
mark them as synthetic and then the ones from @InheritConstrcutors would not be
synthetic... But is a rule "if there is a non-synthetic constructor in a
generated script class remove all synthetic ones" sound? Maybe worth a try.
But if one would indeed use @Field and @InheritConstructors in the phases they
are intended to be used, then this will not work, as field is running first and
would modify the wrong constructor.
Maybe we should instead apply InheritConstructors early? If the script base
class is set, we take it from there, otherwise from the given class... And
then @BaseScript is in the way.. sigh.
Or another idea we add a fake constructor to the script, let transforms run
wild with it and then use the contents of that constructor to add it to other
added constructors in a later phase That way the base script would be
resolved, Field would have already added its fields to the constructor and that
code would be copied then to the constructors added by the inherit transform...
still sounds messy to me, but could work.
> Script subclasses cannot have constructors with arguments
> -
>
> Key: GROOVY-11154
> URL: https://issues.apache.org/jira/browse/GROOVY-11154
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 4.0.7
>Reporter: jonny
>Priority: Major
>
> Prior to the fix for GROOVY-9857, subclasses of {{Script}} could have
> constructor arguments and still be used (with a little help from
> {{InheritConstructors}} and {{DefaultGroovyMethods#newInstance}}).
> For example, the following script executes find in Groovy 3.x, but fails
> after Groovy 4.0.7:
> {code}
> import groovy.transform.InheritConstructors
> import org.codehaus.groovy.ast.AnnotationNode
> import org.codehaus.groovy.ast.ClassNode
> import org.codehaus.groovy.classgen.GeneratorContext
> import org.codehaus.groovy.control.CompilationFailedException
> import org.codehaus.groovy.control.CompilePhase
> import org.codehaus.groovy.control.CompilerConfiguration
> import org.codehaus.groovy.control.SourceUnit
> import org.codehaus.groovy.control.customizers.CompilationCustomizer
> import org.codehaus.groovy.runtime.DefaultGroovyMethods
> abstract class NamedScript extends Script {
> NamedScript(String name) {
> }
> }
> def compilerConfig = new CompilerConfiguration()
> compilerConfig.setScriptBaseClass(NamedScript.class.getName())
> compilerConfig.addCompilationCustomizers(new
> CompilationCustomizer(CompilePhase.CONVERSION) {
> @Override
> void call(SourceUnit source, GeneratorContext context, ClassNode
> classNode) throws CompilationFailedException {
> classNode.addAnnotation(new AnnotationNode(new
> ClassNode(InheritConstructors.class)))
> }
> })
> def classLoader = new GroovyClassLoader(new GroovyClassLoader(),
> compilerConfig)
> def parsedClass = classLoader.parseClass('println "Foo"')
> DefaultGroovyMethods.newInstance(parsedClass, "dummy").run()
> {code}
> The error returned is:
> {noformat}
> Implicit super constructor NamedScript() is undefined for generated
> constructor. Must define an explicit constructor.
> {noformat}
> Ratpack relies on this behavior for its custom text template renderer.
> See how script objects are instantiated in the
> [ScriptEngine#create|https://github.com/ratpack/ratpack/blob/503060ab2351a49f6e96416d588607ff7ef63028/ratpack-groovy/src/main/java/ratpack/groovy/script/internal/ScriptEngine.java#L51]
> method.
> I talked this out in the Groovy community Slack with [~blackdrag] (see
> [thread|https://groovy-community.slack.com/archives/C2NEFCM55/p1691783910137829]),
> who suggested that we should skip the check for constructors for Script
> subclasses as a bugfix in Groovy 4, with a potentially breaking change in
> Groovy 5 to make constructor generation for Script subclasses happen in the
> same place as any other class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11158) Explore whether we should deprecate/delete any generated callsite caching related classes
[ https://issues.apache.org/jira/browse/GROOVY-11158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755584#comment-17755584 ] Jochen Theodorou edited comment on GROOVY-11158 at 8/17/23 2:42 PM: After looking more closely I think there is actually quite a few places that would require adaption, including breaking changes. was (Author: blackdrag): After looking more closely I tihnk there is actually quite a few places that would require adaption, including breaking changes. > Explore whether we should deprecate/delete any generated callsite caching > related classes > - > > Key: GROOVY-11158 > URL: https://issues.apache.org/jira/browse/GROOVY-11158 > Project: Groovy > Issue Type: Task >Reporter: Paul King >Priority: Major > Fix For: 5.x > > > See the mailing list discussion: > https://lists.apache.org/thread/hvfxv7j9bnrj6l48c1hnd7px4qhdn7b7 > We want to retain any classes needed for backwards compatibility, e.g. > classes embedded in the bytecode generated from older groovy versions. But we > should deprecate classes as appropriate. Some may be possible to delete > altogether. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11158) Explore whether we should deprecate/delete any generated callsite caching related classes
[ https://issues.apache.org/jira/browse/GROOVY-11158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755584#comment-17755584 ] Jochen Theodorou commented on GROOVY-11158: --- After looking more closely I tihnk there is actually quite a few places that would require adaption, including breaking changes. > Explore whether we should deprecate/delete any generated callsite caching > related classes > - > > Key: GROOVY-11158 > URL: https://issues.apache.org/jira/browse/GROOVY-11158 > Project: Groovy > Issue Type: Task >Reporter: Paul King >Priority: Major > Fix For: 5.x > > > See the mailing list discussion: > https://lists.apache.org/thread/hvfxv7j9bnrj6l48c1hnd7px4qhdn7b7 > We want to retain any classes needed for backwards compatibility, e.g. > classes embedded in the bytecode generated from older groovy versions. But we > should deprecate classes as appropriate. Some may be possible to delete > altogether. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11158) Explore whether we should deprecate/delete any generated callsite caching related classes
[ https://issues.apache.org/jira/browse/GROOVY-11158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755580#comment-17755580 ] Jochen Theodorou commented on GROOVY-11158: --- My wish would be to "long term" to take the all classes in org.codehaus.groovy.runtime.callsite, make them deprecated and move them to a groovy-lagacy kind of jar, that is then only required if you want to run groovy with callsite caching. I think only CachedClass#getCallSiteLoader would also have to be moved, causing a breaking change in the public api. Though I think the risk is really low > Explore whether we should deprecate/delete any generated callsite caching > related classes > - > > Key: GROOVY-11158 > URL: https://issues.apache.org/jira/browse/GROOVY-11158 > Project: Groovy > Issue Type: Task >Reporter: Paul King >Priority: Major > Fix For: 5.x > > > See the mailing list discussion: > https://lists.apache.org/thread/hvfxv7j9bnrj6l48c1hnd7px4qhdn7b7 > We want to retain any classes needed for backwards compatibility, e.g. > classes embedded in the bytecode generated from older groovy versions. But we > should deprecate classes as appropriate. Some may be possible to delete > altogether. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11154) Script subclasses cannot have constructors with arguments
[
https://issues.apache.org/jira/browse/GROOVY-11154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755578#comment-17755578
]
Jochen Theodorou commented on GROOVY-11154:
---
I forgot the later part of the question.. does this generate a constructor that
passes name through to NamedScript? Yes, it does. In other words 3 constructor
would exist, of which 2 are added by us and they contain super() or
super(binding), which both do not match available constructors in NamedScript.
@InheritConstructors adds a third one, which basically does super(name). Before
the check, the two duds we add wouldn't have been a problem since they are not
called. With the check they are correctly recognized as wrong.
> Script subclasses cannot have constructors with arguments
> -
>
> Key: GROOVY-11154
> URL: https://issues.apache.org/jira/browse/GROOVY-11154
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 4.0.7
>Reporter: jonny
>Priority: Major
>
> Prior to the fix for GROOVY-9857, subclasses of {{Script}} could have
> constructor arguments and still be used (with a little help from
> {{InheritConstructors}} and {{DefaultGroovyMethods#newInstance}}).
> For example, the following script executes find in Groovy 3.x, but fails
> after Groovy 4.0.7:
> {code}
> import groovy.transform.InheritConstructors
> import org.codehaus.groovy.ast.AnnotationNode
> import org.codehaus.groovy.ast.ClassNode
> import org.codehaus.groovy.classgen.GeneratorContext
> import org.codehaus.groovy.control.CompilationFailedException
> import org.codehaus.groovy.control.CompilePhase
> import org.codehaus.groovy.control.CompilerConfiguration
> import org.codehaus.groovy.control.SourceUnit
> import org.codehaus.groovy.control.customizers.CompilationCustomizer
> import org.codehaus.groovy.runtime.DefaultGroovyMethods
> abstract class NamedScript extends Script {
> NamedScript(String name) {
> }
> }
> def compilerConfig = new CompilerConfiguration()
> compilerConfig.setScriptBaseClass(NamedScript.class.getName())
> compilerConfig.addCompilationCustomizers(new
> CompilationCustomizer(CompilePhase.CONVERSION) {
> @Override
> void call(SourceUnit source, GeneratorContext context, ClassNode
> classNode) throws CompilationFailedException {
> classNode.addAnnotation(new AnnotationNode(new
> ClassNode(InheritConstructors.class)))
> }
> })
> def classLoader = new GroovyClassLoader(new GroovyClassLoader(),
> compilerConfig)
> def parsedClass = classLoader.parseClass('println "Foo"')
> DefaultGroovyMethods.newInstance(parsedClass, "dummy").run()
> {code}
> The error returned is:
> {noformat}
> Implicit super constructor NamedScript() is undefined for generated
> constructor. Must define an explicit constructor.
> {noformat}
> Ratpack relies on this behavior for its custom text template renderer.
> See how script objects are instantiated in the
> [ScriptEngine#create|https://github.com/ratpack/ratpack/blob/503060ab2351a49f6e96416d588607ff7ef63028/ratpack-groovy/src/main/java/ratpack/groovy/script/internal/ScriptEngine.java#L51]
> method.
> I talked this out in the Groovy community Slack with [~blackdrag] (see
> [thread|https://groovy-community.slack.com/archives/C2NEFCM55/p1691783910137829]),
> who suggested that we should skip the check for constructors for Script
> subclasses as a bugfix in Groovy 4, with a potentially breaking change in
> Groovy 5 to make constructor generation for Script subclasses happen in the
> same place as any other class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11154) Script subclasses cannot have constructors with arguments
[
https://issues.apache.org/jira/browse/GROOVY-11154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1779#comment-1779
]
Jochen Theodorou commented on GROOVY-11154:
---
[~emilles] ratpack adds @InheritConstructors by compiler customizer and the
script base class by compiler configuration. Meaning the @BaseScript annotation
is not used.
> Script subclasses cannot have constructors with arguments
> -
>
> Key: GROOVY-11154
> URL: https://issues.apache.org/jira/browse/GROOVY-11154
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 4.0.7
>Reporter: jonny
>Priority: Major
>
> Prior to the fix for GROOVY-9857, subclasses of {{Script}} could have
> constructor arguments and still be used (with a little help from
> {{InheritConstructors}} and {{DefaultGroovyMethods#newInstance}}).
> For example, the following script executes find in Groovy 3.x, but fails
> after Groovy 4.0.7:
> {code}
> import groovy.transform.InheritConstructors
> import org.codehaus.groovy.ast.AnnotationNode
> import org.codehaus.groovy.ast.ClassNode
> import org.codehaus.groovy.classgen.GeneratorContext
> import org.codehaus.groovy.control.CompilationFailedException
> import org.codehaus.groovy.control.CompilePhase
> import org.codehaus.groovy.control.CompilerConfiguration
> import org.codehaus.groovy.control.SourceUnit
> import org.codehaus.groovy.control.customizers.CompilationCustomizer
> import org.codehaus.groovy.runtime.DefaultGroovyMethods
> abstract class NamedScript extends Script {
> NamedScript(String name) {
> }
> }
> def compilerConfig = new CompilerConfiguration()
> compilerConfig.setScriptBaseClass(NamedScript.class.getName())
> compilerConfig.addCompilationCustomizers(new
> CompilationCustomizer(CompilePhase.CONVERSION) {
> @Override
> void call(SourceUnit source, GeneratorContext context, ClassNode
> classNode) throws CompilationFailedException {
> classNode.addAnnotation(new AnnotationNode(new
> ClassNode(InheritConstructors.class)))
> }
> })
> def classLoader = new GroovyClassLoader(new GroovyClassLoader(),
> compilerConfig)
> def parsedClass = classLoader.parseClass('println "Foo"')
> DefaultGroovyMethods.newInstance(parsedClass, "dummy").run()
> {code}
> The error returned is:
> {noformat}
> Implicit super constructor NamedScript() is undefined for generated
> constructor. Must define an explicit constructor.
> {noformat}
> Ratpack relies on this behavior for its custom text template renderer.
> See how script objects are instantiated in the
> [ScriptEngine#create|https://github.com/ratpack/ratpack/blob/503060ab2351a49f6e96416d588607ff7ef63028/ratpack-groovy/src/main/java/ratpack/groovy/script/internal/ScriptEngine.java#L51]
> method.
> I talked this out in the Groovy community Slack with [~blackdrag] (see
> [thread|https://groovy-community.slack.com/archives/C2NEFCM55/p1691783910137829]),
> who suggested that we should skip the check for constructors for Script
> subclasses as a bugfix in Groovy 4, with a potentially breaking change in
> Groovy 5 to make constructor generation for Script subclasses happen in the
> same place as any other class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11156) Groovy using no longer existing MagicAccessorImpl from sun.reflect
Jochen Theodorou created GROOVY-11156: - Summary: Groovy using no longer existing MagicAccessorImpl from sun.reflect Key: GROOVY-11156 URL: https://issues.apache.org/jira/browse/GROOVY-11156 Project: Groovy Issue Type: Improvement Reporter: Jochen Theodorou Since Java9 MagicAccessorImpl moved to a different package and does no longer fulfill the same role as before. While our code does not depend on that class to exist, it is also used almost solely for callsite caching code generation, which is no longer the default. Therefore removing the usage of class seems to be a good option at least for Groovy 5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11145) add a join() method for Iterable/List
[
https://issues.apache.org/jira/browse/GROOVY-11145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750438#comment-17750438
]
Jochen Theodorou commented on GROOVY-11145:
---
I think we made the design decision that implicit arguments are not supported
by static compilation. In fact we wanted it out of dynamic Groovy as well.
> add a join() method for Iterable/List
> -
>
> Key: GROOVY-11145
> URL: https://issues.apache.org/jira/browse/GROOVY-11145
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.5.12, 3.0.9, 4.0.13
>Reporter: Jochen Theodorou
>Priority: Minor
>
> {code:Java}
> @groovy.transform.CompileStatic
> def m() {
> ["a", "b"].join()
> }
> assert m() == "ab"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11143) Add extension method to source unit (same locality as static import)
[
https://issues.apache.org/jira/browse/GROOVY-11143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750428#comment-17750428
]
Jochen Theodorou commented on GROOVY-11143:
---
Yeah, that explains it in great detail for me. Originally the plan was to have
multiple switch points, depending on at least some receiver types. Then one
such change would not affect *all* method handles created so far. Never got
that far, and this is actually the first time a need for this pops up. But very
valid, yes
> Add extension method to source unit (same locality as static import)
>
>
> Key: GROOVY-11143
> URL: https://issues.apache.org/jira/browse/GROOVY-11143
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
>Reporter: Eric Milles
>Priority: Major
>
> I have been poking around with the many ways to extend a class/object's
> functionality within groovy. To add a new method that can be called like any
> other instance method, there are a few possibilities:
> 1. modify the MetaClass
> {code:groovy}
> String.metaClass.ext = { ->
> print delegate
> }
> "works".ext()
> {code}
> 2. use a category class
> {code:groovy}
> @Category(String) class Cat {
> void ext() {
> println this
> }
> }
> use (Cat) {
> "works".ext()
> }
> {code}
> 3. apply a mixin
> first create class similar to Cat in (2)
> {code:groovy}
> def str = "works"; str.metaClass.mixin(Cat)
> str.ext()
> {code}
> 4. apply a trait
> {code:groovy}
> trait Ext {
> void ext() { println this.toLowerCase() } // see GROOVY-11142
> }
> "works".withTraits(Ext).ext()
> {code}
> 5. create an extension moodule
> - create class similar to Cat in (2)
> - create META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule file
> - build and deploy separately from current script / project
> What I'm after is something that works as easily in a script or source file
> as static imports but lets me call like an extension method. And does not
> modify state outside of the current script (like {{MetaClass}}) or introduce
> a thread barrier (like {{use}}). And works with static type checking.
> Scala has an "extension" mechanism that is similar to static import but there
> is a keyword on the category class that lets compiler know the method is used
> like any other instance method. Scala used to provide "implicit" methods --
> I've lost my familiarity with those.
> I've seen "import static extension foo.Bar.baz;" for some language.
> (citation required)
> And lastly, Kotlin provides a local extension like this:
> {code}
> fun foo.Bar.baz() { x ->
> // ...
> }
> {code}
> For any new users or just to add something quickly that can be used in a
> file, I think I'm looking for an enhancement to "import static ..." that will
> get substituted in the source unit, like {{StaticImportVisitor}} does today
> for static method calls. For example:
> {code:groovy}
> import static foo.Bar.baz
> import static /*something*/ foo.Bar.baz
> baz("") // supported by first import
> "".baz() // supported by second import
> {code}
> I have been considering whether "extension", "default", some annotation or
> something else should be used for /\*something\*/ in the script above.
> Similar to Kotlin, this could let someone declare an extension in a single
> script with no dynamic runtime impact:
> {code:groovy}
> import static /*something*/ ThisScript.*
> static ext(String self) {
> print self
> }
> "works".ext()
> {code}
> Has anyone looked at something like this in Groovy or other languages and has
> some feedback?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11145) add a join() method for Iterable/List
[
https://issues.apache.org/jira/browse/GROOVY-11145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-11145:
--
Description:
{code:Java}
@groovy.transform.CompileStatic
def m() {
["a", "b"].join()
}
assert m() == "ab"
{code}
was:
{code:Java}
@groovy.transform.CompileStatic
def m() {
["a", "b"].join()
}
assert m() == "ab"
{code}
I expected the code above to work since there is a join(Iterable) method in
DGM, but the code gives instead a compilation error. Works of course in dynamic
mode.
Summary: add a join() method for Iterable/List (was: Iterable DGM not
recognized for List)
> add a join() method for Iterable/List
> -
>
> Key: GROOVY-11145
> URL: https://issues.apache.org/jira/browse/GROOVY-11145
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.5.12, 3.0.9, 4.0.13
>Reporter: Jochen Theodorou
>Priority: Major
>
> {code:Java}
> @groovy.transform.CompileStatic
> def m() {
> ["a", "b"].join()
> }
> assert m() == "ab"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11145) add a join() method for Iterable/List
[
https://issues.apache.org/jira/browse/GROOVY-11145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Theodorou updated GROOVY-11145:
--
Issue Type: Improvement (was: Bug)
> add a join() method for Iterable/List
> -
>
> Key: GROOVY-11145
> URL: https://issues.apache.org/jira/browse/GROOVY-11145
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.5.12, 3.0.9, 4.0.13
>Reporter: Jochen Theodorou
>Priority: Major
>
> {code:Java}
> @groovy.transform.CompileStatic
> def m() {
> ["a", "b"].join()
> }
> assert m() == "ab"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11145) add a join() method for Iterable/List
[
https://issues.apache.org/jira/browse/GROOVY-11145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750271#comment-17750271
]
Jochen Theodorou commented on GROOVY-11145:
---
I updated the issue
> add a join() method for Iterable/List
> -
>
> Key: GROOVY-11145
> URL: https://issues.apache.org/jira/browse/GROOVY-11145
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.5.12, 3.0.9, 4.0.13
>Reporter: Jochen Theodorou
>Priority: Major
>
> {code:Java}
> @groovy.transform.CompileStatic
> def m() {
> ["a", "b"].join()
> }
> assert m() == "ab"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11145) Iterable DGM not recognized for List
Jochen Theodorou created GROOVY-11145:
-
Summary: Iterable DGM not recognized for List
Key: GROOVY-11145
URL: https://issues.apache.org/jira/browse/GROOVY-11145
Project: Groovy
Issue Type: Bug
Components: Static compilation, Static Type Checker
Affects Versions: 4.0.13, 3.0.9, 2.5.12
Reporter: Jochen Theodorou
{code:Java}
@groovy.transform.CompileStatic
def m() {
["a", "b"].join()
}
assert m() == "ab"
{code}
I expected the code above to work since there is a join(Iterable) method in
DGM, but the code gives instead a compilation error. Works of course in dynamic
mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11143) Add extension method to source unit (same locality as static import)
[
https://issues.apache.org/jira/browse/GROOVY-11143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750238#comment-17750238
]
Jochen Theodorou commented on GROOVY-11143:
---
[~emilles] "The use method creates a thread barrier so we can’t call it in our
server process." Can you explain a bit what the problem with the server process
is?
> Add extension method to source unit (same locality as static import)
>
>
> Key: GROOVY-11143
> URL: https://issues.apache.org/jira/browse/GROOVY-11143
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
>Reporter: Eric Milles
>Priority: Major
>
> I have been poking around with the many ways to extend a class/object's
> functionality within groovy. To add a new method that can be called like any
> other instance method, there are a few possibilities:
> 1. modify the MetaClass
> {code:groovy}
> String.metaClass.ext = { ->
> print delegate
> }
> "works".ext()
> {code}
> 2. use a category class
> {code:groovy}
> @Category(String) class Cat {
> void ext() {
> println this
> }
> }
> use (Cat) {
> "works".ext()
> }
> {code}
> 3. apply a mixin
> first create class similar to Cat in (2)
> {code:groovy}
> def str = "works"; str.metaClass.mixin(Cat)
> str.ext()
> {code}
> 4. apply a trait
> {code:groovy}
> trait Ext {
> void ext() { println this.toLowerCase() } // see GROOVY-11142
> }
> "works".withTraits(Ext).ext()
> {code}
> 5. create an extension moodule
> - create class similar to Cat in (2)
> - create META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule file
> - build and deploy separately from current script / project
> What I'm after is something that works as easily in a script or source file
> as static imports but lets me call like an extension method. And does not
> modify state outside of the current script (like {{MetaClass}}) or introduce
> a thread barrier (like {{use}}). And works with static type checking.
> Scala has an "extension" mechanism that is similar to static import but there
> is a keyword on the category class that lets compiler know the method is used
> like any other instance method. Scala used to provide "implicit" methods --
> I've lost my familiarity with those.
> I've seen "import static extension foo.Bar.baz;" for some language.
> (citation required)
> And lastly, Kotlin provides a local extension like this:
> {code}
> fun foo.Bar.baz() { x ->
> // ...
> }
> {code}
> For any new users or just to add something quickly that can be used in a
> file, I think I'm looking for an enhancement to "import static ..." that will
> get substituted in the source unit, like {{StaticImportVisitor}} does today
> for static method calls. For example:
> {code:groovy}
> import static foo.Bar.baz
> import static /*something*/ foo.Bar.baz
> baz("") // supported by first import
> "".baz() // supported by second import
> {code}
> I have been considering whether "extension", "default", some annotation or
> something else should be used for /\*something\*/ in the script above.
> Similar to Kotlin, this could let someone declare an extension in a single
> script with no dynamic runtime impact:
> {code:groovy}
> import static /*something*/ ThisScript.*
> static ext(String self) {
> print self
> }
> "works".ext()
> {code}
> Has anyone looked at something like this in Groovy or other languages and has
> some feedback?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11143) Add extension method to source unit (same locality as static import)
[
https://issues.apache.org/jira/browse/GROOVY-11143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750028#comment-17750028
]
Jochen Theodorou commented on GROOVY-11143:
---
It depends on if you want to limit the visibility of the added method or not.
Restricting the visibility makes things quite difficult
> Add extension method to source unit (same locality as static import)
>
>
> Key: GROOVY-11143
> URL: https://issues.apache.org/jira/browse/GROOVY-11143
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
>Reporter: Eric Milles
>Priority: Major
>
> I have been poking around with the many ways to extend a class/object's
> functionality within groovy. To add a new method that can be called like any
> other instance method, there are a few possibilities:
> 1. modify the MetaClass
> {code:groovy}
> String.metaClass.ext = { ->
> print delegate
> }
> "works".ext()
> {code}
> 2. use a category class
> {code:groovy}
> @Category(String) class Cat {
> void ext() {
> println this
> }
> }
> use (Cat) {
> "works".ext()
> }
> {code}
> 3. apply a mixin
> first create class similar to Cat in (2)
> {code:groovy}
> def str = "works"; str.metaClass.mixin(Cat)
> str.ext()
> {code}
> 4. apply a trait
> {code:groovy}
> trait Ext {
> void ext() { println this.toLowerCase() } // see GROOVY-11142
> }
> "works".withTraits(Ext).ext()
> {code}
> 5. create an extension moodule
> - create class similar to Cat in (2)
> - create META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule file
> - build and deploy separately from current script / project
> What I'm after is something that works as easily in a script or source file
> as static imports but lets me call like an extension method. And does not
> modify state outside of the current script (like {{MetaClass}}) or introduce
> a thread barrier (like {{use}}). And works with static type checking.
> Scala has an "extension" mechanism that is similar to static import but there
> is a keyword on the category class that lets compiler know the method is used
> like any other instance method. Scala used to provide "implicit" methods --
> I've lost my familiarity with those.
> I've seen "import static extension foo.Bar.baz;" for some language.
> (citation required)
> And lastly, Kotlin provides a local extension like this:
> {code}
> fun foo.Bar.baz() { x ->
> // ...
> }
> {code}
> For any new users or just to add something quickly that can be used in a
> file, I think I'm looking for an enhancement to "import static ..." that will
> get substituted in the source unit, like {{StaticImportVisitor}} does today
> for static method calls. For example:
> {code:groovy}
> import static foo.Bar.baz
> import static /*something*/ foo.Bar.baz
> baz("") // supported by first import
> "".baz() // supported by second import
> {code}
> I have been considering whether "extension", "default", some annotation or
> something else should be used for /\*something\*/ in the script above.
> Similar to Kotlin, this could let someone declare an extension in a single
> script with no dynamic runtime impact:
> {code:groovy}
> import static /*something*/ ThisScript.*
> static ext(String self) {
> print self
> }
> "works".ext()
> {code}
> Has anyone looked at something like this in Groovy or other languages and has
> some feedback?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11143) Add extension method to source unit (same locality as static import)
[
https://issues.apache.org/jira/browse/GROOVY-11143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17749981#comment-17749981
]
Jochen Theodorou commented on GROOVY-11143:
---
[~emilles] "I've seen "import static extension foo.Bar.baz;" for some language.
(citation required)" was that maybe XText?
I did have a look at this before the Pivotal incident. I think it works easily
(there are many details to work out) in the static compiler, but in
non-static... I had the idea of meta class realms for this, but no time to
implement or really develop it in enough detail.
> Add extension method to source unit (same locality as static import)
>
>
> Key: GROOVY-11143
> URL: https://issues.apache.org/jira/browse/GROOVY-11143
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
>Reporter: Eric Milles
>Priority: Major
>
> I have been poking around with the many ways to extend a class/object's
> functionality within groovy. To add a new method that can be called like any
> other instance method, there are a few possibilities:
> 1. modify the MetaClass
> {code:groovy}
> String.metaClass.ext = { ->
> print delegate
> }
> "works".ext()
> {code}
> 2. use a category class
> {code:groovy}
> @Category(String) class Cat {
> void ext() {
> println this
> }
> }
> use (Cat) {
> "works".ext()
> }
> {code}
> 3. apply a mixin
> first create class similar to Cat in (2)
> {code:groovy}
> def str = "works"; str.metaClass.mixin(Cat)
> str.ext()
> {code}
> 4. apply a trait
> {code:groovy}
> trait Ext {
> void ext() { println this.toLowerCase() } // see GROOVY-11142
> }
> "works".withTraits(Ext).ext()
> {code}
> 5. create an extension moodule
> - create class similar to Cat in (2)
> - create META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule file
> - build and deploy separately from current script / project
> What I'm after is something that works as easily in a script or source file
> as static imports but lets me call like an extension method. And does not
> modify state outside of the current script (like {{MetaClass}}) or introduce
> a thread barrier (like {{use}}). And works with static type checking.
> Scala has an "extension" mechanism that is similar to static import but there
> is a keyword on the category class that lets compiler know the method is used
> like any other instance method. Scala used to provide "implicit" methods --
> I've lost my familiarity with those.
> I've seen "import static extension foo.Bar.baz;" for some language.
> (citation required)
> And lastly, Kotlin provides a local extension like this:
> {code}
> fun foo.Bar.baz() { x ->
> // ...
> }
> {code}
> For any new users or just to add something quickly that can be used in a
> file, I think I'm looking for an enhancement to "import static ..." that will
> get substituted in the source unit, like {{StaticImportVisitor}} does today
> for static method calls. For example:
> {code:groovy}
> import static foo.Bar.baz
> import static /*something*/ foo.Bar.baz
> baz("") // supported by first import
> "".baz() // supported by second import
> {code}
> I have been considering whether "extension", "default", some annotation or
> something else should be used for /\*something\*/ in the script above.
> Similar to Kotlin, this could let someone declare an extension in a single
> script with no dynamic runtime impact:
> {code:groovy}
> import static /*something*/ ThisScript.*
> static ext(String self) {
> print self
> }
> "works".ext()
> {code}
> Has anyone looked at something like this in Groovy or other languages and has
> some feedback?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747119#comment-17747119
]
Jochen Theodorou commented on GROOVY-10931:
---
[~emilles]If a method is not accessible and cannot be made accessible, then it
should not be part of the method selection. In the case here we are talking
about the same module. Assuming it is the unnamed module then
"--add-opens=java.base/java.lang.reflect=ALL-UNNAMED" should for example allow
all cases here.
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking, invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
