Re: JSR 308 support for Groovy

[Paul King]

Thanks Daniel,

I created this additional sub-task:

https://issues.apache.org/jira/browse/GROOVY-8228 JSR308 grammar changes

If any parts turn out to be controversial or need further discussion we can
create further issues.

Cheers, Paul.


On Tue, Jun 13, 2017 at 2:34 AM, Daniel Sun  wrote:

> Hi Paul,
>
> > The grammar isn't expecting an annotation on the parameterized type. It
> > fails for both the old and new parsers with slightly different error
> > messages.
>
>   I will set aside some time to complete the grammar and AST
> construction.
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/JSR-308-support-for-Groovy-tp5741586p5741591.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>

Re: JSR 308 support for Groovy

[Daniel Sun]

Hi Paul,

> The grammar isn't expecting an annotation on the parameterized type. It
> fails for both the old and new parsers with slightly different error
> messages.

  I will set aside some time to complete the grammar and AST
construction.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/JSR-308-support-for-Groovy-tp5741586p5741591.html
Sent from the Groovy Users mailing list archive at Nabble.com.

JSR 308 support for Groovy

[Paul King]

I have started examining what is required for JSR 308 support in Groovy. It
is one of those things which might make sense to ensure we support in the
new grammar from the get go.

Current issues:

https://issues.apache.org/jira/browse/GROOVY-8225
https://issues.apache.org/jira/browse/GROOVY-8226

With just a few tweaks (GROOVY-8226) we get some stuff for free since
we had some bits geared up already. We can now start using some of the
Java libraries which leverage the JSR, e.g.:

==>8==
@Grab('com.pholser:junit-quickcheck-generators:0.7')
@Grab('com.pholser:junit-quickcheck-core:0.7')
import com.pholser.junit.quickcheck.generator.InRange
import com.pholser.junit.quickcheck.runner.JUnitQuickcheck
import org.junit.runner.RunWith
import com.pholser.junit.quickcheck.Property

@RunWith(JUnitQuickcheck)
class IntegerRanges {
@Property
void shouldHold(@InRange(min = "0", max = "9") Integer item) {
item >= 0 && item <= 9
}
}
==>8==

Which uses a property-based testing framework to call our assertion 100
times. It works in fact even with the old grammar once the plumbing changes
are done.

What we can't do at the moment is something like this:

==>8==
@Property
void shouldAlsoHold(List<@InRange(min = "0", max = "9") Integer> items) {
assert items.every{ it >= 0 && it <= 9 }
}
==>8==

The grammar isn't expecting an annotation on the parameterized type. It
fails for both the old and new parsers with slightly different error
messages.

I'll be taking a look at what else is required to make this work but if
anyone has particular requirements or comments, or some part they would
like to work on, please let me know.

Cheers, Paul.

Re: Minecraft modding with Groovy: @CompileStatic not statically compiling fields ?

[Jochen Theodorou]

On 10.06.2017 21:52, Ahm Avoby wrote:

Hi,

I am a Groovy developer at work, and am trying to switch my sons
Minecraft 1.11.2 project (Forge based) from Java to Groovy 2.4.11. Since
the generated class files need to be obfuscated to work with Minecraft,
I am using @CompileStatic, as suggested by another Minecraft developer,
so that the Forge obfuscator finds the field/method names in the class
files. This works in some cases, but when trying to access fields of the
base class (e.g. net.minecraft.entity.Entity) I am encountering
groovy.lang.MissingPropertyException|s.


you need the obfuscation to be able to call into the obfuscated 
minecraft code I assume. It sounds very much like a bug if calling to a 
accessible super class field ends up in a MissingPropertyException. Is 
it possible for you to make a small example? Though I had assumed, that 
if you use forge, you do not need to do that anymore. Well, modding on 
minecraft is not unknown to me, but I never tried to mod myself. So of 
course I have no idea about the details.



I don't have much experience using @CompileStatic (nor with Minecraft
modding), but looking at the generated class files, it seems as if
property (same for fields) access is not compiled statically, but
remains a call to ScriptBytecodeAdapter.setProperty, with the property
name given as a string literal (ergo the obfuscator won't see it, and
the call in Minecraft will fail). I have explained this more in-depth
with code samples on minecraftforum.net, but did not get a reply (
http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/modification-development/2828852-groovy-compilestatic-solution-not-working-when).


Frankly, about every setProperty/getProperty call in @CompileStatic is 
not right and needs fixing.



Can anyone confirm to me that what I am seeing is the excpected
@CompileStatic behavior - so using @CompileStatic on all Groovy classes
is not the solution to modding Minecraft with Groovy - or if there is
something I can do differently ?


That is not the expected behaviour, no. If you can provide samples, 
especially a small script, that shows the problem but has no other 
dependencies, you would help us to fix this.


As for obfuscation in Groovy in general... I think it can be done, but 
there are some limitations, even with @CompileStatic. Our final goal for 
@CompileStatic is to have a runtime, that has only the minimum required 
dynamic elements, but right now we have a lot of methods, that you 
usually call, that have more a naming convention, than anything else. 
And such conventions do not translate to obfuscation well. For example 
doCall in Closure, asBoolean, and iterator are very central here, as 
they are called from the runtime dynamically even if @CompileStatic is 
used. But excluding those few would then already do the job.. well... in 
theory... if @CompileStatic does not fall back to a dynamic setProperty 
for a reason it should not do that of course.



I would also be grateful for any other suggestion at a solution - I
really would like to avoid having to revert the project back to its Java
version :-)


depending on the problem we could fix it and ensure there is a speedy 
2.4.12. Other solution my also require knowing the nature of the problem 
first


bye Jochen