[jira] [Created] (GROOVY-8461) We should do an assessment of our AST transformations cf the immutables.org library
Paul King created GROOVY-8461: - Summary: We should do an assessment of our AST transformations cf the immutables.org library Key: GROOVY-8461 URL: https://issues.apache.org/jira/browse/GROOVY-8461 Project: Groovy Issue Type: Task Reporter: Paul King https://immutables.github.io/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8338) Calling Stream.of from groovy class in JDK 9 fails
[
https://issues.apache.org/jira/browse/GROOVY-8338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342298#comment-16342298
]
Slawomir Nowak commented on GROOVY-8338:
Do you have any idea when this could be fixed?
> Calling Stream.of from groovy class in JDK 9 fails
> --
>
> Key: GROOVY-8338
> URL: https://issues.apache.org/jira/browse/GROOVY-8338
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.12
>Reporter: Marcus Nylander
>Priority: Major
>
> Trying to call Stream.of from groovy class (groovy version 2.4.12) using JDK
> 9 (jdk 9 181) fails.
> Example:
> {code}
> package test
> import java.util.stream.Stream
> class B {
> static void main(String[] args) {
> Stream.of("1").forEach({ println(it) })
> }
> }
> {code}
> The code above fails with:
> Exception in thread "main" java.lang.IncompatibleClassChangeError: Method
> java.util.stream.Stream.of(Ljava/lang/Object;)Ljava/util/stream/Stream; must
> be InterfaceMethodref constant
> at java_util_stream_Stream$of.call(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
> at test.B.main(B.groovy:7)
> The same occurs for other interface static methods also:
> {code}
> public interface D {
> static D of(String s) {
> return new D() {
> };
> }
> }
> class C {
> static void main(String[] args) {
> D.of("1")
> }
> }
> {code}
> Also fails with:
> Exception in thread "main" java.lang.IncompatibleClassChangeError: Method
> test.D.of(Ljava/lang/String;)Ltest/D; must be InterfaceMethodref constant
> at test.D$of.call(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
> at test.C.main(C.groovy:7)
> Running with JDK 8 works fine.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-6844) "Break label" instruction broken when combining nested loops with "old-school" labeled code blocks
[
https://issues.apache.org/jira/browse/GROOVY-6844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342210#comment-16342210
]
Evermind commented on GROOVY-6844:
--
After a few exploration I got the conclusion that break seems only work
for labels placed before a loop control statement i.e. for and while. If label
is placed elsewhere, the break statement just ignores and break
from current loop level.
It's astonishing nowhere mentioned this behavior in the document and other
materials, and compiler just ignores the misplaced label without error or
runtime exception. Even example in document doesn't work.
* mentioned document and example is in
[http://groovy-lang.org/semantics.html|http://groovy-lang.org/semantics.html,]
section 1.5.
> "Break label" instruction broken when combining nested loops with
> "old-school" labeled code blocks
> --
>
> Key: GROOVY-6844
> URL: https://issues.apache.org/jira/browse/GROOVY-6844
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.3.2
>Reporter: Davide Cavestro
>Priority: Major
>
> I've seen in groovy _the break statement with named label is only allowed
> inside loops_, in fact executing the following snippet from groovyConsole
> {code}
> foo: {
> println "foo"
> break foo
> }
> {code}
> I get this output {quote}
> 2 compilation errors:
> the break statement with named label is only allowed inside loops
> at line: 5, column: 13
> break to missing label
> at line: 5, column: 13
> {quote}
> Bu this morning a colleague of mine discovered that if you combine
> *old-school label definition* with a *break label used within two nested
> loops* you obtain no compile/runtime errors. Instead the executed logic is
> not the expected one, at least not what you would expect when you write that
> kind of code.
> It seems that the _break label_ instruction simply breaks the innermost loop
> execution, continuing with the outer one (hence ignoring the label).
> Follows a test based on the example took from
> http://docs.codehaus.org/display/GROOVY/JN2535-Control:
> Its output shows how the labeled code block is *re-executed after the
> {{break}}*
> {code:title=Foo.groovy}
> def i=0, j=0
> outer: {
> println "executing outer block"
> while( i<5 ){ //labelling a while loop is especially useful...
> j= 0
> i++
> println "executing outer while, i: $i, j: $j"
> while( j<5 ){
> j++
> println "executing inner while, i: $i, j: $j"
> if( i==3 && j==2 ) break outer
> //...because we can break out of a specified labelled while loop
> }
> }
> }
> assert i==3 && j==2
> {code}
> This is its execution output:
> {quote}
> executing outer block
> executing outer while, i: 1, j: 0
> executing inner while, i: 1, j: 1
> executing inner while, i: 1, j: 2
> executing inner while, i: 1, j: 3
> executing inner while, i: 1, j: 4
> executing inner while, i: 1, j: 5
> executing outer while, i: 2, j: 0
> executing inner while, i: 2, j: 1
> executing inner while, i: 2, j: 2
> executing inner while, i: 2, j: 3
> executing inner while, i: 2, j: 4
> executing inner while, i: 2, j: 5
> executing outer while, i: 3, j: 0
> executing inner while, i: 3, j: 1
> executing inner while, i: 3, j: 2
> executing outer while, i: 4, j: 0
> executing inner while, i: 4, j: 1
> executing inner while, i: 4, j: 2
> executing inner while, i: 4, j: 3
> executing inner while, i: 4, j: 4
> executing inner while, i: 4, j: 5
> executing outer while, i: 5, j: 0
> executing inner while, i: 5, j: 1
> executing inner while, i: 5, j: 2
> executing inner while, i: 5, j: 3
> executing inner while, i: 5, j: 4
> executing inner while, i: 5, j: 5
> Exception in thread "main" Assertion failed:
> assert i==3 && j==2
>|| |
>5| false
> false
> at
> org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:398)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:646)
> at Bar.main(Bar.groovy:27)
> {quote}
> Follows the java counterpart, whose output shows how the labeled code block
> is not executed after the {{break}}
> {code:title=Foo.java}
> public class Foo {
> public static void main(String[] args) {
> int i = 0, j = 0;
> outer: {
> println("executing outer block");
> while (i < 5) { // labelling a while loop is especially useful...
> j = 0;
> i++;
> println("executing outer while, i: " + i + ", j: " + j);
> while (j < 5) {
> j++;
> println("executing inner while, i: " + i + ", j: " + j);
> if (i == 3 &&
[jira] [Commented] (GROOVY-8458) File leak in Eclipse Plugin
[ https://issues.apache.org/jira/browse/GROOVY-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342069#comment-16342069 ] Peter Kriens commented on GROOVY-8458: -- Ok, looking at the code and your comment I understand the loaders stay open, which is explaining the problem. Setting an option in eclipse.ini is of course very awkward. I see the following solutions: 1) bnd does a GC before we access these files (or after we get the exception). The URLClassLoader keeps the files 'weakly' open. This of course is ugly in our code and it costs time. (Though in a large build this is likely amortized since one GC would work for all.) 2) bnd sets greclipse.nonlocking=true. Although we then need to make sure we are executed before Groovy which might be hard, if at all possible. 3) Groovy adapts to use the NonLockingJarFileClassLoader by default, or provides a preference for this Clearly my rather strong preference is #3 since that follows the Eclipse rules, I expect there are non bnd use cases that also get this error. bnd is just very prone to this problem because we change the Eclipse build path all the time. Would that be possible? > File leak in Eclipse Plugin > --- > > Key: GROOVY-8458 > URL: https://issues.apache.org/jira/browse/GROOVY-8458 > Project: Groovy > Issue Type: Bug >Reporter: Peter Kriens >Priority: Blocker > > The Eclipse Groovy compiler opens JAR files that are on an Eclipse's project > build path. These JAR files are opened by Groovy but never closed. > When a project changes its buildpath, the Groovy compiler keeps a reference > to the old file which makes it impossible to overwrite it on Windows. > This is very visible in bnd(tools) environments because bnd creates an actual > bundle and puts this on the project's build path. Since every change results > in a new bundle, the build path is changed very frequently. However, once the > Groovy compiler has its hands on that JAR, bnd can no longer delete and its > build fails. > When we run an Eclipse workspace with a number of bnd projects we see a large > number of the following file leaks at the end. > Looking at the source code it seems that you're opening a GroovyClassLoader, > to get some resources to find the AST transform services from it, and then > never close it. So the JAR files it accesses are then never closed. Which > kind of is a problem on Windows .. > [https://github.com/groovy/groovy-core/blob/01309f9d4be34ddf93c4a9943b5a97843bff6181/src/main/org/codehaus/groovy/transform/ASTTransformationVisitor.java#L197] > It seems putting this in a try/resource will solve the problem. > Although we did not detect leaks from different places, in our experience, > these patterns tend to happen frequently in a code base so it would be > appreciated to do a check on any classloaders (which are Java resources so > you can get a warning from Eclipse when you forget to close a Closeable > resource) are not closed. > > Let me know if you prefer a pull request on Github. > > > #95 C:\Users\-\com.___\target\com.___.jar by > thread:Worker-11 on Wed Jan 24 10:30:25 CET 2018 at > java.util.zip.ZipFile.(ZipFile.java:156) at > java.util.jar.JarFile.(JarFile.java:166) at > java.util.jar.JarFile.(JarFile.java:103) at > sun.misc.URLClassPath$JarLoader.getJarFile(URLClassPath.java:930) at > sun.misc.URLClassPath$JarLoader.access$800(URLClassPath.java:791) at > sun.misc.URLClassPath$JarLoader$1.run(URLClassPath.java:876) at > sun.misc.URLClassPath$JarLoader$1.run(URLClassPath.java:869) at > java.security.AccessController.doPrivileged(Native Method) at > sun.misc.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:868) at > sun.misc.URLClassPath$JarLoader.(URLClassPath.java:841) at > sun.misc.URLClassPath$3.run(URLClassPath.java:565) at > sun.misc.URLClassPath$3.run(URLClassPath.java:555) at > java.security.AccessController.doPrivileged(Native Method) at > sun.misc.URLClassPath.getLoader(URLClassPath.java:554) at > sun.misc.URLClassPath.getLoader(URLClassPath.java:519) at > sun.misc.URLClassPath.getNextLoader(URLClassPath.java:484) at > sun.misc.URLClassPath.access$100(URLClassPath.java:65) at > sun.misc.URLClassPath$1.next(URLClassPath.java:266) at > sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:277) at > java.net.URLClassLoader$3$1.run(URLClassLoader.java:601) at > java.net.URLClassLoader$3$1.run(URLClassLoader.java:599) at > java.security.AccessController.doPrivileged(Native Method) at > java.net.URLClassLoader$3.next(URLClassLoader.java:598) at > java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:623) at > sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) at > sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) at > sun.misc.Com
