Groovy Console wont start

[Mart]

As anew green user can anyone help me getting the Groovy Console  2.4.6 to
fire up.

I have very little knowledge of Java so Im look for detailed help.

I have looked at the startGroovy.bat placing pauses in the code and found
where it fails but I don’t have the knowledge to go further.

There is a problem somewhere here, the paths exist

"C:\Java\jdk\bin\java.exe" 
"-Xmx128m" 
-Dprogram.name="" 
-Dgroovy.home="C:\Program Files (x86)\Groovy\Groovy-2.4.6" 
-Dtools.jar="C:\Java\jdk\lib\tools.jar" 
-Dgroovy.starter.conf="C:\Program Files
(x86)\Groovy\Groovy-2.4.6\conf\groovy-starter.conf" 
-Dscript.name=""  
-classpath "C:\Program Files
(x86)\Groovy\Groovy-2.4.6\lib\groovy-2.4.6.jar" 
org.codehaus.groovy.tools.GroovyStarter 
--main  
--conf pause

This is the Java error below at the Bottom

Press any key to continue . . .
at have_JAVA_HOME
Press any key to continue . . .
at valid_JAVA_HOME_DIR
Press any key to continue . . .
at valid_JAVA_HOME
Press any key to continue . . .
at check_GROOVY_HOME
Press any key to continue . . .
at execute
Press any key to continue . . .
at after_cp
Press any key to continue . . .
groovy_opts="-Xmx128m" -Dprogram.name="" -Dgroovy.home="C:\Program Files
(x86)\G
roovy\Groovy-2.4.6" -Dtools.jar="C:\Java\jdk\lib\tools.jar"
-Dgroovy.starter.con
f="C:\Program Files (x86)\Groovy\Groovy-2.4.6\conf\groovy-starter.conf"
-Dscript
.name=""
Press any key to continue . . .
"C:\Java\jdk\bin\java.exe" "-Xmx128m" -Dprogram.name=""
-Dgroovy.home="C:\Progra
m Files (x86)\Groovy\Groovy-2.4.6" -Dtools.jar="C:\Java\jdk\lib\tools.jar"
-Dgro
ovy.starter.conf="C:\Program Files
(x86)\Groovy\Groovy-2.4.6\conf\groovy-starter
.conf" -Dscript.name=""  -classpath "C:\Program Files
(x86)\Groovy\Groovy-2.4.6\
lib\groovy-2.4.6.jar" org.codehaus.groovy.tools.GroovyStarter --main  --conf
pau
se
java.lang.ClassNotFoundException: --conf
at
org.codehaus.groovy.tools.RootLoader.findClass(RootLoader.java:179)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at
org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:151)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at
org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java
:99)
at
org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:131)
Press any key to continue . . .







--
View this message in context: 
http://groovy.329449.n5.nabble.com/Groovy-Console-wont-start-tp5731981.html
Sent from the Groovy Users mailing list archive at Nabble.com.

RE: search for particular text in a multi-line string

[Winnebeck, Jason]

Contains works, but depending on your situation you might need to normalize 
data. If you don't know where your line breaks are, for example if you want to 
find "the cow jumped over the moon" but the string is "I read a book. It is 
called the Cow\nJumped Over the Moon", in this case you need to normalize the 
input. You can normalize any sequence of whitespace (including newlines) to a 
single space and do a case insensitive comparison (or convert everything to 
lower case).

Jason

From: Deng, Lea [mailto:lea.d...@ccc.govt.nz]
Sent: Wednesday, March 16, 2016 12:29 AM
To: 'users@groovy.apache.org' 
Subject: search for particular text in a multi-line string

I'd like to have your suggestions on searching for particular text in a 
multi-line string.

I found the contains() method does not work:
boolean isContain = multi_line_String.contains(expectedText)

Do I have to break down my multi line string into single lines for the search? 
I think that may slow down the search.

Or is there an object I could use to declare the multi line, instead of using 
String?

many thanks,
Kind Regards
Lea Deng

Creating connections to make IT easier for everyone

Lead Test Analyst
IT Regulatory Services Team
Christchurch City Council
New Zealand
DDI: +64 (3) 941 88 55
Extn: 8855
lea.d...@ccc.govt.nz


