[jira] [Updated] (GROOVY-8669) Groovy class does not compile if the ValueType of an annotation is not on the classpath
[
https://issues.apache.org/jira/browse/GROOVY-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Turban updated GROOVY-8669:
---
Description:
If a groovy class (Test.groovy) references a class (AnnotatedClass) which has
an annotation (Annotation) with a value class (ValueClass), which is not on the
classpath an NoClassDefFoundError is thrown.
{{This does happen during Compilation. This did not happen in Groovy 2.4.15.}}
{{The stacktrace is:}}
{{Caused by: java.lang.NoClassDefFoundError: annos.ValueClass}}
{{ at
org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClass(AsmReferenceResolver.java:48)}}
{{ at
org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveNonArrayType(AsmReferenceResolver.java:81)}}
{{ at
org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveType(AsmReferenceResolver.java:72)}}
{{ at
org.codehaus.groovy.ast.decompiled.Annotations.annotationValueToExpression(Annotations.java:58)}}
{{ at
org.codehaus.groovy.ast.decompiled.Annotations.createAnnotationNode(Annotations.java:51)}}
\{{ at }}
I think the class org.codehaus.groovy.ast.decompiled.Annotations should also
ignore annotation nodes, if the values type is not resolvable. Like it is done
if the annotation type itself is not resolvable, see line 43-46.
I have attached a simple sample to reproduce the issue.
1. Compile it with gradle build
2. Open the jar file annos/build/libs/annos.jar
3. Delete the classfile annos/ValueClass.class
4. Compile it with gradle :client:build
Now the exception is thrown.
was:
If a groovy class (Test.groovy) references a class (AnnotatedClass) which has
an annotation (Annotation) with a value class (ValueClass), which is not on the
classpath an NoClassDefFoundError is thrown.
{{This does happen during Compilation. This did not happen in Groovy 2.4.15.}}
{{The stacktrace is:}}
{{Caused by: java.lang.NoClassDefFoundError: annos.valueClass}}
{{ at
org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClass(AsmReferenceResolver.java:48)}}
{{ at
org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveNonArrayType(AsmReferenceResolver.java:81)}}
{{ at
org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveType(AsmReferenceResolver.java:72)}}
{{ at
org.codehaus.groovy.ast.decompiled.Annotations.annotationValueToExpression(Annotations.java:58)}}
{{ at
org.codehaus.groovy.ast.decompiled.Annotations.createAnnotationNode(Annotations.java:51)}}
{{ at }}
I think the class org.codehaus.groovy.ast.decompiled.Annotations should also
ignore annotation nodes, if the values type is not resolvable. Like it is done
if the annotation type itself is not resolvable, see line 43-46.
I have attached a simple sample to reproduce the issue.
1. Compile it with gradle build
2. Open the jar file annos/build/libs/annos.jar
3. Delete the classfile annos/ValueClass.class
4. Compile it with gradle :client:build
Now the exception is thrown.
> Groovy class does not compile if the ValueType of an annotation is not on the
> classpath
> ---
>
> Key: GROOVY-8669
> URL: https://issues.apache.org/jira/browse/GROOVY-8669
> Project: Groovy
> Issue Type: Bug
> Components: class generator
>Affects Versions: 2.5.0
>Reporter: Andreas Turban
>Priority: Major
> Labels: annotations, compile-error
> Attachments: AnnoTest.zip
>
>
> If a groovy class (Test.groovy) references a class (AnnotatedClass) which has
> an annotation (Annotation) with a value class (ValueClass), which is not on
> the classpath an NoClassDefFoundError is thrown.
> {{This does happen during Compilation. This did not happen in Groovy 2.4.15.}}
> {{The stacktrace is:}}
> {{Caused by: java.lang.NoClassDefFoundError: annos.ValueClass}}
> {{ at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClass(AsmReferenceResolver.java:48)}}
> {{ at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveNonArrayType(AsmReferenceResolver.java:81)}}
> {{ at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveType(AsmReferenceResolver.java:72)}}
> {{ at
> org.codehaus.groovy.ast.decompiled.Annotations.annotationValueToExpression(Annotations.java:58)}}
> {{ at
> org.codehaus.groovy.ast.decompiled.Annotations.createAnnotationNode(Annotations.java:51)}}
> \{{ at }}
> I think the class org.codehaus.groovy.ast.decompiled.Annotations should also
> ignore annotation nodes, if the values type is not resolvable. Like it is
> done if the annotation type itself is not resolvable, see line 43-46.
> I have attached a simple sample to reproduce the issue.
> 1. Compile it with gradle build
> 2. Open the jar file annos/build/libs/annos.j
[jira] [Created] (GROOVY-8669) Groovy class does not compile if the ValueType of an annotation is not on the classpath
Andreas Turban created GROOVY-8669:
--
Summary: Groovy class does not compile if the ValueType of an
annotation is not on the classpath
Key: GROOVY-8669
URL: https://issues.apache.org/jira/browse/GROOVY-8669
Project: Groovy
Issue Type: Bug
Components: class generator
Affects Versions: 2.5.0
Reporter: Andreas Turban
Attachments: AnnoTest.zip
If a groovy class (Test.groovy) references a class (AnnotatedClass) which has
an annotation (Annotation) with a value class (ValueClass), which is not on the
classpath an NoClassDefFoundError is thrown.
{{This does happen during Compilation. This did not happen in Groovy 2.4.15.}}
{{The stacktrace is:}}
{{Caused by: java.lang.NoClassDefFoundError: annos.valueClass}}
{{ at
org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClass(AsmReferenceResolver.java:48)}}
{{ at
org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveNonArrayType(AsmReferenceResolver.java:81)}}
{{ at
org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveType(AsmReferenceResolver.java:72)}}
{{ at
org.codehaus.groovy.ast.decompiled.Annotations.annotationValueToExpression(Annotations.java:58)}}
{{ at
org.codehaus.groovy.ast.decompiled.Annotations.createAnnotationNode(Annotations.java:51)}}
{{ at }}
I think the class org.codehaus.groovy.ast.decompiled.Annotations should also
ignore annotation nodes, if the values type is not resolvable. Like it is done
if the annotation type itself is not resolvable, see line 43-46.
I have attached a simple sample to reproduce the issue.
1. Compile it with gradle build
2. Open the jar file annos/build/libs/annos.jar
3. Delete the classfile annos/ValueClass.class
4. Compile it with gradle :client:build
Now the exception is thrown.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8666) New partial groovy 2.5 causes split-packages itself
[ https://issues.apache.org/jira/browse/GROOVY-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16524946#comment-16524946 ] Paul King commented on GROOVY-8666: --- You can look at the jarAll task in assemble.gradle from the GROOVY_2_4_X branch or in the history (late 2017) in the other branches. I am investigating whether we can configure bnd to specify split packages. > New partial groovy 2.5 causes split-packages itself > --- > > Key: GROOVY-8666 > URL: https://issues.apache.org/jira/browse/GROOVY-8666 > Project: Groovy > Issue Type: Bug > Components: release >Affects Versions: 2.5.0 >Reporter: Josef Härtl >Priority: Major > > The splitting of groovy into smaller causes another, very major, problem: > First, consider the "main" groovy jar: It contains the package groovy.util > with numerous classes. > Secondly, consider the groovy-xml jar. It contains the package groovy.util > and therein the classes XMLParser etc. > Regardless whether you use OSGi (like in our case) or Java 9 (what we are > migrating to): This presents a split-package itself: As we already reproduced > in our build: Whatever jar of these is loaded first wins the groovy.util > package and "overrides" the other. > As a result, it's become random whether our users can use XMLParser or not. > Sometimes it is found, sometimes it's not. I consider this a very major > problem and a blocker as it makes execution unreliable and randomish. I did > not check but somewhat guess that this is not the only collision of this sort. > Therefore, the splitting of groovy 2.5 into smaller pieces introduced > split-packages to itself. If one wants to split groovy, the split will have > to follow package borders. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #762: BigDecimalMath.MAX_DIVISION_SCALE is hard-coded to...
GitHub user pierrepinon opened a pull request: https://github.com/apache/groovy/pull/762 BigDecimalMath.MAX_DIVISION_SCALE is hard-coded to 10 digits The "scale" for BigDecimal division is hard-coded to 10 (BigDecimalMath.MAX_DIVISION_SCALE), which is fewer than the roughly equivalent 16-17 digits for double (64-bit) division. It seems like the default scale should be at least as accurate as double division. Also it is probably desirable for this setting to be configurable in some way, maybe more than one. Maybe a global Java system property setting, and then some form of context related override (per-thread, per-script, etc.). I use this fix for 2 years without side effects on a software for a big company. For comparison, Excel use a round with 15 digit after decimal You can merge this pull request into a Git repository by running: $ git pull https://github.com/pierrepinon/groovy master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/762.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #762 commit e5bbe6fd94f36389242b415a8d2c685f03ac51d9 Author: Pierre Pinon Date: 2018-06-27T07:35:10Z Update BigDecimalMath.java Fix GROOVY-2675 ---
