Re: About type inference of method return value

[MG]

Hi Jochen,

but in what sense is any of these examples confusing for the user ? Type 
inference is not magic, and it can quickyl become a hard mathematical 
problem (https://en.wikipedia.org/wiki/Type_inference). But in all that 
cases, we should just fall back to Object or throw. I don't know 
Daniel's intentions, but for me type inference for methods (same as for 
fields/variables) should only be used for simple, obvious cases, not for 
complex ones (eveb if these are of course the only interesting 
intellectual challnge ;-) ). If I, as a developer, cannot see the 
deduced type at a a glance, then the RHS expression is already too complex.


I have added some comments to the examples:

On 05.09.2018 23:03, Jochen Theodorou wrote:



private foo() {
  return new SomeMarkerInterface(){
    def x() {1}
  }
}


is the return type here SomeMarkerInterface or XYZ$1? 


XYZ$1


Can I do foo().x()?


yes




private foo() {
  if (something) {
 return x // of class X
  } else {
 return y // of class Y
  }
}


if X and Y implement the interfaces Foo and Bar the common super type 
would be something like Object+Foo+Bar, which cannot be an actual 
return type, because the Java type system cannot properly express that 
type. Which is it then? Object, or Foo or Bar? 


Intuitively I would not infer on interfaces, but only classes. In 
practice I would expect X and Y to have a common superclass that is not 
Object; otherwise infer Object.


And if you think this problem is small, you have to consider this one 
here as well:



private foo() {
  def ret
  if (something) {
 ret = x // of class X
  } else {
 ret = y // of class Y
  }
  return ret
}


Same problem as before obviously, just showing that using local 
variables makes it even worse.


Infer Object - if you use Object for the return variable type, this is 
what you should expect...





And how about this one?


private f(List l) {   if (l.size()==1) {
    return l[0]
  } else {
    return f(l.tail())
  }
}


for me it is obvious the return type is X, but a compiler must be able 
to see through the recursive call and it must see that it is a 
recursive call.


Too complex => infer Object




private f(List l) {   if (l.size()==1) {
    return g(l[0])
  } else {
    return g(f(l.tail()))
  }
}
private g(X x){x}
private g(List l){l}



here it gets even more complicated... g(l[0]) is easy, that will 
return X, since l[0] will return X causing a call to g(X):X. But since 
we currently infer f, we cannot simply know what f(l.tail()) will be, 
thus we cannot easily know if we call here g(X):X or g(List):List.


Way too complex and ambivalent => throw 
GroovyMethodReturnTypeInferenceComplexityError telling programmer he 
must supply the return type explicitely (optional: compiler parameter to 
infer Object in these cases)




Or let us say there is also g(Object):Object and let us assume we 
delete g(X):X. Then inferring the type above successfully means 
obviously to let f return Object. The change will go unnoticed in f 
and cause secondary errors in callers of f. In the worst case even 
quite far away from the callsite itself.


I do not follow: What secondary errors would that be ? How would they 
differ from errors that occur when the user explicitely supplies Object 
as return type ?




Wanting more?


private f(List l) {   if (l.size()==1) {
    return l[0]
  } else {
    return g(l.tail())
  }
}
private g(List l){f(l)}


to know the return type of f I need to know the return type of g, for 
which I need to know the return type of f... global type inference 
could solve such problems, but makes about everything else more 
complicated


GroovyMethodReturnTypeInferenceComplexityError...

Cheers,
mg

Re: About type inference of method return value

[Jochen Theodorou]

On 05.09.2018 14:36, mg wrote:

I agree with Daniel here, I also don't see how this could be confusing (?).

Even if the inference mechanism falls back to inferring Object, the user 
will just get an "cannot call dadadam on Object" or such compile error - 
which should immediately leave to the conclusion that the type needs to 
be given explicitely in this case...


Does anyone have an example that shows such a malign/confusing type 
deduction case ?


Let's start easy


private foo() {
  return new SomeMarkerInterface(){
def x() {1}
  }
}


is the return type here SomeMarkerInterface or XYZ$1? Can I do foo().x()?