**
This electronic email and any files transmitted with it are intended
solely for the use of the individual or entity to whom they are addressed.

The views expressed in this message are those of the individual sender
and may not necessarily reflect the views of the Christchurch City Council.

If you are not the correct recipient of this email please advise the
sender and delete.

Christchurch City Council
http://www.ccc.govt.nz
**

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

Re: Expando as a Trait?

[Cédric Champeau]

I think what you are suggesting is close to this example in the docs:
http://groovy-lang.org/objectorientation.html#_dynamic_methods_in_a_trait

Am I right?

2016-03-18 16:51 GMT+01:00 Gerald Wiltse :

> Expando is a pretty cool object. And if we extend it, we get it's really
> nice "behavior". Unfortunately, as extending = inheritance, thus extending
> expando precludes us from extending our true parent classes. This is why
> implementing interfaces and traits is often a better choice than
> inheriting, especially when one just wants to compose behaviors such as
> those offered by expando.
>
> Which leads me to ask the question: is it crazy to suggest that the body
> of Expando would actually make a good Trait?   Has this been discussed
> before?
>
> I'm novice so there could be obvious reasons not to do this which I'm not
> aware of.
>
>
> Gerald R. Wiltse
> jerrywil...@gmail.com
>
>

Re: Very Odd/Random JVM Slowdown With Indy

[David Clark]

I believe I have a simple application which shows the problem. You can 
find it here:


https://github.com/dwclark/deopt-storm

The README should cover how to use it. The original application involved 
a dynamic state machine. I have tried to preserve the basics of how the 
program would execute while removing the application specific details. 
Please let me know if there is something I can do to improve this or if 
you have any questions.


Thanks,

David

On 03/18/2016 07:26 AM, Jochen Theodorou wrote:



On 16.03.2016 20:31, David Clark wrote:

If I can think of a way to reproduce the problem with a small script or
application I will definitely post it to the list. I really have no idea
what would cause this problem. If you have any suggestions about what
types of application behavior would tend to lead to this issue I will
give them a try.

Thank for the link to the JDK bug, that does seem to be what we are 
seeing.


If it is not that bug, then it is most probably... well it is the most 
probable reason anyway... our non-existing ability to handle multiple 
targets for the method call in the callsite. It is non-existing, 
because we don't do it for the non-indy case, and while this can 
increase Groovy's performance quite a bit, it is additional complexity 
to deal with and so I was waiting for a real life use case And it 
might be, that your case is exactly what I was looking for.


bye Jochen

RE: Groovy Console wont start

[Winnebeck, Jason]

Are you calling groovyStart directly? That script takes a built program as a 
parameter (like one you build). If you want to run Groovy Console that comes 
with Groovy, you need to run groovysh.bat (for command line version) or 
groovyConsole.bat (for GUI version).

Jason Winnebeck

-Original Message-
From: Mart [mailto:m.a...@herts.ac.uk] 
Sent: Friday, March 18, 2016 6:51 AM
To: us...@groovy.incubator.apache.org
Subject: Groovy Console wont start

As anew green user can anyone help me getting the Groovy Console  2.4.6 to
fire up.

I have very little knowledge of Java so Im look for detailed help.

I have looked at the startGroovy.bat placing pauses in the code and found
where it fails but I don’t have the knowledge to go further.

There is a problem somewhere here, the paths exist

"C:\Java\jdk\bin\java.exe" 
"-Xmx128m" 
-Dprogram.name="" 
-Dgroovy.home="C:\Program Files (x86)\Groovy\Groovy-2.4.6" 
-Dtools.jar="C:\Java\jdk\lib\tools.jar" 
-Dgroovy.starter.conf="C:\Program Files
(x86)\Groovy\Groovy-2.4.6\conf\groovy-starter.conf" 
-Dscript.name=""  
-classpath "C:\Program Files
(x86)\Groovy\Groovy-2.4.6\lib\groovy-2.4.6.jar" 
org.codehaus.groovy.tools.GroovyStarter 
--main  
--conf pause

This is the Java error below at the Bottom

