[jira] [Updated] (GROOVY-7843) Trait method calling closure cannot be inherited while using CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud CAVAILHEZ updated GROOVY-7843:
-
Description:
A trait extending another and calling itself more than 3 times:
{code}@CompileStatic
trait UpperTrait {
void call(Closure body){
body()
}
}{code}
{code}@CompileStatic
trait LowerTrait extends UpperTrait {
void threeCalls() {
call {
call {
call {
}
}
}
}
}{code}
Will generate a `ClassCastException` when called:
{code}class ImplementsTrait implements LowerTrait {
}
new ImplementsTrait().threeCalls()
{code}
raises:
{code}Caught: java.lang.ClassCastException:
LowerTrait$Trait$Helper$_threeCalls_closure1 cannot be cast to UpperTrait
java.lang.ClassCastException: LowerTrait$Trait$Helper$_threeCalls_closure1
cannot be cast to UpperTrait
at
LowerTrait$Trait$Helper$_threeCalls_closure1$_closure2.doCall(LowerTrait.groovy:9)
etc..{code}
was:
A trait extending another and calling itself more than 3 times:
```@CompileStatic
trait UpperTrait {
void call(Closure body){
body()
}
}```
```@CompileStatic
trait LowerTrait extends UpperTrait {
void threeCalls() {
call {
call {
call {
}
}
}
}
}```
Will generate a `ClassCastException` when called:
```class ImplementsTrait implements LowerTrait {
}
new ImplementsTrait().threeCalls()
```
raises:
```Caught: java.lang.ClassCastException:
LowerTrait$Trait$Helper$_threeCalls_closure1 cannot be cast to UpperTrait
java.lang.ClassCastException: LowerTrait$Trait$Helper$_threeCalls_closure1
cannot be cast to UpperTrait
at
LowerTrait$Trait$Helper$_threeCalls_closure1$_closure2.doCall(LowerTrait.groovy:9)
etc..```
> Trait method calling closure cannot be inherited while using CompileStatic
> --
>
> Key: GROOVY-7843
> URL: https://issues.apache.org/jira/browse/GROOVY-7843
> Project: Groovy
> Issue Type: Bug
>Reporter: Arnaud CAVAILHEZ
>Priority: Minor
>
> A trait extending another and calling itself more than 3 times:
> {code}@CompileStatic
> trait UpperTrait {
> void call(Closure body){
> body()
> }
> }{code}
> {code}@CompileStatic
> trait LowerTrait extends UpperTrait {
> void threeCalls() {
> call {
> call {
> call {
> }
> }
> }
> }
> }{code}
> Will generate a `ClassCastException` when called:
> {code}class ImplementsTrait implements LowerTrait {
> }
> new ImplementsTrait().threeCalls()
> {code}
> raises:
> {code}Caught: java.lang.ClassCastException:
> LowerTrait$Trait$Helper$_threeCalls_closure1 cannot be cast to UpperTrait
> java.lang.ClassCastException: LowerTrait$Trait$Helper$_threeCalls_closure1
> cannot be cast to UpperTrait
> at
> LowerTrait$Trait$Helper$_threeCalls_closure1$_closure2.doCall(LowerTrait.groovy:9)
> etc..{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GROOVY-7843) Trait method calling closure cannot be inherited while using CompileStatic
Arnaud CAVAILHEZ created GROOVY-7843:
Summary: Trait method calling closure cannot be inherited while
using CompileStatic
Key: GROOVY-7843
URL: https://issues.apache.org/jira/browse/GROOVY-7843
Project: Groovy
Issue Type: Bug
Reporter: Arnaud CAVAILHEZ
Priority: Minor
A trait extending another and calling itself more than 3 times:
```@CompileStatic
trait UpperTrait {
void call(Closure body){
body()
}
}```
```@CompileStatic
trait LowerTrait extends UpperTrait {
void threeCalls() {
call {
call {
call {
}
}
}
}
}```
Will generate a `ClassCastException` when called:
```class ImplementsTrait implements LowerTrait {
}
new ImplementsTrait().threeCalls()
```
raises:
```Caught: java.lang.ClassCastException:
LowerTrait$Trait$Helper$_threeCalls_closure1 cannot be cast to UpperTrait
java.lang.ClassCastException: LowerTrait$Trait$Helper$_threeCalls_closure1
cannot be cast to UpperTrait
at
LowerTrait$Trait$Helper$_threeCalls_closure1$_closure2.doCall(LowerTrait.groovy:9)
etc..```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7788) Groovy does not run on 64 bit Windows 7
[ https://issues.apache.org/jira/browse/GROOVY-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295678#comment-15295678 ] Keegan Witt commented on GROOVY-7788: - The installer runs a jar that detects the version of Java by checking in this order # JAVA_HOME # Registry key SOFTWARE\JavaSoft\Java Runtime Environment # Assume 32 bit Then it installs the Groovy binaries that match. Obviously, it would be a problem if Java wasn't installed or if a different architecture of Java was in JAVA_HOME when the installer was run (as you have noticed). I'll add a message box to the installer so it's clear what version it's installing. Longer term, I'm thinking I'll re-implement the binaries with Launch4J instead of C and that should eliminate the need for the installer to do any Java detection. I just haven't had time to get to it yet. > Groovy does not run on 64 bit Windows 7 > --- > > Key: GROOVY-7788 > URL: https://issues.apache.org/jira/browse/GROOVY-7788 > Project: Groovy > Issue Type: Bug > Components: windows installer >Affects Versions: 2.4.6 > Environment: Microsoft Windows 7 Enterprise 64 bit > java version 1.8.0_65 > Java(TM) SE Runtime Environment (build 1.8.0_65-b17) > Java HotSpot(TM) 64-Bit server VM (build 25.65-b01, mixed mode) >Reporter: Shawn Cole >Priority: Minor > Labels: windows > > When I try to execute groovy I get: > error: dynamic library C:\Program > Files\Java\jdk1.8.0_65\jre\bin\server\jvm.dll exists but could not be loaded! > This may be caused e.g. by trying to use a 32-bit executable to load a 64-bit > jvm (or vice versa) > error (win code 193): (null) > error: could not find client or server jvm under C:\Program > Files\Java\jdk1.8.0_65 > please check that it is a valid jdk / jre containing the desired type of jvm > I have a 64 bit machine and 64 bit java, with my JAVA_HOME pointing to > C:\Program Files\Java\jdk1.8.0_65 > The problem seems to be when I ran the windows installer, it installed a 32 > bit version of groovy on my machine that is not able to run on the 64 bit JVM. > Is there any workarounds to this? and please don't say install the 32 bit > version of java, because if that is the only solution i'd rather just not > learn this language. I can't seem to find any binaries specific to 64 bit or > 32. > Also note worthy: I can launch groovy shell and groovy console with their > corresponding batch files in the bin directory successfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7788) Groovy does not run on 64 bit Windows 7
[ https://issues.apache.org/jira/browse/GROOVY-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295535#comment-15295535 ] Pascal Schumacher commented on GROOVY-7788: --- [~keegan] Maybe you can take a look at this? > Groovy does not run on 64 bit Windows 7 > --- > > Key: GROOVY-7788 > URL: https://issues.apache.org/jira/browse/GROOVY-7788 > Project: Groovy > Issue Type: Bug > Components: windows installer >Affects Versions: 2.4.6 > Environment: Microsoft Windows 7 Enterprise 64 bit > java version 1.8.0_65 > Java(TM) SE Runtime Environment (build 1.8.0_65-b17) > Java HotSpot(TM) 64-Bit server VM (build 25.65-b01, mixed mode) >Reporter: Shawn Cole >Priority: Minor > Labels: windows > > When I try to execute groovy I get: > error: dynamic library C:\Program > Files\Java\jdk1.8.0_65\jre\bin\server\jvm.dll exists but could not be loaded! > This may be caused e.g. by trying to use a 32-bit executable to load a 64-bit > jvm (or vice versa) > error (win code 193): (null) > error: could not find client or server jvm under C:\Program > Files\Java\jdk1.8.0_65 > please check that it is a valid jdk / jre containing the desired type of jvm > I have a 64 bit machine and 64 bit java, with my JAVA_HOME pointing to > C:\Program Files\Java\jdk1.8.0_65 > The problem seems to be when I ran the windows installer, it installed a 32 > bit version of groovy on my machine that is not able to run on the 64 bit JVM. > Is there any workarounds to this? and please don't say install the 32 bit > version of java, because if that is the only solution i'd rather just not > learn this language. I can't seem to find any binaries specific to 64 bit or > 32. > Also note worthy: I can launch groovy shell and groovy console with their > corresponding batch files in the bin directory successfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7824) Windows Installer sets Search Path Incorrectly
[ https://issues.apache.org/jira/browse/GROOVY-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295534#comment-15295534 ] Pascal Schumacher commented on GROOVY-7824: --- [~keegan] Maybe you can take a look at this? > Windows Installer sets Search Path Incorrectly > -- > > Key: GROOVY-7824 > URL: https://issues.apache.org/jira/browse/GROOVY-7824 > Project: Groovy > Issue Type: Bug > Components: windows installer >Affects Versions: 2.4.6 > Environment: Windows 10 Pro x64 >Reporter: Dennis E. Hamilton > > When addition to the User environment is selected during the Windows install > (rather than the pre-checked System case), the GROOVY_HOME variable is set. > However, the PATH addition is %GROOVY_HOME%\bin and that does not work with > either cmd.exe or PowerShell. Batch variables are not recognized and > processed in the PATH list. > The following abbreviated cmd.exe capture demonstrates what happens: > D:\OneDrive\VSProjects>groovy -v > 'groovy' is not recognized as an internal or external command, > operable program or batch file. > D:\OneDrive\VSProjects>set > [ ... abbreviated ... ] > GROOVY_HOME=C:\PROGRA~2\Groovy\GROOVY~1.6 > HOMEDRIVE=C: > HOMEPATH=\Users\orcmi_000 > LOCALAPPDATA=C:\Users\orcmi_000\AppData\Local > LOGONSERVER=\\MicrosoftAccount > MYNODE=C:\Program Files\nodejs\ > NUMBER_OF_PROCESSORS=8 > OS=Windows_NT > Path=C:\Users\orcmi_000\AppData\Roaming\npm; > [ ... much abbreviation ... ] > D:\crea\Microsoft VS Code\bin;%GROOVY_HOME%\bin > [ THE USE OF %GROOVY_HOME% here is not going to work ] > > PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.groovy;.gy > PROCESSOR_ARCHITECTURE=AMD64 > PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 58 Stepping 9, GenuineIntel > PROCESSOR_LEVEL=6 > PROCESSOR_REVISION=3a09 > ProgramData=C:\ProgramData > ProgramFiles=C:\Program Files > ProgramFiles(x86)=C:\Program Files (x86) > ProgramW6432=C:\Program Files > [ ... abbreviated ...] > D:\OneDrive\VSProjects>%GROOVY_HOME%\bin\groovy -v > Groovy Version: 2.4.6 JVM: 1.7.0_55 Vendor: Oracle Corporation OS: Windows 8 > D:\OneDrive\VSProjects> > *** Neither CMD.EXE nor PowerShell will process batch variables in the > *** PATH list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GROOVY-7835) Groovysh does not support static import aliasing
[ https://issues.apache.org/jira/browse/GROOVY-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated GROOVY-7835: -- Description: Groovysh does not as yet seem to support static import aliasing, e.g.: ``` groovy:000> import static Calendar.getInstance as now ===> static Calendar.getInstance as now groovy:000> now.class Unknown property: now groovy:000> ``` See http://docs.groovy-lang.org/latest/html/documentation/index.html#_static_import_aliasing was: Groovysh does not as yet seem to support import aliasing, e.g.: ``` groovy:000> import static Calendar.getInstance as now ===> static Calendar.getInstance as now groovy:000> now.class Unknown property: now groovy:000> ``` See http://docs.groovy-lang.org/latest/html/documentation/index.html#_static_import_aliasing Summary: Groovysh does not support static import aliasing (was: Groovysh does not support import aliasing) update the title and description according to Jakes comment > Groovysh does not support static import aliasing > > > Key: GROOVY-7835 > URL: https://issues.apache.org/jira/browse/GROOVY-7835 > Project: Groovy > Issue Type: Improvement > Components: Groovysh >Affects Versions: 2.4.6 >Reporter: Jake Gage >Priority: Minor > > Groovysh does not as yet seem to support static import aliasing, e.g.: > ``` > groovy:000> import static Calendar.getInstance as now > ===> static Calendar.getInstance as now > groovy:000> now.class > Unknown property: now > groovy:000> > ``` > See > http://docs.groovy-lang.org/latest/html/documentation/index.html#_static_import_aliasing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GROOVY-7835) Groovysh does not support static import aliasing
[
https://issues.apache.org/jira/browse/GROOVY-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher updated GROOVY-7835:
--
Description:
Groovysh does not as yet seem to support static import aliasing, e.g.:
{quote}
groovy:000> import static Calendar.getInstance as now
===> static Calendar.getInstance as now
groovy:000> now.class
Unknown property: now
groovy:000>
{quote}
See
http://docs.groovy-lang.org/latest/html/documentation/index.html#_static_import_aliasing
was:
Groovysh does not as yet seem to support static import aliasing, e.g.:
```
groovy:000> import static Calendar.getInstance as now
===> static Calendar.getInstance as now
groovy:000> now.class
Unknown property: now
groovy:000>
```
See
http://docs.groovy-lang.org/latest/html/documentation/index.html#_static_import_aliasing
> Groovysh does not support static import aliasing
>
>
> Key: GROOVY-7835
> URL: https://issues.apache.org/jira/browse/GROOVY-7835
> Project: Groovy
> Issue Type: Improvement
> Components: Groovysh
>Affects Versions: 2.4.6
>Reporter: Jake Gage
>Priority: Minor
>
> Groovysh does not as yet seem to support static import aliasing, e.g.:
> {quote}
> groovy:000> import static Calendar.getInstance as now
> ===> static Calendar.getInstance as now
> groovy:000> now.class
> Unknown property: now
> groovy:000>
> {quote}
> See
> http://docs.groovy-lang.org/latest/html/documentation/index.html#_static_import_aliasing
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GROOVY-6203) GroovyScriptEngine does not take script base class into account
[
https://issues.apache.org/jira/browse/GROOVY-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher resolved GROOVY-6203.
---
Resolution: Fixed
Assignee: Pascal Schumacher
Fix Version/s: 2.4.7
Pull request merged. Thanks!
> GroovyScriptEngine does not take script base class into account
> ---
>
> Key: GROOVY-6203
> URL: https://issues.apache.org/jira/browse/GROOVY-6203
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.0.5
>Reporter: Julien Nicoulaud
>Assignee: Pascal Schumacher
> Fix For: 2.4.7
>
>
> When configuring GroovyScriptEngine with a custom script base class, the
> script engine does not take it account:
> {code}
> CompilerConfiguration cc = new CompilerConfiguration();
> cc.setScriptBaseClass(ScriptBase.class.getName());
> GroovyScriptEngine engine = new GroovyScriptEngine("file://.");
> engine.setConfig(cc);
> Script script = engine.createScript("test.groovy", new Binding());
> assertTrue(script instanceof ScriptBase); // fails
> {code}
> This has been discussed here:
> http://groovy.329449.n5.nabble.com/setScriptBaseClass-does-not-work-for-GroovyScriptEngine-td5710646.html
> The workaround with setting the CompilerConfiguration on the
> GroovyClassLoader works.
> Also related: GROOVY-3281
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