private foo() {
  if (something) {
 return x // of class X
  } else {
 return y // of class Y
  }
}


if X and Y implement the interfaces Foo and Bar the common super type 
would be something like Object+Foo+Bar, which cannot be an actual return 
type, because the Java type system cannot properly express that type. 
Which is it then? Object, or Foo or Bar? And if you think this problem 
is small, you have to consider this one here as well:



private foo() {
  def ret
  if (something) {
 ret = x // of class X
  } else {
 ret = y // of class Y
  }
  return ret
}


Same problem as before obviously, just showing that using local 
variables makes it even worse.


And how about this one?

private f(List l) { 
  if (l.size()==1) {

return l[0]
  } else {
return f(l.tail())
  }
}


for me it is obvious the return type is X, but a compiler must be able 
to see through the recursive call and it must see that it is a recursive 
call.


private f(List l) { 
  if (l.size()==1) {

return g(l[0])
  } else {
return g(f(l.tail()))
  }
}
private g(X x){x}
private g(List l){l}



here it gets even more complicated... g(l[0]) is easy, that will return 
X, since l[0] will return X causing a call to g(X):X. But since we 
currently infer f, we cannot simply know what f(l.tail()) will be, thus 
we cannot easily know if we call here g(X):X or g(List):List.


Or let us say there is also g(Object):Object and let us assume we delete 
g(X):X. Then inferring the type above successfully means obviously to 
let f return Object. The change will go unnoticed in f and cause 
secondary errors in callers of f. In the worst case even quite far away 
from the callsite itself.


Wanting more?

private f(List l) { 
  if (l.size()==1) {

return l[0]
  } else {
return g(l.tail())
  }
}
private g(List l){f(l)}


to know the return type of f I need to know the return type of g, for 
which I need to know the return type of f... global type inference could 
solve such problems, but makes about everything else more complicated


bye Jochen

Re: Constructor call short-hand syntax

[Jochen Theodorou]

Am 05.09.2018 um 00:22 schrieb Paul King:
[..]

for example. I personally think we can take supporting things like
x[y:z] and x?[y:z] as future project... if we find a nice use case
for this.

We certainly could ... but we don't have such a proposal in front of us 
right now,


How about this... think of t as a sql database based table T and t[id:1] 
as a version to do "select * from T where id=1"


bye Jochen

Re: Constructor call short-hand syntax

[mg]

In my view creating a new instance of a class is a call to its ctor, which 
takes arguments, for which the (shorthand) syntax in Java and Groovy is (...), 
not [...]
[...] is access by indices / get something at coordinates. Even if one would 
follow the view that a Class object contains an infinite amount of instances 
inside of it, which are accessed through class' ctor parameters interpreted as 
indices, then [...] semantics would still imply that each access with the same 
index tuple (ie parameters) will return the same class instance - which is 
evidently not compatible with ctor calls.
(This is in addition to the fact that you cannot discontinue the syntactically 
very different looking mainstream, existing new Goo(...) syntax since it a) is 
what Java (and other) devs know, b) it is in every Groovy program/script ever 
written, and c) it is in DSLs.)
Cheers,mg

 Ursprüngliche Nachricht Von: Daniil Ovchinnikov 
 Datum: 05.09.18  14:54  (GMT+01:00) An: 
dev@groovy.apache.org Betreff: Re: Constructor call short-hand syntax 
I didn’t know that it’s a shorthand constructor syntax when I’ve created a 
ticket. 
I thought it should just work as shorthand for getAt call:a[1, 2] == a.getAt(1, 
2)a[x: y] == a.getAt(x: y)a?[1, 2] == a?.getAt(1, 2) // this works alreadya?[x: 
y] == a?.getAt(x: y)
And now I see it as a perfect Groovy-style replacement for @Newify.
Why even @Newify exists if Groovy already had Person[name: “John”, age: 42] 
syntax?If such syntax exists, why not extend it to be equivalent to 
Person.class.getAt(name: “John”, age: 42), where getAt on a class instance 
would instantiate a new object ?The last question implies that getAt would work 
with any arguments, including named ones.

—

Daniil Ovchinnikov
JetBrains




