Re: [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy 3.0

[Simon Sadedin]

As with everyone else: option 3, or even just solving the Java9+ issue
separate from 3.0 is much more important than JDK7.

Cheers,

Simon

On Wed, Jun 13, 2018 at 8:44 PM, Iván López  wrote:

> I also vote for Option 3. I think it is better to focus on JDK 9+ than in
> JDK 7.
>
> Regards, Iván.
>
> --
> @ilopmar 
>
> On 13 June 2018 at 11:30, Russel Winder  wrote:
>
>> On Wed, 2018-06-13 at 08:11 +0100, David Dawson wrote:
>> > I would vote 2.
>> >
>> > Actually, i would vote 3) abandon 2.6 immediately.
>> >
>>
>> I vote for Option 3, abandon 2.6 immediately.
>>
>> With so little resource, the Groovy project must focus on forward looking
>> work, not backward looking stuff. JDK10 is whee the current action is, and
>> where Groovy should be looking to be competitive.
>>
>> --
>> Russel.
>> ===
>> Dr Russel Winder  t: +44 20 7585 2200
>> 41 Buckmaster Road
>> 
>> m: +44 7770 465 077
>> London SW11 1EN, UK   w: www.russel.org.uk
>>
>
>

Re: New webapp development kit using Groovy

[Simon Sadedin]

Congrats on the release!

Looks like a sort of full-stack version of Vert.x or similar (or micronaut
for that matter). Actually would fit the bill for a lot of projects where I
find grails too heavy and slow, especially for SPAs where the front end is
very decoupled from the back end.

Will be giving it a try and see how it goes.

Cheers,

Simon

On Tue, Jul 3, 2018 at 10:26 PM, Blake McBride  wrote:

> Greetings,
>
> I put together an open-source web application development system that uses
> Groovy.  It is a complete (front-end and back-end) solution for web-based
> business applications.  It includes features such as microservices, SQL
> support, custom HTML tags, REST services, user authentication, etc.  Take a
> look if it sounds interesting:  kissweb.org
>
> Blake McBride
>
>

Re: Byte literal

[Simon Sadedin]

>I'm getting the following error:
>
> Error:Groovyc: Attribute 'value' should have type 'java.lang.Byte'; but
found type 'java.lang.Integer' in @Version

I have a similar type of problem where I cannot find any way to invoke
Arrays.fill() for the byte version  - even with explicit workarounds that
should ensure a primitive byte is passed, for example:

def result = new byte[10][10]
final Byte minusOne = -1
for(int i=0; i<10; ++i) {
Arrays.fill(result, 0, dim, minusOne.byteValue())
}

It happens with and without CompileStatic and results in:

java.lang.ArrayStoreException: java.lang.Byte
at java.util.Arrays.fill(Arrays.java:3155)

For these kind of cases  I'm left having to create little Java stub
workarounds to get it to call the right underlying Java API.

Would be nice to have at least a way to work around this!

Cheers,

Simon

Odd behaviour of List to Map coercion within function arguments

[Simon Sadedin]

Hi,

I am trying to understand some behaviour that is causing subtle and odd
bugs in our code.

The behaviour is essentially that under very specific circumstances, Groovy
is coercing a List of Maps to a single Map. A condensed example is:

   class Foo {
def foo(Map obj) {
println(obj)
}
}
z = [
[ a: 1, b:2]
]
f = new Foo()
f.foo(z)

In here, even though the foo() method requires a Map, the call does not
throw a type mismatch exception. Instead, the foo() method receives the Map
object that is the first entry of the list as its argument. Consequently,
it prints:

[a:1, b:2]

If instead, it is passed a list containing two Maps, eg: z = [ [ a: 1,
b:2], [c:1, d:2] ], then it does throw a type conversion error. Also
notable is that it will always throw the type conversion error if you
attempt to coerce it outside the context of a function call, for example,
using z.asType(Map).

So it seems that under very specific circumstances that is both code
context and data dependent, Groovy will perform a different type of type
conversion to what it would do otherwise.

Can anyone explain why it does this and what the rationale is?

Cheers,

Simon

Re: Odd behaviour of List to Map coercion within function arguments

[Simon Sadedin]

On Mon, 18 Mar 2024 at 09:25, Paul King  wrote:

I am not sure I have the full history of when support started (at
> least 15+ years ago) but dynamic Groovy unwraps a list as arguments:
>
> def avg(int a, int b, int c) { (a + b + c)/3 }
> assert avg(1, 2, 3) == 2// normal invocation
> def nums = [10, 20, 30]
> assert avg(nums) == 20// args are a list
>
> It will only do this if the argument is a single List and no method
> matching a single List argument was found. Relevant implementation:
>
>
> https://github.com/apache/groovy/blob/master/src/main/java/groovy/lang/MetaClassImpl.java#L1242
>
> https://github.com/apache/groovy/blob/master/src/main/java/groovy/lang/MetaClassImpl.java#L1246-L1253
>
> You can turn this feature off with @TypeChecked/@CompileStatic.
>

 Thanks - that explains it perfectly!

Though it is still a bit disconcerting how it manifests as a type error at
run time that is data dependent that way. But at least knowing how it works
allows me to think about what's happening and how to handle it.

Cheers / thanks!,

Simon