Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Jochen Theodorou]

On 03.11.2015 16:03, Alan Bateman wrote:

On 03/11/2015 13:41, Jochen Theodorou wrote:


Well, what we currently do is fill a ClassInfo class (a kind of
reflection cache from which we generate our meta class) with the all
the members we can access. This is the non-private members from the
parents and all declared members of the current class. If the current
class is blocked, it will automatically consist only of the not
blocked information from the parent.

By "blocked" then do you mean setAccessible(true) fails or specific
exceptions like IllegalAccess*, InaccessibleObjectException or maybe
SecurityException?


I mean SecurityException and InaccessibleObjectException.


Does it meant that Groovy will work with strong encapsulation? I realize
there are issues with support for dynamic code generation that aren't
currently exposed in the API.


IllegalAccessException is a different story, Groovy does not do strong 
encapsulation in the Java sense. Well, it is more that the access 
modifiers have a slightly different meaning, but it goes probably too 
far to explain details.


bye Jochen

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Alan Bateman]

On 03/11/2015 13:41, Jochen Theodorou wrote:


Well, what we currently do is fill a ClassInfo class (a kind of 
reflection cache from which we generate our meta class) with the all 
the members we can access. This is the non-private members from the 
parents and all declared members of the current class. If the current 
class is blocked, it will automatically consist only of the not 
blocked information from the parent.
By "blocked" then do you mean setAccessible(true) fails or specific 
exceptions like IllegalAccess*, InaccessibleObjectException or maybe 
SecurityException?


Does it meant that Groovy will work with strong encapsulation? I realize 
there are issues with support for dynamic code generation that aren't 
currently exposed in the API.


-Alan

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Jochen Theodorou]

On 03.11.2015 13:06, Alan Bateman wrote:
[...]

Good to hear, so I'm guess you have to talk the hierarchy of the runtime
time to find the type that is part of the API. With modules then could
this look at the exportness?


Well, what we currently do is fill a ClassInfo class (a kind of 
reflection cache from which we generate our meta class) with the all the 
members we can access. This is the non-private members from the parents 
and all declared members of the current class. If the current class is 
blocked, it will automatically consist only of the not blocked 
information from the parent.


We don't try to find the module and its exports at runtime. Maybe we 
will do such things later to improve performance.


bye Jochen

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Alan Bateman]

On 02/11/2015 12:55, Jochen Theodorou wrote:


This impression is wrong, Groovy does not need access to all 
JDK-internal types.
Okay, I should have said "potentially all" as there are many cases were 
the implementation type is not in an exported package.


But this is a dynamic language at heart. If you do not have a static 
type, then the runtime type is what counts, and that is the exact 
type, which is sometime an internal JDK type. It means Groovy has to 
do the same thing it has to do when a security manager doesn't like 
access to this class, which is to not use the specific class/method, 
but the super class information... or the information of that super 
class.. in worst case this will be Object, which means only method 
from Object can be called using Groovy in that case.


The current state is, that this issue is now fixed. The example 
scripts in the issue are working. That does not mean we can now run 
the build on jigsaw of course.
Good to hear, so I'm guess you have to talk the hierarchy of the runtime 
time to find the type that is part of the API. With modules then could 
this look at the exportness?


-Alan

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Jochen Theodorou]

Hi,

Jochen here, not Rory, but Groovy maintainer ;) So for Groovy reporting 
on the mailing list is good, if you also want to discuss the bug a bit 
there. If you really only want to report it, then you can just write it 
in the bug tracker. Of course Gradle is Gradle and Groovy is Groovy


bye Jochen

On 02.11.2015 23:23, Mani Sarkar wrote:

Hi Rory,

TestNG has an alternative build system which we will try to use to build
it using the Jigsaw binary.

How do you report such bugs to Gradle / Groovy ? Is it simpler if you
reported to them on their mailing list ? Let me know what works best,
this is fairly important as other Gradle users might have similar issues.

Cheers,
Mani

On Mon, Nov 2, 2015 at 8:51 AM, Rory O'Donnell mailto:rory.odonn...@oracle.com>> wrote:

I can't find a bug in Gradle's JIRA on this issue, Mani do you want
to log an issue there ?

Rgds,Rory


On 31/10/2015 13:56, Alan Bateman wrote:

On 31/10/2015 12:50, Mani Sarkar wrote:

Hi Rory,

Do you know of a version of Gradle or a EA version which is
JDK 9 Jigsaw compatible, we get these failures when building:


https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console


Caused by: java.lang.IllegalAccessException: class
org.gradle.internal.reflect.DirectInstantiator cannot access
class com.sun.tools.javac.api.JavacTool (in module jdk.compiler)
because module jdk.compiler does not export package
com.sun.tools.javac.api to 
 at

org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49)
 ... 86 more

We should at least check if there is a bug in the Gradle JIRA
for this. It can be worked around by configuring the compileJava
options to fork javac but you might not want to do that.

The other issue with Gradle that we know about is the
ClassCastException when attempting to run tests, this is tracked
here:
https://issues.gradle.org/browse/GRADLE-3287

-Alan.


--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland




--
@theNeomatrix369 *  | **Blog
**  | *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
*  | **Bitbucket
* * | **Github
** | **LinkedIn
*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*/Don't chase success, rather aim for "Excellence", and success will
come chasing after you!/*

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Mani Sarkar]

Hi Rory,

TestNG has an alternative build system which we will try to use to build it
using the Jigsaw binary.

How do you report such bugs to Gradle / Groovy ? Is it simpler if you
reported to them on their mailing list ? Let me know what works best, this
is fairly important as other Gradle users might have similar issues.

Cheers,
Mani

On Mon, Nov 2, 2015 at 8:51 AM, Rory O'Donnell 
wrote:

> I can't find a bug in Gradle's JIRA on this issue, Mani do you want to log
> an issue there ?
>
> Rgds,Rory
>
>
> On 31/10/2015 13:56, Alan Bateman wrote:
>
>> On 31/10/2015 12:50, Mani Sarkar wrote:
>>
>>> Hi Rory,
>>>
>>> Do you know of a version of Gradle or a EA version which is JDK 9 Jigsaw
>>> compatible, we get these failures when building:
>>>
>>>
>>> https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console
>>>
>>> Caused by: java.lang.IllegalAccessException: class
>> org.gradle.internal.reflect.DirectInstantiator cannot access class
>> com.sun.tools.javac.api.JavacTool (in module jdk.compiler) because module
>> jdk.compiler does not export package com.sun.tools.javac.api to > module @b7f23d9>
>> at
>> org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49)
>> ... 86 more
>>
>> We should at least check if there is a bug in the Gradle JIRA for this.
>> It can be worked around by configuring the compileJava options to fork
>> javac but you might not want to do that.
>>
>> The other issue with Gradle that we know about is the ClassCastException
>> when attempting to run tests, this is tracked here:
>> https://issues.gradle.org/browse/GRADLE-3287
>>
>> -Alan.
>>
>>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>


-- 
@theNeomatrix369 *  |  **Blog
**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
*  |  **Bitbucket
* * |  **Github
* * |  **LinkedIn
*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Jochen Theodorou]

On 02.11.2015 11:24, Alan Bateman wrote:
[...]

Uwe Schindler has created a bug on this topic here:

   https://issues.apache.org/jira/browse/GROOVY-7587

It makes me wonder if Groovy has ever been used with a security manager
as it seems to wrap or need access to all JDK-internal types.


This impression is wrong, Groovy does not need access to all 
JDK-internal types. But this is a dynamic language at heart. If you do 
not have a static type, then the runtime type is what counts, and that 
is the exact type, which is sometime an internal JDK type. It means 
Groovy has to do the same thing it has to do when a security manager 
doesn't like access to this class, which is to not use the specific 
class/method, but the super class information... or the information of 
that super class.. in worst case this will be Object, which means only 
method from Object can be called using Groovy in that case.


The current state is, that this issue is now fixed. The example scripts 
in the issue are working. That does not mean we can now run the build on 
jigsaw of course.


bye Jochen

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Cédric Champeau]

Surely Groovy is widely used with security managers, and it has never been
a problem so far. I'm not sure how this issue is relevant to the problem,
but Jochen expressed several times concerns about how Groovy would interact
with Jigsaw without getting clear answers, or at best "we don't know". I'm
unfortunately not in a position where I can investigate right now, but
Jigsaw is certainly critical for both Groovy and Gradle, so I'd like to
make sure we address all issues before Jigsaw is out. Basically my focus
today is making Gradle capable of building apps using Jigsaw, but not
running on Jigsaw. Just because those are competing priorities. But both
*have* to be fixed.

2015-11-02 11:24 GMT+01:00 Alan Bateman :

>
> On 02/11/2015 09:58, Cédric Champeau wrote:
>
>>
>> I think this is the particular issue Jochen is very worried about. We
>> should think about the consequences of it. What does it mean to be forced
>> to use -XaddExports. It is at least unclear to me. What would be
>> catastrophic is releasing Jigsaw and realizing that we killed Groovy
>> because it cannot use modules without, for example, disabling all kind of
>> security.
>>
>
> Uwe Schindler has created a bug on this topic here:
>
>   https://issues.apache.org/jira/browse/GROOVY-7587
>
> It makes me wonder if Groovy has ever been used with a security manager as
> it seems to wrap or need access to all JDK-internal types.
>
> -Alan.
>

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Alan Bateman]

On 02/11/2015 09:58, Cédric Champeau wrote:


I think this is the particular issue Jochen is very worried about. We 
should think about the consequences of it. What does it mean to be 
forced to use -XaddExports. It is at least unclear to me. What would 
be catastrophic is releasing Jigsaw and realizing that we killed 
Groovy because it cannot use modules without, for example, disabling 
all kind of security.


Uwe Schindler has created a bug on this topic here:

  https://issues.apache.org/jira/browse/GROOVY-7587

It makes me wonder if Groovy has ever been used with a security manager 
as it seems to wrap or need access to all JDK-internal types.


-Alan.

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Rory O'Donnell]

I can't find a bug in Gradle's JIRA on this issue, Mani do you want to 
log an issue there ?


Rgds,Rory

On 31/10/2015 13:56, Alan Bateman wrote:

On 31/10/2015 12:50, Mani Sarkar wrote:

Hi Rory,

Do you know of a version of Gradle or a EA version which is JDK 9 
Jigsaw compatible, we get these failures when building:


https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console 



Caused by: java.lang.IllegalAccessException: class 
org.gradle.internal.reflect.DirectInstantiator cannot access class 
com.sun.tools.javac.api.JavacTool (in module jdk.compiler) because 
module jdk.compiler does not export package com.sun.tools.javac.api to 

at 
org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49)

... 86 more

We should at least check if there is a bug in the Gradle JIRA for 
this. It can be worked around by configuring the compileJava options 
to fork javac but you might not want to do that.


The other issue with Gradle that we know about is the 
ClassCastException when attempting to run tests, this is tracked here:

https://issues.gradle.org/browse/GRADLE-3287

-Alan.



--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Cédric Champeau]

BTW, Groovy itself is not compatible with Jigsaw, so my guess would be that
even if Gradle fixed this, you would have different errors because Gradle
uses Groovy. What is possible today is to run Gradle on Java 9 non jigsaw,
and compile using Java 9 Jigsaw.

Jochen sent an email on jigsaw-dev a few weeks ago ("Groovy with Jigsaw")
but as far as I understand, there's no clear understanding of the
problem/solutions so far.

2015-11-02 9:51 GMT+01:00 Rory O'Donnell :

> I can't find a bug in Gradle's JIRA on this issue, Mani do you want to log
> an issue there ?
>
> Rgds,Rory
>
>
> On 31/10/2015 13:56, Alan Bateman wrote:
>
>> On 31/10/2015 12:50, Mani Sarkar wrote:
>>
>>> Hi Rory,
>>>
>>> Do you know of a version of Gradle or a EA version which is JDK 9 Jigsaw
>>> compatible, we get these failures when building:
>>>
>>>
>>> https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console
>>>
>>> Caused by: java.lang.IllegalAccessException: class
>> org.gradle.internal.reflect.DirectInstantiator cannot access class
>> com.sun.tools.javac.api.JavacTool (in module jdk.compiler) because module
>> jdk.compiler does not export package com.sun.tools.javac.api to > module @b7f23d9>
>> at
>> org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49)
>> ... 86 more
>>
>> We should at least check if there is a bug in the Gradle JIRA for this.
>> It can be worked around by configuring the compileJava options to fork
>> javac but you might not want to do that.
>>
>> The other issue with Gradle that we know about is the ClassCastException
>> when attempting to run tests, this is tracked here:
>> https://issues.gradle.org/browse/GRADLE-3287
>>
>> -Alan.
>>
>>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Cédric Champeau]

>
>  That issue was resolved at the time and I don't think there were any
> other specific issues on that thread. There was of course the general issue
> that Groovy seems to access or wrap types in non-exported packages but we
> don't have a solution to that except via the command-line -XaddExports.
>
> -Alan.
>

I think this is the particular issue Jochen is very worried about. We
should think about the consequences of it. What does it mean to be forced
to use -XaddExports. It is at least unclear to me. What would be
catastrophic is releasing Jigsaw and realizing that we killed Groovy
because it cannot use modules without, for example, disabling all kind of
security.

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Alan Bateman]

On 02/11/2015 08:56, Cédric Champeau wrote:
BTW, Groovy itself is not compatible with Jigsaw, so my guess would be 
that even if Gradle fixed this, you would have different errors 
because Gradle uses Groovy. What is possible today is to run Gradle on 
Java 9 non jigsaw, and compile using Java 9 Jigsaw.


Jochen sent an email on jigsaw-dev a few weeks ago ("Groovy with 
Jigsaw") but as far as I understand, there's no clear understanding of 
the problem/solutions so far.
There was one specific issue in that thread, it was a VerifyError that 
stemmed from Guava overriding 
java.lang.reflect.AccessibleObject.setAccessible. That issue was 
resolved at the time and I don't think there were any other specific 
issues on that thread. There was of course the general issue that Groovy 
seems to access or wrap types in non-exported packages but we don't have 
a solution to that except via the command-line -XaddExports.


-Alan.

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Alan Bateman]

On 31/10/2015 12:50, Mani Sarkar wrote:

Hi Rory,

Do you know of a version of Gradle or a EA version which is JDK 9 
Jigsaw compatible, we get these failures when building:


https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console

Caused by: java.lang.IllegalAccessException: class 
org.gradle.internal.reflect.DirectInstantiator cannot access class 
com.sun.tools.javac.api.JavacTool (in module jdk.compiler) because 
module jdk.compiler does not export package com.sun.tools.javac.api to 

at 
org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49)

... 86 more

We should at least check if there is a bug in the Gradle JIRA for this. 
It can be worked around by configuring the compileJava options to fork 
javac but you might not want to do that.


The other issue with Gradle that we know about is the ClassCastException 
when attempting to run tests, this is tracked here:

https://issues.gradle.org/browse/GRADLE-3287

-Alan.