On 5 Sep 2018, at 01:22, Paul King  wrote:


On Wed, Sep 5, 2018 at 2:52 AM Jochen Theodorou  wrote:Am 
04.09.2018 um 06:49 schrieb Daniel Sun:
> Hi Paul,
> 
>       Safe index is only for accessing the elements of collections and object
> properties, but not for creating instance. The collections and objects may
> be null, so we designed the "safe" index.
> 
>       To sum up, I vote -1 to support syntax like `Date[time:0]`, the class
> instance will not be null.

I think you actually miss the point a little. Let me rephrase... should 
we support

somMap?[x:y]

for example. I personally think we can take supporting things like 
x[y:z] and x?[y:z] as future project... if we find a nice use case for this.

We certainly could ... but we don't have such a proposal in front of us right 
now, so it'swhether we'd like to cater for the current situation in the 
meantime with an improvederror message. We could remove such an error message 
at a future point if we havean acceptable proposal.
Having said that, it's hard to pick up this error case here without also making 
themissing : within a ternary error message look more complex. You'd basically 
needan error message that coped with both cases. Hence my suggestion to close 
as"Won't fix". (But fix up the empty Map edge case only - without safe 
decorator).
bye Jochen

Re: Constructor call short-hand syntax

[Daniil Ovchinnikov]

I didn’t know that it’s a shorthand constructor syntax when I’ve created a 
ticket. 

I thought it should just work as shorthand for getAt call:
a[1, 2] == a.getAt(1, 2)
a[x: y] == a.getAt(x: y)
a?[1, 2] == a?.getAt(1, 2) // this works already
a?[x: y] == a?.getAt(x: y)

And now I see it as a perfect Groovy-style replacement for @Newify.

Why even @Newify exists if Groovy already had Person[name: “John”, age: 42] 
syntax?
If such syntax exists, why not extend it to be equivalent to 
Person.class.getAt(name: “John”, age: 42), where getAt on a class instance 
would instantiate a new object ?
The last question implies that getAt would work with any arguments, including 
named ones.

—

Daniil Ovchinnikov
JetBrains


> On 5 Sep 2018, at 01:22, Paul King  wrote:
> 
> 
> 
> On Wed, Sep 5, 2018 at 2:52 AM Jochen Theodorou  > wrote:
> Am 04.09.2018 um 06:49 schrieb Daniel Sun:
> > Hi Paul,
> > 
> >   Safe index is only for accessing the elements of collections and 
> > object
> > properties, but not for creating instance. The collections and objects may
> > be null, so we designed the "safe" index.
> > 
> >   To sum up, I vote -1 to support syntax like `Date[time:0]`, the class
> > instance will not be null.
> 
> I think you actually miss the point a little. Let me rephrase... should 
> we support
> 
> somMap?[x:y]
> 
> for example. I personally think we can take supporting things like 
> x[y:z] and x?[y:z] as future project... if we find a nice use case for this.
> 
> We certainly could ... but we don't have such a proposal in front of us right 
> now, so it's
> whether we'd like to cater for the current situation in the meantime with an 
> improved
> error message. We could remove such an error message at a future point if we 
> have
> an acceptable proposal.
> 
> Having said that, it's hard to pick up this error case here without also 
> making the
> missing : within a ternary error message look more complex. You'd basically 
> need
> an error message that coped with both cases. Hence my suggestion to close as
> "Won't fix". (But fix up the empty Map edge case only - without safe 
> decorator).
> 
> bye Jochen

Re: About type inference of method return value

[mg]

I agree with Daniel here, I also don't see how this could be confusing (?).
Even if the inference mechanism falls back to inferring Object, the user will 
just get an "cannot call dadadam on Object" or such compile error - which 
should immediately leave to the conclusion that the type needs to be given 
explicitely in this case...
Does anyone have an example that shows such a malign/confusing type deduction 
case ?

 Ursprüngliche Nachricht Von: "Daniel.Sun"  
Datum: 05.09.18  14:02  (GMT+01:00) An: d...@groovy.incubator.apache.org 
Betreff: Re: About type inference of method return value 
I just propose the smarter type inference for methods, which was in my TODO
list.

