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
It's possible to work around the gradle error below by adding
--add-exports-private=java.base/java.io=ALL-UNNAMED to _JAVA_OPTIONS.
It's unfortunate that javac doesn't recognize this option because up until now
I had been using one jdk9args file for both java and javac.
The next one that I ran i
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
I’m not sure that I understand. I did a jar xf on the class and ran jad on it.
Are you saying it’s somehow by-passing this class?
From: Cédric Champeau [mailto:cedric.champ...@gmail.com]
Sent: Thursday, October 20, 2016 1:33 PM
To: Stephen Felts
Cc: jigsaw-dev
Subject: Re: Gradle not
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 :
> I also note that Gradle 3.0 still has both
>
> lib/asm-all-5.1.jar!org/objectweb/asm/ClassReader.class
>
> and
>
> lib/groovy-all-2.4.7.jar!groovyjarjarasm/as
I also note that Gradle 3.0 still has both
lib/asm-all-5.1.jar!org/objectweb/asm/ClassReader.class
and
lib/groovy-all-2.4.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-
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
18 matches
Mail list logo