Press any key to continue . . .
at have_JAVA_HOME
Press any key to continue . . .
at valid_JAVA_HOME_DIR
Press any key to continue . . .
at valid_JAVA_HOME
Press any key to continue . . .
at check_GROOVY_HOME
Press any key to continue . . .
at execute
Press any key to continue . . .
at after_cp
Press any key to continue . . .
groovy_opts="-Xmx128m" -Dprogram.name="" -Dgroovy.home="C:\Program Files
(x86)\G
roovy\Groovy-2.4.6" -Dtools.jar="C:\Java\jdk\lib\tools.jar"
-Dgroovy.starter.con
f="C:\Program Files (x86)\Groovy\Groovy-2.4.6\conf\groovy-starter.conf"
-Dscript
.name=""
Press any key to continue . . .
"C:\Java\jdk\bin\java.exe" "-Xmx128m" -Dprogram.name=""
-Dgroovy.home="C:\Progra
m Files (x86)\Groovy\Groovy-2.4.6" -Dtools.jar="C:\Java\jdk\lib\tools.jar"
-Dgro
ovy.starter.conf="C:\Program Files
(x86)\Groovy\Groovy-2.4.6\conf\groovy-starter
.conf" -Dscript.name=""  -classpath "C:\Program Files
(x86)\Groovy\Groovy-2.4.6\
lib\groovy-2.4.6.jar" org.codehaus.groovy.tools.GroovyStarter --main  --conf
pau
se
java.lang.ClassNotFoundException: --conf
at
org.codehaus.groovy.tools.RootLoader.findClass(RootLoader.java:179)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at
org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:151)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at
org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java
:99)
at
org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:131)
Press any key to continue . . .







--
View this message in context: 
http://groovy.329449.n5.nabble.com/Groovy-Console-wont-start-tp5731981.html
Sent from the Groovy Users mailing list archive at Nabble.com.

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

Re: Groovy Console wont start

[Keegan Witt]

Curious...it worked on both my Windows 10 home machine and my Windows 7
work machine.  What's you're JAVA_HOME environment variable set to?  Is it
a JDK?

I'm thinking maybe your JAVA_HOME isn't set, and you can't pass where Java
is as an arg because groovy.c

doesn't
take any args for groovyConsole.  I've been meaning to update the native
binaries, we've been in need of some changes for a while.  But first I
wanted to move it over to GNU Make so we can actually reliably build these
things (or change to Launch4j -- I'm not sure I get the original author's
objections to that idea).  I just haven't gotten it done yet...

In the mean time, I'd look at setting your JAVA_HOME, or j.ust keep using
the batch file.

-Keegan


On Fri, Mar 18, 2016 at 9:51 AM, Winnebeck, Jason <
jason.winneb...@windstream.com> wrote:

> I understand you are green that's fine.
>
> I don't use the installer, so I didn't have groovyConsole.exe, but I did
> try the installer. My account is not an admin so I installed outside of
> Program Files, and for whatever reason I got no start menu entries, but all
> of the files did copy down. If I run groovyConsole.exe directly it did
> work. I'm not sure how groovyConsole.exe differs from the bat in terms of
> launching Groovy, or how the exe file is made.
>
> Jason
>
> -Original Message-
> From: Mart [mailto:m.a...@herts.ac.uk]
> Sent: Friday, March 18, 2016 8:47 AM
> To: us...@groovy.incubator.apache.org
> Subject: RE: Groovy Console wont start
>
> Thanks Jason
>
> Told you I was green
>
> The windows insall added  Start GroovyConsole to the start menu the
> properties being "C:\Program Files
> (x86)\Groovy\Groovy-2.4.6\bin\groovyConsole.exe".
>
> However running the GroovyConsole.bat does indeed start up the console. At
> least I know my Java_Home is ok!
>
> Any idea why groovyConsole.exe doesnt run?
>
> Mart
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Groovy-Console-wont-start-tp5731981p5731991.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>
> --
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>


On Fri, Mar 18, 2016 at 9:51 AM, Winnebeck, Jason <
jason.winneb...@windstream.com> wrote:

> I understand you are green that's fine.
>
> I don't use the installer, so I didn't have groovyConsole.exe, but I did
> try the installer. My account is not an admin so I installed outside of
> Program Files, and for whatever reason I got no start menu entries, but all
> of the files did copy down. If I run groovyConsole.exe directly it did
> work. I'm not sure how groovyConsole.exe differs from the bat in terms of
> launching Groovy, or how the exe file is made.
>
> Jason
>
> -Original Message-
> From: Mart [mailto:m.a...@herts.ac.uk]
> Sent: Friday, March 18, 2016 8:47 AM
> To: us...@groovy.incubator.apache.org
> Subject: RE: Groovy Console wont start
>
> Thanks Jason
>
> Told you I was green
>
> The windows insall added  Start GroovyConsole to the start menu the
> properties being "C:\Program Files
> (x86)\Groovy\Groovy-2.4.6\bin\groovyConsole.exe".
>
> However running the GroovyConsole.bat does indeed start up the console. At
> least I know my Java_Home is ok!
>
> Any idea why groovyConsole.exe doesnt run?
>
> Mart
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Groovy-Console-wont-start-tp5731981p5731991.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>
> --
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>

Re: Very Odd/Random JVM Slowdown With Indy

[David Clark]

If I can think of a way to reproduce the problem with a small script or
application I will definitely post it to the list. I really have no idea
what would cause this problem. If you have any suggestions about what types
of application behavior would tend to lead to this issue I will give them a
try.

Thank for the link to the JDK bug, that does seem to be what we are seeing.

On Wed, Mar 16, 2016 at 7:51 AM, Jochen Theodorou  wrote:

> Ideal would be to have a small application showing the problem. With an
> actual test we could analyze the problem much better. It is possible the
> issue is related to https://bugs.openjdk.java.net/browse/JDK-8151981, but
> there are also possible bugs in our invokedynamic usage. What I could
> gather so far is that
>
> java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native
> Method)
>
> will lock the compiler and stop all threads. And even if jvisualvm shows
> no locking, there might be still many many threads trying to recompile a
> callsite at the same time and wait for a lock to do so.
>
> bye Jochen
>
> On 14.03.2016 22:31, David Clark wrote:
>
>> I've been chasing a slowdown in our application for a couple of months
>> now. I have what I believe is a solution (no slowdown for 4 days now).
>> But I'm having difficulty understanding why the solution works.
>>
>> Symptoms:
>>
>> At random intervals and a random times our web servers will go from
>> serving responses in the 300 ms range to taking 30 seconds or more.
>> Sometimes the servers will recover, sometimes they require a restart of
>> the webserver (spring boot/tomcat). When the applications slow down we
>> always see the tomcat thread pool hit the maximum size. Every single
>> thread in the thread pool is in the RUNNABLE state but appears to be
>> making no progress. Successive thread dumps show that the stacks are
>> changing, but VERY slowly. The top of the stack is always this method:
>>
>> at java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native
>> Method).
>>
>> The other common condition is that whatever application code is on the
>> stack is always dynamically compiled. Code that is @CompileStatic is
>> NEVER on the stack when we see these slowdowns.
>>
>> The thread dumps showed that the application code is never waiting on
>> locks, socket reads, db connections, etc.
>>
>> Solution:
>>
>> The solution to the problem was to disable Indy compilation and return
>> to non-Indy compilation. However, I don't think Indy is the problem
>> here. I noticed that our Spring Boot executable jar contained BOTH
>> groovy-all-2.4.5.jar AND groovy-all-indy-2.4.5.jar. Someone forgot to
>> exclude the non-indy jars.
>>
>> My theory:
>>
>> Having both indy and non-indy jars on the classpath is confusing the JIT
>> compiler. Code will be continuously JIT-ed as different methods fight
>> over which class files to JIT, those loaded from the groovy-all jar or
>> those loaded from the groovy-all-indy jar. If this is true then the
>> compiler threads will be continuously running and applying native locks
>> which are invisible to tools like VisualVM. The result would be random
>> slowdowns because only certain combinations of code paths would result
>> in slowdowns. It would also cause application code to go very slowly as
>> the JIT compiler continuously re-compiles code over and over again.
>> Application code would be stuck mostly waiting for JIT operations to
>> complete as invalidated code is continuously removed and replaced.
>>
>> For now I will be leaving Indy disabled until we can do more accurate
>> load testing in non production environments.
>>
>> My Question:
>>
>> Is this theory possible? Am I going in a direction that is possible or
>> likely?
>>
>

