Re: Java does not see method implemented in Groovy

2018-04-23 Thread Schalk Cronjé

On 23/04/2018 17:13, mg wrote:

Are you using the Gradle build cache ?
Have you tried building the code using the IntelliJ build system (I am 
not sure if you mean that by "In IntelliJ this is not flagged up as an 
issue either" or that only Intellisense does not complain) ?


It's not a Gradle build cache issue. I can also reproduce the problem in 
IntelliJ now (after a restart).


I got it working now, but I cannot explain why. I removed the method and 
then just inherited it again (with no code body). Re-compiled and it 
worked. Replaced the code body, re-compiled and now it works.


This is a WTF. It does not make sense.






 Ursprüngliche Nachricht 
Von: Schalk Cronjé 
Datum: 23.04.18 12:05 (GMT+01:00)
An: users@groovy.apache.org
Betreff: Java does not see method implemented in Groovy

Hi all,

I have build an hierarchy that effectively looks like:

Abstract Base #1 (Java)
    ^
    |
Abstract Base #2 (Groovy, CompileStatic)
    ^
    |
Abstract Base #3 (Groovy, CompileStatic)
    ^
    |
Abstract Base #4 (Groovy, CompileStatic) <- Implements methodA
from Abstract Base #1
    ^    ^ ^
    |    | |
ExampleG (Groovy)    ExampleJ (Java)   ExampleK (Kotlin)




--
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r



Re: Java does not see method implemented in Groovy

2018-04-23 Thread mg
Are you using the Gradle build cache ?Have you tried building the code using 
the IntelliJ build system (I am not sure if you mean that by "In IntelliJ this 
is not flagged up as an issue either" or that only Intellisense does not 
complain) ?
Cheers,mg
 Ursprüngliche Nachricht Von: Schalk Cronjé  
Datum: 23.04.18  12:05  (GMT+01:00) An: users@groovy.apache.org Betreff: Java 
does not see method implemented in Groovy 

Hi all,
I have build an hierarchy that effectively looks like:



  Abstract Base #1 (Java)

      ^

      |

  Abstract Base #2 (Groovy, CompileStatic)

      ^

      |

Abstract Base #3 (Groovy, CompileStatic)

      ^

      |

Abstract Base #4 (Groovy, CompileStatic) <- Implements
  methodA from Abstract Base #1

      ^    ^ ^  

      |    | |

  ExampleG (Groovy)    ExampleJ (Java)   ExampleK (Kotlin)



Finally there are three examples - one each in  Groovy, Java and
  otlin example. They extend #4 with concrete classes. The Groovy
  and Kotlin examples compile fine, but the Java complains that
  methodA is not implemented. The real signature of methodA is
  actually

  SeekableByteChannel newByteChannel(Path path, Set options, FileAttribute[]
  attrs) throws IOException

  

This could be down to what the Groovy compiler (2.4.11) has done
  with the generics, but it has me me confused. I am even more
  surprised that only the Java compiler complains and not the Kotlin
  compiler.  In IntelliJ this is not flagged up as an issue either.
  It only occurs when compiling the project with Gradle.


I know my example is slightly vague, but it removes all of the
  noise. The actual code of the offending class is here ->
https://gitlab.com/ysb33rOrg/java-nio2-providers/blob/development/commons-compress-provider-core/src/test/java/org/ysb33r/nio/provider/commons_core/examples/java/GzFileSystemProvider.java
Now I'm hoping if anyone has seen issues like this before or have
  an idea where I can start diagnosing it.


-- 
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r
  

Re: Java does not see method implemented in Groovy

2018-04-23 Thread Paul King
A bit of a long shot but does compiling the class by hand (outside gradle)
make any difference?


On Mon, Apr 23, 2018 at 8:05 PM, Schalk Cronjé  wrote:

> Hi all,
>
> I have build an hierarchy that effectively looks like:
>
> Abstract Base #1 (Java)
> ^
> |
> Abstract Base #2 (Groovy, CompileStatic)
> ^
> |
> Abstract Base #3 (Groovy, CompileStatic)
> ^
> |
> Abstract Base #4 (Groovy, CompileStatic) <- Implements methodA from
> Abstract Base #1
> ^^ ^
> || |
> ExampleG (Groovy)ExampleJ (Java)   ExampleK (Kotlin)
>
> Finally there are three examples - one each in  Groovy, Java and otlin
> example. They extend #4 with concrete classes. The Groovy and Kotlin
> examples compile fine, but the Java complains that methodA is not
> implemented. The real signature of methodA is actually
>
> SeekableByteChannel newByteChannel(Path path, Set
> options, FileAttribute[] attrs) throws IOException
>
> This could be down to what the Groovy compiler (2.4.11) has done with the
> generics, but it has me me confused. I am even more surprised that only the
> Java compiler complains and not the Kotlin compiler.  In IntelliJ this is
> not flagged up as an issue either. It only occurs when compiling the
> project with Gradle.
>
> I know my example is slightly vague, but it removes all of the noise. The
> actual code of the offending class is here ->
> https://gitlab.com/ysb33rOrg/java-nio2-providers/blob/
> development/commons-compress-provider-core/src/test/java/
> org/ysb33r/nio/provider/commons_core/examples/java/
> GzFileSystemProvider.java
>
> Now I'm hoping if anyone has seen issues like this before or have an idea
> where I can start diagnosing it.
>
> --
> Schalk W. Cronjé
> Twitter / Ello / Toeter : @ysb33r
>
>


Java does not see method implemented in Groovy

2018-04-23 Thread Schalk Cronjé

Hi all,

I have build an hierarchy that effectively looks like:

   Abstract Base #1 (Java)
    ^
    |
   Abstract Base #2 (Groovy, CompileStatic)
    ^
    |
   Abstract Base #3 (Groovy, CompileStatic)
    ^
    |
   Abstract Base #4 (Groovy, CompileStatic) <- Implements methodA from
   Abstract Base #1
    ^    ^ ^
    |    | |
   ExampleG (Groovy)    ExampleJ (Java)   ExampleK (Kotlin)

Finally there are three examples - one each in  Groovy, Java and otlin 
example. They extend #4 with concrete classes. The Groovy and Kotlin 
examples compile fine, but the Java complains that methodA is not 
implemented. The real signature of methodA is actually


   SeekableByteChannel newByteChannel(Path path, Set options, FileAttribute[] attrs) throws IOException

This could be down to what the Groovy compiler (2.4.11) has done with 
the generics, but it has me me confused. I am even more surprised that 
only the Java compiler complains and not the Kotlin compiler.  In 
IntelliJ this is not flagged up as an issue either. It only occurs when 
compiling the project with Gradle.


I know my example is slightly vague, but it removes all of the noise. 
The actual code of the offending class is here -> 
https://gitlab.com/ysb33rOrg/java-nio2-providers/blob/development/commons-compress-provider-core/src/test/java/org/ysb33r/nio/provider/commons_core/examples/java/GzFileSystemProvider.java


Now I'm hoping if anyone has seen issues like this before or have an 
idea where I can start diagnosing it.


--
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r