> We explicitly chose not to be too smart here, because it can be confusing
> to users.

OK. Recently I am developing a project based on Groovy.  Writing code with
"dynamic" mind and compile code in "static" way. So I don't care why STC
passes but just care why STC doesn't work and try to fix compilation errors,
some of which impress me that Groovy is not smart enough.
So I don't understand why smarter type inference will confuse users.

Cheers,
Daniel.Sun


Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About type inference of method return value

[mg]

I agree with Daniel here, I also don't see how this could be confusing (?).
Even if the inference mechanism falls back to inferring Object, the user will 
just get an "cannot call dadadam on Object" or such compile error - which 
should immediately leave to the conclusion that the type needs to be given 
explicitely in this case...
Does anyone have an example that shows such a malign/confusing type deduction 
case ?

 Ursprüngliche Nachricht Von: "Daniel.Sun"  
Datum: 05.09.18  14:02  (GMT+01:00) An: d...@groovy.incubator.apache.org 
Betreff: Re: About type inference of method return value 
I just propose the smarter type inference for methods, which was in my TODO
list.

> We explicitly chose not to be too smart here, because it can be confusing
> to users.

OK. Recently I am developing a project based on Groovy.  Writing code with
"dynamic" mind and compile code in "static" way. So I don't care why STC
passes but just care why STC doesn't work and try to fix compilation errors,
some of which impress me that Groovy is not smart enough.
So I don't understand why smarter type inference will confuse users.

Cheers,
Daniel.Sun


Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About type inference of method return value

[Daniel.Sun]

I just propose the smarter type inference for methods, which was in my TODO
list.

> We explicitly chose not to be too smart here, because it can be confusing
> to users.

OK. Recently I am developing a project based on Groovy.  Writing code with
"dynamic" mind and compile code in "static" way. So I don't care why STC
passes but just care why STC doesn't work and try to fix compilation errors,
some of which impress me that Groovy is not smart enough.
So I don't understand why smarter type inference will confuse users.

Cheers,
Daniel.Sun


Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About type inference of method return value

[Daniel.Sun]

This is another smarter type inference for `final`, which should work too if
my proposal is supported by most of groovy users.


Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About type inference of method return value

[Cédric Champeau]

Sorry I don't understand what you are saying. What I'm saying is that we
already had such an implementation, and we decided to _remove_ it. Are you
saying that you have a branch that reintroduces it, or that it's already on
master?

I disagree with the statement that the "users require smarter type
inference". Type inference is cool, but it's also hard to predict.
Sometimes you just don't understand why the compiler inferred something or
not. We explicitly chose not to be too smart here, because it can be
confusing to users.

Le mer. 5 sept. 2018 à 13:36, Daniel.Sun  a écrit :

> Hi Cédric,
>
>  > Basically, it's not easy to realize that when you have a non final
> methods, subclasses can override the method to return a different type.
>
>  As I proposed, the methods with smarter return type inference should
> match one of the following charactristics:
> 1) `final`
> 2) `private`
> 3) `static`
> 4)  method defined in Script
>
>  So these methods will not be overrided and the return type will be
> exact.
>
>  I will leave the implementation as it is util most of groovy users
> require the smarter type inference ;-)
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: About type inference of method return value

[Daniel.Sun]

Hi Cédric,

 > Basically, it's not easy to realize that when you have a non final
methods, subclasses can override the method to return a different type.

 As I proposed, the methods with smarter return type inference should
match one of the following charactristics: 
1) `final` 
2) `private` 
3) `static` 
4)  method defined in Script

 So these methods will not be overrided and the return type will be
exact.

 I will leave the implementation as it is util most of groovy users
require the smarter type inference ;-)

Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Old bytecode targets

[Remi Forax]

COMPUTE_FRAMES + getCommonSuperClass is one option, calling visitFrame by 
yourself is the other option, for the later usually you have more context to 
find the super type but it means you have to generate the visitFrame at the 
right place.

Rémi

- Mail original -
> De: "Jochen Theodorou" 
> À: "dev" 
> Envoyé: Mercredi 5 Septembre 2018 12:44:45
> Objet: Re: Old bytecode targets