RE: Groovy Console wont start

[Winnebeck, Jason]

I understand you are green that's fine.

I don't use the installer, so I didn't have groovyConsole.exe, but I did try 
the installer. My account is not an admin so I installed outside of Program 
Files, and for whatever reason I got no start menu entries, but all of the 
files did copy down. If I run groovyConsole.exe directly it did work. I'm not 
sure how groovyConsole.exe differs from the bat in terms of launching Groovy, 
or how the exe file is made.

Jason

-Original Message-
From: Mart [mailto:m.a...@herts.ac.uk] 
Sent: Friday, March 18, 2016 8:47 AM
To: us...@groovy.incubator.apache.org
Subject: RE: Groovy Console wont start

Thanks Jason

Told you I was green

The windows insall added  Start GroovyConsole to the start menu the properties 
being "C:\Program Files (x86)\Groovy\Groovy-2.4.6\bin\groovyConsole.exe".

However running the GroovyConsole.bat does indeed start up the console. At 
least I know my Java_Home is ok!

Any idea why groovyConsole.exe doesnt run?

Mart



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Groovy-Console-wont-start-tp5731981p5731991.html
Sent from the Groovy Users mailing list archive at Nabble.com.

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Groovy Console wont start

[Mart]

Thanks Jason

Told you I was green

The windows insall added  Start GroovyConsole to the start menu the
properties being "C:\Program Files
(x86)\Groovy\Groovy-2.4.6\bin\groovyConsole.exe".

However running the GroovyConsole.bat does indeed start up the console. At
least I know my Java_Home is ok!

Any idea why groovyConsole.exe doesnt run?

Mart



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Groovy-Console-wont-start-tp5731981p5731991.html
Sent from the Groovy Users mailing list archive at Nabble.com.

Re: Very Odd/Random JVM Slowdown With Indy

[Jochen Theodorou]

Ideal would be to have a small application showing the problem. With an 
actual test we could analyze the problem much better. It is possible the 
issue is related to https://bugs.openjdk.java.net/browse/JDK-8151981, 
but there are also possible bugs in our invokedynamic usage. What I 
could gather so far is that


java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native  Method)

will lock the compiler and stop all threads. And even if jvisualvm shows 
no locking, there might be still many many threads trying to recompile a 
callsite at the same time and wait for a lock to do so.


bye Jochen

On 14.03.2016 22:31, David Clark wrote:

I've been chasing a slowdown in our application for a couple of months
now. I have what I believe is a solution (no slowdown for 4 days now).
But I'm having difficulty understanding why the solution works.

Symptoms:

At random intervals and a random times our web servers will go from
serving responses in the 300 ms range to taking 30 seconds or more.
Sometimes the servers will recover, sometimes they require a restart of
the webserver (spring boot/tomcat). When the applications slow down we
always see the tomcat thread pool hit the maximum size. Every single
thread in the thread pool is in the RUNNABLE state but appears to be
making no progress. Successive thread dumps show that the stacks are
changing, but VERY slowly. The top of the stack is always this method:

at java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native
Method).

The other common condition is that whatever application code is on the
stack is always dynamically compiled. Code that is @CompileStatic is
NEVER on the stack when we see these slowdowns.

The thread dumps showed that the application code is never waiting on
locks, socket reads, db connections, etc.

Solution:

The solution to the problem was to disable Indy compilation and return
to non-Indy compilation. However, I don't think Indy is the problem
here. I noticed that our Spring Boot executable jar contained BOTH
groovy-all-2.4.5.jar AND groovy-all-indy-2.4.5.jar. Someone forgot to
exclude the non-indy jars.

My theory:

Having both indy and non-indy jars on the classpath is confusing the JIT
compiler. Code will be continuously JIT-ed as different methods fight
over which class files to JIT, those loaded from the groovy-all jar or
those loaded from the groovy-all-indy jar. If this is true then the
compiler threads will be continuously running and applying native locks
which are invisible to tools like VisualVM. The result would be random
slowdowns because only certain combinations of code paths would result
in slowdowns. It would also cause application code to go very slowly as
the JIT compiler continuously re-compiles code over and over again.
Application code would be stuck mostly waiting for JIT operations to
complete as invalidated code is continuously removed and replaced.

For now I will be leaving Indy disabled until we can do more accurate
load testing in non production environments.

My Question:

Is this theory possible? Am I going in a direction that is possible or
likely?

Re: Very Odd/Random JVM Slowdown With Indy

[Jochen Theodorou]

On 15.03.2016 17:01, David Clark wrote:


if it is in native code, it might not be showing properly actually


We don't have any JNI code in our code base. Is there something else
native I could/should be looking at?


you are not using JNI, yes, but the method you mentioned is implemented 
in native code of the JVM itself. And such internal information tends 
not to be shown in tools inspecting the Application


bye Jochen

Re: Expando as a Trait?

[Gerald Wiltse]

Yes indeed.   Just as Tim posted here, the basics of this functionality can
be manually.

http://stackoverflow.com/questions/7078855/groovy-dynamically-add-properties-to-groovy-classes-from-inside-class-methods

However, his comment points out the fact that groovy expando is a nicely
polished and mature implementation of a dynamic object.

https://github.com/apache/groovy/blob/master/src/main/groovy/util/Expando.java

It just seems undesirable to manually add this boilerplate code into every
object I create in the future (where i want dynamic), when traits are so
nice in groovy.


Gerald R. Wiltse
jerrywil...@gmail.com


On Fri, Mar 18, 2016 at 12:03 PM, Cédric Champeau  wrote:

> I think what you are suggesting is close to this example in the docs:
> http://groovy-lang.org/objectorientation.html#_dynamic_methods_in_a_trait
>
> Am I right?
>
> 2016-03-18 16:51 GMT+01:00 Gerald Wiltse :
>
>> Expando is a pretty cool object. And if we extend it, we get it's really
>> nice "behavior". Unfortunately, as extending = inheritance, thus extending
>> expando precludes us from extending our true parent classes. This is why
>> implementing interfaces and traits is often a better choice than
>> inheriting, especially when one just wants to compose behaviors such as
>> those offered by expando.
>>
>> Which leads me to ask the question: is it crazy to suggest that the body
>> of Expando would actually make a good Trait?   Has this been discussed
>> before?
>>
>> I'm novice so there could be obvious reasons not to do this which I'm not
>> aware of.
>>
>>
>> Gerald R. Wiltse
>> jerrywil...@gmail.com
>>
>>
>

Expando as a Trait?

[Gerald Wiltse]

Expando is a pretty cool object. And if we extend it, we get it's really
nice "behavior". Unfortunately, as extending = inheritance, thus extending
expando precludes us from extending our true parent classes. This is why
implementing interfaces and traits is often a better choice than
inheriting, especially when one just wants to compose behaviors such as
those offered by expando.

Which leads me to ask the question: is it crazy to suggest that the body of
Expando would actually make a good Trait?   Has this been discussed before?

I'm novice so there could be obvious reasons not to do this which I'm not
aware of.


Gerald R. Wiltse
jerrywil...@gmail.com

Re: Very Odd/Random JVM Slowdown With Indy

[Jochen Theodorou]

On 16.03.2016 20:31, David Clark wrote:

If I can think of a way to reproduce the problem with a small script or
application I will definitely post it to the list. I really have no idea
what would cause this problem. If you have any suggestions about what
types of application behavior would tend to lead to this issue I will
give them a try.

Thank for the link to the JDK bug, that does seem to be what we are seeing.


If it is not that bug, then it is most probably... well it is the most 
probable reason anyway... our non-existing ability to handle multiple 
targets for the method call in the callsite. It is non-existing, because 
we don't do it for the non-indy case, and while this can increase 
Groovy's performance quite a bit, it is additional complexity to deal 
with and so I was waiting for a real life use case And it might be, 
that your case is exactly what I was looking for.


bye Jochen