[jira] [Commented] (GROOVY-9776) ClassNotFoundException in test execution with Groovy >3.0.3
[ https://issues.apache.org/jira/browse/GROOVY-9776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214288#comment-17214288 ] rkrisztian commented on GROOVY-9776: In the meantime I've changed my algorithm so much that I am no longer using an abstract class, and the bug went away. Regardless, the mentioned branch is still there, feel free to test. > ClassNotFoundException in test execution with Groovy >3.0.3 > --- > > Key: GROOVY-9776 > URL: https://issues.apache.org/jira/browse/GROOVY-9776 > Project: Groovy > Issue Type: Documentation > Components: bytecode, Compiler >Affects Versions: 3.0.5, 3.0.6 >Reporter: rkrisztian >Priority: Major > > I've got this weird ClassNotFoundException with Groovy 3.0.5 and above when a > test class tries to reuse an abstract class from the main sources: > https://github.com/rkrisztian/search/tree/task/improve_color_highlighting > This branch as you can see from the build log of TravisCI, reproduces the > error: > https://travis-ci.org/github/rkrisztian/search/jobs/734837733 > Which goes away if I downgrade Groovy to 3.0.3. > Could you please help me find out why? > Note: not urgent, it's my hobby project. But I'll keep the branch until the > issue is fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [groovy] paulk-asert commented on pull request #1405: Add a null check so that the proper exception is thrown.
paulk-asert commented on pull request #1405: URL: https://github.com/apache/groovy/pull/1405#issuecomment-708631316 LGTM This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] spmallette opened a new pull request #1405: Add a null check so that the proper exception is thrown.
spmallette opened a new pull request #1405: URL: https://github.com/apache/groovy/pull/1405 This issue is resolved in 3.x and is essentially backported from 47d106cddc069d0f7c9b3e75f1a35aec44685b03 which was part of GROOVY-8279. This issue ends up being a problem for Apache TinkerPop which relies on groovysh fairly heavily. Without this change, a fail within `shell.parse()` within the `try` block leaves the `type` as `null` and then provides that argument to `removeClassCacheEntry()`. At that point no matter what exception `shell.parse()` threw, the `Interpreter.evaluate()` will end up throwing a `NullPointerException` thus masking the error. In our case at TinkerPop, the exception typically masked is a `StackOverflowError` which would be much more useful than the `NullPointerException` as it would point to a common specific problem that we could alert users to more readily. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (GROOVY-9780) stuck waiting for lock with AbstractConcurrentMap$Segment.put
[ https://issues.apache.org/jira/browse/GROOVY-9780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boon updated GROOVY-9780: - Description: A simple getProperty operation resulting in org.codehaus.groovy.util.AbstractConcurrentMap$Segment.getOrPut and finally waiting for a none existing lock for over 10 minutes (stuck thread). See following stuck thread: [STUCK] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=10 tid=0x7fcfea664000 nid=0x1d5c waiting on condition [0x7fcf484a3000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00059e0e4600> (a org.codehaus.groovy.util.ManagedConcurrentMap$Segment) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) at org.codehaus.groovy.util.LockableObject.lock(LockableObject.java:37) at org.codehaus.groovy.util.AbstractConcurrentMapBase$Segment.removeEntry(AbstractConcurrentMapBase.java:174) at org.codehaus.groovy.util.ManagedConcurrentMap$Entry.finalizeReference(ManagedConcurrentMap.java:81) at org.codehaus.groovy.util.ManagedConcurrentMap$EntryWithValue.finalizeReference(ManagedConcurrentMap.java:115) at org.codehaus.groovy.util.ReferenceManager$1.removeStallEntries(ReferenceManager.java:86) at org.codehaus.groovy.util.ReferenceManager$1.afterReferenceCreation(ReferenceManager.java:94) at org.codehaus.groovy.util.ReferenceManager$2.afterReferenceCreation(ReferenceManager.java:111) at org.codehaus.groovy.util.ManagedReference.(ManagedReference.java:36) at org.codehaus.groovy.util.ManagedReference.(ManagedReference.java:40) at org.codehaus.groovy.util.ManagedConcurrentMap$Entry.(ManagedConcurrentMap.java:55) at org.codehaus.groovy.util.ManagedConcurrentMap$EntryWithValue.(ManagedConcurrentMap.java:98) at org.codehaus.groovy.util.ManagedConcurrentMap$Segment.createEntry(ManagedConcurrentMap.java:46) at org.codehaus.groovy.util.AbstractConcurrentMap$Segment.put(AbstractConcurrentMap.java:157) at org.codehaus.groovy.util.AbstractConcurrentMap$Segment.getOrPut(AbstractConcurrentMap.java:100) at org.codehaus.groovy.util.AbstractConcurrentMap.getOrPut(AbstractConcurrentMap.java:38) at org.codehaus.groovy.runtime.metaclass.ThreadManagedMetaBeanProperty$ThreadBoundGetter.invoke(ThreadManagedMetaBeanProperty.java:183) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325) at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1849) at groovy.lang.ExpandoMetaClass.getProperty(ExpandoMetaClass.java:1155) at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3734) at groovy.lang.ExpandoMetaClass.getProperty(ExpandoMetaClass.java:1167) at groovy.lang.GroovyObjectSupport.getProperty(GroovyObjectSupport.java:38) at groovy.lang.Script.getProperty(Script.java:58) at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:50) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:307) was: A get operation resulting in waiting for a none existing lock for over 10 minutes. See following stuck thread: [STUCK] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=10 tid=0x7fcfea664000 nid=0x1d5c waiting on condition [0x7fcf484a3000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00059e0e4600> (a org.codehaus.groovy.util.ManagedConcurrentMap$Segment) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) at org.codehaus.groovy.util.LockableObject.lock(LockableObject.java:37) at org.codehaus.groovy.util.AbstractConcurrentMapBase$Segment.removeEntry(AbstractConcurrentMapBase.java:174) at org.codehaus.groovy.util.ManagedConcurrentMap$Entry.finalizeReference(ManagedConcurrentMap.java:81) at
[jira] [Created] (GROOVY-9780) stuck waiting for lock with AbstractConcurrentMap$Segment.put
Boon created GROOVY-9780: Summary: stuck waiting for lock with AbstractConcurrentMap$Segment.put Key: GROOVY-9780 URL: https://issues.apache.org/jira/browse/GROOVY-9780 Project: Groovy Issue Type: Bug Affects Versions: 2.4.6 Reporter: Boon A get operation resulting in waiting for a none existing lock for over 10 minutes. See following stuck thread: [STUCK] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=10 tid=0x7fcfea664000 nid=0x1d5c waiting on condition [0x7fcf484a3000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00059e0e4600> (a org.codehaus.groovy.util.ManagedConcurrentMap$Segment) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) at org.codehaus.groovy.util.LockableObject.lock(LockableObject.java:37) at org.codehaus.groovy.util.AbstractConcurrentMapBase$Segment.removeEntry(AbstractConcurrentMapBase.java:174) at org.codehaus.groovy.util.ManagedConcurrentMap$Entry.finalizeReference(ManagedConcurrentMap.java:81) at org.codehaus.groovy.util.ManagedConcurrentMap$EntryWithValue.finalizeReference(ManagedConcurrentMap.java:115) at org.codehaus.groovy.util.ReferenceManager$1.removeStallEntries(ReferenceManager.java:86) at org.codehaus.groovy.util.ReferenceManager$1.afterReferenceCreation(ReferenceManager.java:94) at org.codehaus.groovy.util.ReferenceManager$2.afterReferenceCreation(ReferenceManager.java:111) at org.codehaus.groovy.util.ManagedReference.(ManagedReference.java:36) at org.codehaus.groovy.util.ManagedReference.(ManagedReference.java:40) at org.codehaus.groovy.util.ManagedConcurrentMap$Entry.(ManagedConcurrentMap.java:55) at org.codehaus.groovy.util.ManagedConcurrentMap$EntryWithValue.(ManagedConcurrentMap.java:98) at org.codehaus.groovy.util.ManagedConcurrentMap$Segment.createEntry(ManagedConcurrentMap.java:46) at org.codehaus.groovy.util.AbstractConcurrentMap$Segment.put(AbstractConcurrentMap.java:157) at org.codehaus.groovy.util.AbstractConcurrentMap$Segment.getOrPut(AbstractConcurrentMap.java:100) at org.codehaus.groovy.util.AbstractConcurrentMap.getOrPut(AbstractConcurrentMap.java:38) at org.codehaus.groovy.runtime.metaclass.ThreadManagedMetaBeanProperty$ThreadBoundGetter.invoke(ThreadManagedMetaBeanProperty.java:183) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325) at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1849) at groovy.lang.ExpandoMetaClass.getProperty(ExpandoMetaClass.java:1155) at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3734) at groovy.lang.ExpandoMetaClass.getProperty(ExpandoMetaClass.java:1167) at groovy.lang.GroovyObjectSupport.getProperty(GroovyObjectSupport.java:38) at groovy.lang.Script.getProperty(Script.java:58) at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:50) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:307) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9779) Inconsistency with callable properties in static context
[
https://issues.apache.org/jira/browse/GROOVY-9779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213861#comment-17213861
]
Daniil Ovchinnikov commented on GROOVY-9779:
I also believe this change should be discussed in the mailing list first. It's
also a major change which should not occur in the minor version.
https://groovy-lang.org/operators.html#_call_operator shows an example with
{{call}} omitted _on a local variable_. Local variable calls, as well as calls
on something which is not a reference e.g. call on a parenthesised expression,
are compiled as if {{call}} was written explicitly.
{noformat}
foo() -> foo.call() // if `foo` is a variable, this allows to omit `call`
foo() -> foo() // if `foo` is not a variable
(foo) -> foo.call()
foo[bar]() -> foo[bar].call()
{noformat}
See org.codehaus.groovy.classgen.VariableScopeVisitor#visitMethodCallExpression
> Inconsistency with callable properties in static context
>
>
> Key: GROOVY-9779
> URL: https://issues.apache.org/jira/browse/GROOVY-9779
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.6
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:title=playground.groovy}
> class C {
> def call() {
> 42
> }
> }
> class Container {
> static final staticC = new C()
> def instanceC = new C()
> }
> assert Container.staticC() == 42 // works fine
> def container = new Container()
> assert container.staticC() == 42 // MissingMethodException
> assert container.instanceC() == 42 // MissingMethodException
> {code}
> I'd expect the invocations to fail or to work in both static and instance
> contexts.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9779) Inconsistency with callable properties in static context
[
https://issues.apache.org/jira/browse/GROOVY-9779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213852#comment-17213852
]
Daniil Ovchinnikov commented on GROOVY-9779:
After this change the following tests pass:
{code:groovy}
assertScript '''
class C {
def call() { return 42 }
}
class C1 {
def call = new C()
}
class C2 {
def call = new C1()
}
class C3 {
def call = new C2()
}
class D {
final y = new C3()
}
assert new D().y() == 42
'''
{code}
{code:groovy}
assertScript '''
class C {
def call(a) { return 42 }
}
class C1 {
def call = new C()
}
class C2 {
def plus = new C1()
}
assert new C2() + 1 == 42
'''
{code}
> Inconsistency with callable properties in static context
>
>
> Key: GROOVY-9779
> URL: https://issues.apache.org/jira/browse/GROOVY-9779
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.6
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:title=playground.groovy}
> class C {
> def call() {
> 42
> }
> }
> class Container {
> static final staticC = new C()
> def instanceC = new C()
> }
> assert Container.staticC() == 42 // works fine
> def container = new Container()
> assert container.staticC() == 42 // MissingMethodException
> assert container.instanceC() == 42 // MissingMethodException
> {code}
> I'd expect the invocations to fail or to work in both static and instance
> contexts.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] paulk-asert opened a new pull request #1404: GROOVY-7494: ArrayStoreException assigning GStringImpl to String[] wh…
paulk-asert opened a new pull request #1404: URL: https://github.com/apache/groovy/pull/1404 …en using Indy This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