> Am 05.09.2018 um 12:36 schrieb Remi Forax:
> [...]
>> 
>> it's not free if you ask ASM (COMPUTE_FRAMES) to do the fix point algorithm
>> (which is not linear) and to infer the common supertype, if you generate the
>> StackFrames in the groovy compiler by calling explicitly visitFrame, the
>> runtime cost is not big (but you need to modify your compiler backend which 
>> has
>> development a cost).
> 
> 
> we cannot let asm just do this 100% for us. The classes under
> compilation are possibly not available through classloading, and asm
> might not even use the right classloader if they would. what we do then
> is using COMPUTE_FRAMES, but override
> 
> protected String getCommonSuperClass(String arg1, String arg2)
> 
> which does a not 100% correct calculation of the common super class.
> (not 100% correct means here to claim it is Object in some cases, where
> there would be a better fit)
> 
> bye Jochen

Re: Constructor call short-hand syntax

[mg]

I think we should consider deprecating and/or hiding such syntax constructs 
behind a compiler switch / @Legacy annotation, otherwise we can never rid 
Groovy of sins from the past.
Short term in my opinion we should definitely "will not fix" GROOVY-8602, and 
leave the [:] edge case as is (ie unsupported), as to not encourage use of the 
syntax.

 Ursprüngliche Nachricht Von: Paul King  
Datum: 05.09.18  00:08  (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: 
Constructor call short-hand syntax 


On Wed, Sep 5, 2018 at 4:58 AM mg  wrote:
Couldn't we rather consider phasing out the whole construct ? Allowing a ctor 
to be called without new only in this special case seems awfully inconsistent...
I think it has been around for a long time and might be in use in DSLs. I'd 
probably not encourage it's use in normal programming but see no harm in 
leacing the existing support. And with the new @MapConstructor / 
@NamedVariant/... and @Newify(pattern=...) support, one can achieve the same 
thing from modular annotation building blocks - just without the confusing 
square brackets syntax (which does not work for method calls taking a map 
argument).
 Ursprüngliche Nachricht Von: Paul King  
Datum: 04.09.18  00:30  (GMT+01:00) An: dev@groovy.apache.org Betreff: 
Constructor call short-hand syntax 

Groovy has a rarely used shorthand syntax for constructors:
println Date[time:0] // same as new Date(time:0)println Date[year: 118, month: 
8, date: 3] // same as new Date(year: 118, month: 8, date: 3)
GROOVY-8602points out that the safe args version isn't supported, e.g.:
println Date?[time:0]
I was thinking of closing this as won't fix since we only support this 
shorthand for class constants.
Any objections?
Also, I noticed that the empty map isn't catered for:
println Date[:] // as per above, might be expected to be the same as new 
Date([:]) or new Date()
// currently NPE: Cannot get property '{}' on null object
So, the map isn't found and the expression becomes "println Date" which returns 
void and then we convert the map to a String and look for that property.
I realise this is a weird edge case but I was thinking of creating an issue to 
fix this for consistency (just Groovy 3). We already support this:

def map = [:]println Date[*:map]
Let me know if you have other thoughts.

Cheers, Paul.

Re: Old bytecode targets

[Jochen Theodorou]

Am 05.09.2018 um 12:36 schrieb Remi Forax:
[...]


it's not free if you ask ASM (COMPUTE_FRAMES) to do the fix point algorithm 
(which is not linear) and to infer the common supertype, if you generate the 
StackFrames in the groovy compiler by calling explicitly visitFrame, the 
runtime cost is not big (but you need to modify your compiler backend which has 
development a cost).



we cannot let asm just do this 100% for us. The classes under 
compilation are possibly not available through classloading, and asm 
might not even use the right classloader if they would. what we do then 
is using COMPUTE_FRAMES, but override


protected String getCommonSuperClass(String arg1, String arg2)

which does a not 100% correct calculation of the common super class. 
(not 100% correct means here to claim it is Object in some cases, where 
there would be a better fit)


bye Jochen

Warnings when using J11 and groovy3.0.0-alpha-3

