Re: Looking for testers & feedback: new Groovy binaries for Windows

[Paco Zarate]

I would suggest to keep the gant.exe, it makes really clear that you can
execute that one on Windows. Otherwise I would not know that the
application is there. (as in Linux where you can see the .sh files)

On Tue, Oct 11, 2016 at 2:49 PM, Keegan Witt  wrote:

> Actually question I guess would be whether we even need a gant.exe.
> Nobody really doubleclicks gant files that I'm aware of.
>
> -Keegan
>
> On Tue, Oct 11, 2016 at 4:34 PM, Keegan Witt  wrote:
>
>> Hi Paco,
>> Thanks again for your help.  Yea, it assumes Gant will be installed in
>> the lib directory with the rest of the Groovy jars since that's how it's
>> installed by the Windows installer.  If you drop the jar in there, it
>> should work.
>>
>> I'm mostly liking these so far.  The only thing I might be able to
>> improve on is that all the jars in lib are included in the classpath
>> currently, whereas the C binaries I think were more explicit in some cases
>> (gant I think being one of them).  I want to think through some more
>> whether there's any issues there.
>>
>> -Keegan
>>
>> On Mon, Oct 10, 2016 at 5:57 PM, Paco Zarate 
>> wrote:
>>
>>> Keegan,
>>> The new .exe files look really good, I will keep using them. Even with a
>>> record in the PATH that includes an & (in a non-groovy related folder) it
>>> is working fine.
>>>
>>> The only error was:
>>> paco@DEVELOPER2 C:\Users\paco
>>> > gant
>>> Error: Could not find or load main class gant.Gant
>>>
>>> paco@DEVELOPER2 C:\Users\paco
>>> > gant.exe
>>> Error: Could not find or load main class gant.Gant
>>>
>>> paco@DEVELOPER2 C:\Users\paco
>>> > gant.exe -v
>>> Error: Could not find or load main class gant.Gant
>>>
>>> But i think i am missing the gant install, i will read more about how to
>>> install gant correctly later today and let you know.
>>>
>>> Paco.
>>>
>>> On Mon, Sep 26, 2016 at 12:18 PM, Keegan Witt 
>>> wrote:
>>>
 I started experimenting with launch4j, and have put that experiment in
 this repo: https://github.com/keeganwitt/groovy-launch4j.  I've
 uploaded binaries into same place I previous linked.  The first binaries I
 uploaded are in batWrapper.zip, and the new launch4j based binaries are in
 launch4j.zip if anyone wants to try them out.  At the moment, I only have
 binaries that call Java (i.e. not bundled with Java).

 -Keegan

 On Fri, Sep 9, 2016 at 10:43 PM, Keegan Witt 
 wrote:

> Hmm, maybe the bat files aren't as robust as I assumed and I should
> rethink the approach.
>
> If we went the GCJ route, we'd still have to implement our own logic
> to locate Java binaries (similar to how C code does today), right?  That'd
> be an option, though I'm a little hesitant to start relying on something
> that looks like hasn't been updated in in several years and only supports
> Java 1.4 and some of Java 5.
> Another option would be Launch4J, which is what I was originally
> considering.  If we did that, we could even create 2 sets of binaries -- 1
> with a bundled JRE, and 1 without.  What kinda drew me to that approach 
> was
> that it already had its own logic for locating Java.  I'll do some reading
> on both options.
>
> -Keegan
>
> On Thu, Sep 8, 2016 at 8:27 AM, Jochen Theodorou 
> wrote:
>
>> Maybe a stupid question... but couldn't we write an exe in Java and
>> compile using gcj. The exe would spawn a new "normal" JVM and do the
>> argument handling. Unlike the C variant there would be more people able 
>> to
>> handle this.
>>
>> bye Jochen
>>
>> On 08.09.2016 11:13, Paul King wrote:
>>
>>> I think there are numerous problems with the argument passing in the
>>> batch files. That was one of the things that the exe files aimed to
>>> improve on. I must admit to having reservations about the new
>>> approach.
>>> Not so much with the concept but more about relying on the current
>>> bat
>>> files. That said, I am not sure staying with the current approach is
>>> ideal either.
>>>
>>> Cheers, Paul.
>>>
>>> On Thu, Sep 8, 2016 at 4:57 PM, Paco Zarate <
>>> conta...@nazcasistemas.com
>>> > wrote:
>>>
>>> Hello Keegan
>>> groovy and groovyc are working for me now! thanks!!
>>>
>>> The bat file seems to have an issue on Windows though:
>>>
>>> When the JAVA_HOME is not defined, and the PATH has an element
>>> with
>>> & (ampersand), the groovy invocation seems to try to execute the
>>> code after the & (eg. if mysql is installed there is a PATH
>>> defined to
>>> "c:\Program Files (x86)\MySQL\MySQL Fabric 1.5 & MySQL Utilities
>>> 1.5")
>>> This is the output:
>>> 

Re: Looking for testers & feedback: new Groovy binaries for Windows

[Keegan Witt]

Actually question I guess would be whether we even need a gant.exe.  Nobody
really doubleclicks gant files that I'm aware of.

-Keegan

On Tue, Oct 11, 2016 at 4:34 PM, Keegan Witt  wrote:

> Hi Paco,
> Thanks again for your help.  Yea, it assumes Gant will be installed in the
> lib directory with the rest of the Groovy jars since that's how it's
> installed by the Windows installer.  If you drop the jar in there, it
> should work.
>
> I'm mostly liking these so far.  The only thing I might be able to improve
> on is that all the jars in lib are included in the classpath currently,
> whereas the C binaries I think were more explicit in some cases (gant I
> think being one of them).  I want to think through some more whether
> there's any issues there.
>
> -Keegan
>
> On Mon, Oct 10, 2016 at 5:57 PM, Paco Zarate 
> wrote:
>
>> Keegan,
>> The new .exe files look really good, I will keep using them. Even with a
>> record in the PATH that includes an & (in a non-groovy related folder) it
>> is working fine.
>>
>> The only error was:
>> paco@DEVELOPER2 C:\Users\paco
>> > gant
>> Error: Could not find or load main class gant.Gant
>>
>> paco@DEVELOPER2 C:\Users\paco
>> > gant.exe
>> Error: Could not find or load main class gant.Gant
>>
>> paco@DEVELOPER2 C:\Users\paco
>> > gant.exe -v
>> Error: Could not find or load main class gant.Gant
>>
>> But i think i am missing the gant install, i will read more about how to
>> install gant correctly later today and let you know.
>>
>> Paco.
>>
>> On Mon, Sep 26, 2016 at 12:18 PM, Keegan Witt 
>> wrote:
>>
>>> I started experimenting with launch4j, and have put that experiment in
>>> this repo: https://github.com/keeganwitt/groovy-launch4j.  I've
>>> uploaded binaries into same place I previous linked.  The first binaries I
>>> uploaded are in batWrapper.zip, and the new launch4j based binaries are in
>>> launch4j.zip if anyone wants to try them out.  At the moment, I only have
>>> binaries that call Java (i.e. not bundled with Java).
>>>
>>> -Keegan
>>>
>>> On Fri, Sep 9, 2016 at 10:43 PM, Keegan Witt 
>>> wrote:
>>>
 Hmm, maybe the bat files aren't as robust as I assumed and I should
 rethink the approach.

 If we went the GCJ route, we'd still have to implement our own logic to
 locate Java binaries (similar to how C code does today), right?  That'd be
 an option, though I'm a little hesitant to start relying on something that
 looks like hasn't been updated in in several years and only supports Java
 1.4 and some of Java 5.
 Another option would be Launch4J, which is what I was originally
 considering.  If we did that, we could even create 2 sets of binaries -- 1
 with a bundled JRE, and 1 without.  What kinda drew me to that approach was
 that it already had its own logic for locating Java.  I'll do some reading
 on both options.

 -Keegan

 On Thu, Sep 8, 2016 at 8:27 AM, Jochen Theodorou 
 wrote:

> Maybe a stupid question... but couldn't we write an exe in Java and
> compile using gcj. The exe would spawn a new "normal" JVM and do the
> argument handling. Unlike the C variant there would be more people able to
> handle this.
>
> bye Jochen
>
> On 08.09.2016 11:13, Paul King wrote:
>
>> I think there are numerous problems with the argument passing in the
>> batch files. That was one of the things that the exe files aimed to
>> improve on. I must admit to having reservations about the new
>> approach.
>> Not so much with the concept but more about relying on the current bat
>> files. That said, I am not sure staying with the current approach is
>> ideal either.
>>
>> Cheers, Paul.
>>
>> On Thu, Sep 8, 2016 at 4:57 PM, Paco Zarate <
>> conta...@nazcasistemas.com
>> > wrote:
>>
>> Hello Keegan
>> groovy and groovyc are working for me now! thanks!!
>>
>> The bat file seems to have an issue on Windows though:
>>
>> When the JAVA_HOME is not defined, and the PATH has an element
>> with
>> & (ampersand), the groovy invocation seems to try to execute the
>> code after the & (eg. if mysql is installed there is a PATH
>> defined to
>> "c:\Program Files (x86)\MySQL\MySQL Fabric 1.5 & MySQL Utilities
>> 1.5")
>> This is the output:
>> C:\WINDOWS\system32>groovy.bat -v
>> 'MySQL' is not recognized as an internal or external command,
>> operable program or batch file.
>> 'MySQL' is not recognized as an internal or external command,
>> operable program or batch file.
>> Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor: Oracle Corporation
>> OS:
>> Windows 10
>>
>> I did this another test: I created an empty folder
>>  

Re: Looking for testers & feedback: new Groovy binaries for Windows

[Keegan Witt]

Hi Paco,
Thanks again for your help.  Yea, it assumes Gant will be installed in the
lib directory with the rest of the Groovy jars since that's how it's
installed by the Windows installer.  If you drop the jar in there, it
should work.

I'm mostly liking these so far.  The only thing I might be able to improve
on is that all the jars in lib are included in the classpath currently,
whereas the C binaries I think were more explicit in some cases (gant I
think being one of them).  I want to think through some more whether
there's any issues there.

-Keegan

On Mon, Oct 10, 2016 at 5:57 PM, Paco Zarate 
wrote:

> Keegan,
> The new .exe files look really good, I will keep using them. Even with a
> record in the PATH that includes an & (in a non-groovy related folder) it
> is working fine.
>
> The only error was:
> paco@DEVELOPER2 C:\Users\paco
> > gant
> Error: Could not find or load main class gant.Gant
>
> paco@DEVELOPER2 C:\Users\paco
> > gant.exe
> Error: Could not find or load main class gant.Gant
>
> paco@DEVELOPER2 C:\Users\paco
> > gant.exe -v
> Error: Could not find or load main class gant.Gant
>
> But i think i am missing the gant install, i will read more about how to
> install gant correctly later today and let you know.
>
> Paco.
>
> On Mon, Sep 26, 2016 at 12:18 PM, Keegan Witt 
> wrote:
>
>> I started experimenting with launch4j, and have put that experiment in
>> this repo: https://github.com/keeganwitt/groovy-launch4j.  I've uploaded
>> binaries into same place I previous linked.  The first binaries I uploaded
>> are in batWrapper.zip, and the new launch4j based binaries are in
>> launch4j.zip if anyone wants to try them out.  At the moment, I only have
>> binaries that call Java (i.e. not bundled with Java).
>>
>> -Keegan
>>
>> On Fri, Sep 9, 2016 at 10:43 PM, Keegan Witt 
>> wrote:
>>
>>> Hmm, maybe the bat files aren't as robust as I assumed and I should
>>> rethink the approach.
>>>
>>> If we went the GCJ route, we'd still have to implement our own logic to
>>> locate Java binaries (similar to how C code does today), right?  That'd be
>>> an option, though I'm a little hesitant to start relying on something that
>>> looks like hasn't been updated in in several years and only supports Java
>>> 1.4 and some of Java 5.
>>> Another option would be Launch4J, which is what I was originally
>>> considering.  If we did that, we could even create 2 sets of binaries -- 1
>>> with a bundled JRE, and 1 without.  What kinda drew me to that approach was
>>> that it already had its own logic for locating Java.  I'll do some reading
>>> on both options.
>>>
>>> -Keegan
>>>
>>> On Thu, Sep 8, 2016 at 8:27 AM, Jochen Theodorou 
>>> wrote:
>>>
 Maybe a stupid question... but couldn't we write an exe in Java and
 compile using gcj. The exe would spawn a new "normal" JVM and do the
 argument handling. Unlike the C variant there would be more people able to
 handle this.

 bye Jochen

 On 08.09.2016 11:13, Paul King wrote:

> I think there are numerous problems with the argument passing in the
> batch files. That was one of the things that the exe files aimed to
> improve on. I must admit to having reservations about the new approach.
> Not so much with the concept but more about relying on the current bat
> files. That said, I am not sure staying with the current approach is
> ideal either.
>
> Cheers, Paul.
>
> On Thu, Sep 8, 2016 at 4:57 PM, Paco Zarate <
> conta...@nazcasistemas.com
> > wrote:
>
> Hello Keegan
> groovy and groovyc are working for me now! thanks!!
>
> The bat file seems to have an issue on Windows though:
>
> When the JAVA_HOME is not defined, and the PATH has an element with
> & (ampersand), the groovy invocation seems to try to execute the
> code after the & (eg. if mysql is installed there is a PATH
> defined to
> "c:\Program Files (x86)\MySQL\MySQL Fabric 1.5 & MySQL Utilities
> 1.5")
> This is the output:
> C:\WINDOWS\system32>groovy.bat -v
> 'MySQL' is not recognized as an internal or external command,
> operable program or batch file.
> 'MySQL' is not recognized as an internal or external command,
> operable program or batch file.
> Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor: Oracle Corporation OS:
> Windows 10
>
> I did this another test: I created an empty folder
> "c:\Programs\sample1 & sample2" and added it to the PATH just
> before
> "%GROOVY_HOME%\bin"
>
> When i run:
> C:\WINDOWS\system32> groovy.bat -v
> 'sample2' is not recognized as an internal or external command,
> operable program or batch file.
> Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor: Oracle 

Re: Wrong bytecode generated for getters and setters of volatile field

[Nicolas Peru]

Thanks Paul.

Glad I could help figure this out.
Good luck with the bug then.

Cheers,

Le mar. 11 oct. 2016 à 13:54, Paul King  a écrit :

> This is a bug in Groovy. Normally for a property those modifier bits
> are cleared:
>
> https://github.com/apache/groovy/blob/master/src/main/org/codehaus/groovy/classgen/Verifier.java#L641-L647
>
> But for @Bindable it creates its own setters and bypass the above logic:
>
> https://github.com/apache/groovy/blob/master/src/main/groovy/beans/BindableASTTransformation.java#L247-L258
>
> The same will be true for @Vetoable:
>
> https://github.com/apache/groovy/blob/master/src/main/groovy/beans/VetoableASTTransformation.java#L311-L323
>
> I created the following issue to track the problem:
> https://issues.apache.org/jira/browse/GROOVY-7969
>
> Cheers, Paul.
>
> On Tue, Oct 11, 2016 at 7:34 PM, Nicolas Peru
>  wrote:
> > Hi,
> >
> > I am the developer of the SonarQube Java Analyzer.
> > While we are doing an analysis we are reading bytecode of external
> > dependencies of the compilation unit analyzed.
> >
> > A user recently came back on SonarQube google group complaining about a
> > failure on one of the invariant we have in our bytecode analysis where a
> > bridge method was not marked as synthetic.
> >
> > Investigating a bit further it appears that the failing method is a
> getter
> > generated by groovy compiler and that it is indeed (wrongly) marked as
> > bridge because it is the same bit as the one used for volatile for
> fields.
> >
> > This is an issue that is supposed to be solved  a long time ago per :
> > https://issues.apache.org/jira/browse/GROOVY-3726
> >
> > A reproducer of this issue can be found by compiling the following
> project :
> > https://github.com/Petikoch/sonarqube_issue and looking at the generated
> > .class files.
> >
> > Related discussion about this specific problem on SonarQube Google
> groups:
> >
> https://groups.google.com/forum/?utm_medium=email_source=footer#!msg/sonarqube/htmOuRPm4-c/AVMlDxvOCgAJ
> >
> > as I am no Groovy expert, can anyone shed a light on this ? It sounds to
> me
> > like there is still a bug on Groovy side on this but I might be wrong.
> >
> > Thanks for your help.
> >
> >
> > --
> > Nicolas PERU | SonarSource
> > Senior Developer
> > http://sonarsource.com
> > https://twitter.com/benzonico
>
-- 
*Nicolas PERU | SonarSource*
*Senior Developer*
http://sonarsource.com
https://twitter.com/benzonico

Wrong bytecode generated for getters and setters of volatile field

[Nicolas Peru]

Hi,

I am the developer of the SonarQube Java Analyzer.
While we are doing an analysis we are reading bytecode of external
dependencies of the compilation unit analyzed.

A user recently came back on SonarQube google group complaining about a
failure on one of the invariant we have in our bytecode analysis where a
bridge method was not marked as synthetic.

Investigating a bit further it appears that the failing method is a getter
generated by groovy compiler and that it is indeed (wrongly) marked as
bridge because it is the same bit as the one used for volatile for fields.

This is an issue that is supposed to be solved  a long time ago per :
https://issues.apache.org/jira/browse/GROOVY-3726

A reproducer of this issue can be found by compiling the following project
: https://github.com/Petikoch/sonarqube_issue and looking at the generated
.class files.

Related discussion about this specific problem on SonarQube Google groups:
https://groups.google.com/forum/?utm_medium=email_source=footer#!msg/sonarqube/htmOuRPm4-c/AVMlDxvOCgAJ

as I am no Groovy expert, can anyone shed a light on this ? It sounds to me
like there is still a bug on Groovy side on this but I might be wrong.

Thanks for your help.


-- 
*Nicolas PERU | SonarSource*
*Senior Developer*
http://sonarsource.com
https://twitter.com/benzonico