On 21/10/2016 10:08, Jochen Theodorou wrote:
:
And another example...
Module A:
package a
class X {
protected void foo(){}
}
unnamed Module:
package u
class Y extends X{
public void bar(){ foo() }
}
How am I supposed to realize the call to foo using a runtime based on
classic reflecti
Subject: Gradle not working on Jigsaw
I have the line
def branch = file('..').name
in build.gradle.
Running 'gradle' on build 140
Jdk-9 - runs fine
JDK-9 Jigsaw gets
* What went wrong:
A problem occurred evaluating root project 'dir'.
> No such property: name for
On 21/10/16 10:08, Jochen Theodorou wrote:
> I wrote "same class" and thought same class and subclasses... my bad.
> Anyway, I am aware of how it works, the problem is that shi... caller
> sensitivity. If you work with classic reflection and have a central
> space for these kind of actions (for exa
On 20.10.2016 16:14, Alan Bateman wrote:
On 20/10/2016 14:48, Jochen Theodorou wrote:
:
I still wish you had at least not included protected members. Sure,
protected is not public and protected is always a pain in the butt, I
still fail to comprehend the logic that a class can extend a class
ber 20, 2016 1:33 PM
> *To:* Stephen Felts
> *Cc:* jigsaw-dev
> *Subject:* Re: Gradle not working on Jigsaw
>
>
>
> Gradle uses a custom ClassReader on top of the one provided by ASM to fix
> this version issue.
>
>
>
> 2016-10-20 18:38 GMT+02:00 Stephen Felts :
&g
PM
To: HYPERLINK "mailto:jigsaw-dev@openjdk.java.net"jigsaw-dev@openjdk.java.net
Subject: Gradle not working on Jigsaw
I have the line
def branch = file('..').name
in build.gradle.
Running 'gradle' on build 140
Jdk-9 - runs fine
JDK-9 Jigsaw gets
* What went wro
7.jar!groovyjarjarasm/asm/ClassReader.class
>
> that fail if the version is > 52.
>
> This isn't related to the failure below but they should be fixed.
>
>
> -Original Message-
> From: Stephen Felts
> Sent: Wednesday, October 19, 2016 10:43 PM
> To: j
Message-
From: Stephen Felts
Sent: Wednesday, October 19, 2016 10:43 PM
To: jigsaw-dev@openjdk.java.net
Subject: Gradle not working on Jigsaw
I have the line
def branch = file('..').name
in build.gradle.
Running 'gradle' on build 140
Jdk-9 - runs fine
JDK-9 Jigsaw gets
I realized after reading Alan's email more closely that an important
difference between his usage and my test yesterday is that he used
_JAVA_OPTIONS whereas I was trying it with just JAVA_OPTS (the latter is
recognized and used by gradle, but the former applies to all exec'ed
java/javac comman
On 20/10/2016 15:27, Stephen Felts wrote:
:
Jython seems to be doing a setAccessible on a lot of methods. It catches
SecurityException and ignores it. Of course, JDK9 throws a different exception
so the code is broken.
Further, the new exception is JDK9 only so the code needs to change to ca
> A trySetAccessible is possible although a @CS variant of accessCheck (like in
> MH.Lookup) might be more general. I think we need to be cautious about adding
> APIs here and so would be interesting to get some performance data here (I >
> don't think I've seen the bulk setAccessible used very
On 20/10/2016 14:48, Jochen Theodorou wrote:
:
I still wish you had at least not included protected members. Sure,
protected is not public and protected is always a pain in the butt, I
still fail to comprehend the logic that a class can extend a class
from another module and then use the pro
On 20.10.2016 10:19, Alan Bateman wrote:
[...]
The latest
proposal in the JSR is an attempt to address that issue but it does
impact code that uses setAccessible to get at non-public types/members
in java.* classes.
I still wish you had at least not included protected members. Sure,
protecte
>
>
>
> One thing we are looking at doing as a workaround is to launch gradle with
> a pre-Jigsaw enabled JDK (e.g., JDK 8u112 or JDK 9 build 109) and fork/exec
> javac, java, javadoc, etc., with the latest jigsaw EA.
Yes, that's the strategy I used for my talk about Jigsaw support in Gradle
[1].
We use gradle for building JavaFX, so I did some testing earlier in the
week and found similar issues. I had tried adding
"--add-exports-private=java.base/java.lang=ALL-UNNAMED" to JAVA_OPTIONS,
but hadn't run into
"--add-exports-private=java.base/java.util=ALL-UNNAMED" yet (it died
before it
On 20/10/2016 08:25, Cédric Champeau wrote:
Yes, Gradle, Groovy and other third party libraries Gradle uses are
broken since the changes to enforce strong encapsulation at runtime
(preventing calls to setAccessible). I already raised the concern
here, saying we have no clear idea of the impact
Yes, Gradle, Groovy and other third party libraries Gradle uses are broken
since the changes to enforce strong encapsulation at runtime (preventing
calls to setAccessible). I already raised the concern here, saying we have
no clear idea of the impact of such a change at a larger scale, but it
total
On 20/10/2016 03:42, Stephen Felts wrote:
I have the line
def branch = file('..').name
in build.gradle.
Running 'gradle' on build 140
Jdk-9 - runs fine
JDK-9 Jigsaw gets
* What went wrong:
A problem occurred evaluating root project 'dir'.
No such property: name for class: java.io.File
To
I have the line
def branch = file('..').name
in build.gradle.
Running 'gradle' on build 140
Jdk-9 - runs fine
JDK-9 Jigsaw gets
* What went wrong:
A problem occurred evaluating root project 'dir'.
> No such property: name for class: java.io.File
To run on Jigsaw, I also need to set _JAVA_OPTI
19 matches
Mail list logo