[Kerridge, Jon]

Hi,
I am using J11 latest Oracle build plus groovy 3.0.0-alpha-3.

The groovy test program is a simple print hello script

I am using Intellij with Gradle and the relevant parts of the build file are:

repositories {
mavenCentral()
maven {
url "https://dl.bintray.com/groovy/maven;
}
}

dependencies {
compile 'org.codehaus.groovy:groovy:3.0.0-alpha-3'
compile group: 'javax.xml.bind', name: 'jaxb-api', version: '2.3.0'
}

The program works but I get a warning as follows:

"C:\Program Files\Java\jdk-11\bin\java.exe" "-Dtools.jar=C:\Program 
Files\Java\jdk-11\lib\tools.jar" 
-Dgroovy.home=C:\Users\Jon\.gradle\caches\modules-2\files-2.1\org.codehaus.groovy\groovy\3.0.0-alpha-3\81b3f93dc6c8cdecdca450c6d5326abe9ea28971
 "-Dgroovy.starter.conf=C:\Program Files\JetBrains\IntelliJ IDEA Community 
Edition 2018.2.2\plugins\Groovy\lib\groovy-starter.conf" "-javaagent:C:\Program 
Files\JetBrains\IntelliJ IDEA Community Edition 
2018.2.2\lib\idea_rt.jar=58513:C:\Program Files\JetBrains\IntelliJ IDEA 
Community Edition 2018.2.2\bin" -Dfile.encoding=UTF-8 -classpath 
C:\Users\Jon\.gradle\caches\modules-2\files-2.1\org.codehaus.groovy\groovy\3.0.0-alpha-3\81b3f93dc6c8cdecdca450c6d5326abe9ea28971\groovy-3.0.0-alpha-3.jar
 org.codehaus.groovy.tools.GroovyStarter --conf "C:\Program 
Files\JetBrains\IntelliJ IDEA Community Edition 
2018.2.2\plugins\Groovy\lib\groovy-starter.conf" --main groovy.ui.GroovyMain 
--classpath 
.;D:\IJTest\testj10g2.5.2\out\production\classes;C:\Users\Jon\.gradle\caches\modules-2\files-2.1\org.codehaus.groovy\groovy\3.0.0-alpha-3\81b3f93dc6c8cdecdca450c6d5326abe9ea28971\groovy-3.0.0-alpha-3.jar
 --encoding=UTF-8 D:\IJTest\testj10g2.5.2\src\main\groovy\test1.groovy
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v7.Java7$1 
(file:/C:/Users/Jon/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy/3.0.0-alpha-3/81b3f93dc6c8cdecdca450c6d5326abe9ea28971/groovy-3.0.0-alpha-3.jar)
 to constructor java.lang.invoke.MethodHandles$Lookup(java.lang.Class,int)
WARNING: Please consider reporting this to the maintainers of 
org.codehaus.groovy.vmplugin.v7.Java7$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release
hello from test

Process finished with exit code 0

Where hello from test is what I was expecting!

Is this currently expected behaviour or is something amiss?

Jon Kerridge


From: Paul King 
Sent: 14 August 2018 12:21
To: dev@groovy.apache.org; kdra...@ptc.com
Subject: Re: Java 11 Compatibility check: Apache-groovy


On Tue, Aug 14, 2018 at 9:10 PM Dragan, Krzysztof 
mailto:kdra...@ptc.com>> wrote:
Hi,
We are reaching out to you to check Java 11 compatibility of the library 
Apache-groovy

Could you help us by answering the following questions:

Col 1

Col2

Col3

Col4

Col5

Col6

Library name

Latest version

Is the library compatible with Java 11 Compatible?
(Y/N)

Is the library supported with Java 11?
(Y/N)

(If “N” in compatibility or support)
What is the versions that would be compatible and Supported?

Date of support availability?

Apache Groovy

Stable: 2.5.2, Preliminary: 3.0.0-alpha-3

For 2.5, Groovy classes compiled with JDK10 should run on JDK11. Groovy 3.0 
builds and all tests pass on JDK11 but further testing is required.

See previous answer.

See previous answer.

2.5.2 was released yesterday. Groovy 3.0.0 final doesn't have a set target date 
yet but isn't due in the next few months.


Appreciate your response by 17.08.2018

Thanks,
Krzysztof Dragan
PTC Inc. Contractor


This message and its attachment(s) are intended for the addressee(s) only and 
should not be read, copied, disclosed, forwarded or relied upon by any person 
other than the intended addressee(s) without the permission of the sender. If 
you are not the intended addressee you must not take any action based on this 
message and its attachment(s) nor must you copy or show them to anyone. Please 
respond to the sender and ensure that this message and its attachment(s) are 
deleted.

It is your responsibility to ensure that this message and its attachment(s) are 
scanned for viruses or other defects. Edinburgh Napier University does not 
accept liability for any loss or damage which may result from this message or 
its attachment(s), or for errors or omissions arising after it was sent. Email 
is not a secure medium. Emails entering Edinburgh Napier University's system 
are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration 
number SC018373

Re: About type inference of method return value

[Cédric Champeau]

Hi Daniel,

We discussed this when we implemented static compilation in the past. There
were 2 different relates cases discussed:

- smarter type inference for final fields
- smarter type inference for final methods

and decided not to implement them, so that it's not confusing for users
when the compiler can infer a type in one case and not the other. We can
revisit the decision, just want to give more context. Basically, it's not
easy to realize that when you have a non final methods, subclasses can
override the method to return a different type.


Le mer. 5 sept. 2018 à 06:50, Daniel Sun  a écrit :

> Hi all,
>
>   I am going to refine the type inference of method return value, the
> methods should match one of the following charactristics:
> 1) `final`
> 2) `private`
> 3) `static`
> 4)  method defined in Script
>
>   The above methods will not be overrided and have exact method return
> type.
>
>   Any thoughts?
>
>   P.S. Currently the following code will fail to compile, but it's
> obiviously valid.
> ```
> @groovy.transform.CompileStatic
> class Test {
> static m() {
> return 'abc'
> }
>
> static a() {
> return m().length()
> }
>
> static void main(String[] args) {
> assert 3 == a()
> }
> }
> ```
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: About type inference of method return value

[mg]

Hi Daniel,
would the following case work:
class Goo {  @Lazy static final Goo instance = new Goo(...)  static getGOO() { 
instance } // return type deduced to be Goo ?}
Cheers,mg
 Ursprüngliche Nachricht Von: Daniel Sun 
 Datum: 05.09.18  06:49  (GMT+01:00) An: 
d...@groovy.incubator.apache.org Betreff: About type inference of method return 
value 
Hi all,

  I am going to refine the type inference of method return value, the
methods should match one of the following charactristics:
1) `final`
2) `private`
3) `static`
4)  method defined in Script

  The above methods will not be overrided and have exact method return
type.  

  Any thoughts?

  P.S. Currently the following code will fail to compile, but it's
obiviously valid.
```
@groovy.transform.CompileStatic
class Test {
    static m() {
    return 'abc'
    }
    
    static a() {
    return m().length()
    }
    
    static void main(String[] args) {
    assert 3 == a()
    }
}
```

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About type inference of method return value

[mg]

Hi Daniel,
would the following case work:
class Goo {  @Lazy static final Goo instance = new Goo(...)  static getGOO() { 
instance } // return type deduced to be Goo ?}
Cheers,mg
 Ursprüngliche Nachricht Von: Daniel Sun 
 Datum: 05.09.18  06:49  (GMT+01:00) An: 
d...@groovy.incubator.apache.org Betreff: About type inference of method return 
value 
Hi all,

  I am going to refine the type inference of method return value, the
methods should match one of the following charactristics:
1) `final`
2) `private`
3) `static`
4)  method defined in Script

  The above methods will not be overrided and have exact method return
type.  

  Any thoughts?

  P.S. Currently the following code will fail to compile, but it's
obiviously valid.
```
@groovy.transform.CompileStatic
class Test {
    static m() {
    return 'abc'
    }
    
    static a() {
    return m().length()
    }
    
    static void main(String[] args) {
    assert 3 == a()
    }
}
```

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html