>
> You keep mixing up the perspective of an application (and application
> assembler) with the perspective of a library/module.
>
>
It's interesting that you say this because we precisely value modeling
applications and libraries differently, using different plugins. However
not everybody does tha
>
> They do. The fact that they create further (solvable) challenges does not
> mean that they are not a solution to the initial problem.
>
> The second point is also incorrect - indeed, this is exactly the point of
> using a range rather than a point version. If I depend on a range "[1.4,
> 2.0)",
Although I doubt that making sure a library _only_ works on the module path
is a good idea, would it make sense to introduce a helper method for this
check? Something like:
Module.assertOnModulePath()
?
2018-03-28 9:41 GMT+02:00 Remi Forax :
> yes,
> !Whatever.class.getModule().isNamed()
>
> Ré
> Version ranges solve this problem.
>
They don't. They introduce new categories of problems (reproducibility,
boundaries) and don't account for the fact that liveliness of a version is
post-publication (a vulnerability is rarely discovered before releasing,
typically).
> Whether or not JPMS en
2018-03-27 15:56 GMT+02:00 Gregg Wonderly :
> I think that Stephen is largely announcing that JigSaw presents more
> problems than it solves for the community. My list of issues, which I have
> shared before, goes basically like this.
>
> 1. Modules should have versions which new tooling on commu
odule path (java 9+), it's important to check both. Before, you could
afford unit testing only with the class directory variant, but that's not
so evident anymore.
2018-03-27 10:29 GMT+02:00 Alan Bateman :
> On 27/03/2018 08:15, Cédric Champeau wrote:
>
>> Dual testing is a
Dual testing is a minimum. In practice, it depends on the kind of tests.
Typically, before JDK 9 for unit tests you never needed a jar to execute
unit tests. Maven happens to built it, but in practice a class directory +
resources is enough (what Gradle does when it knows a jar is not required).
Fo
Hi folks,
Let me rephrase what I think Jochen is saying. It seems there is an
implicit assertion, now, that every file found under META-INF/services are
for the exclusive use of ServiceLoader. It has been brought to the Groovy
language developers attention that Maven had a problem loading Groovy w
There's a good argument for 1, though. log4j typically doesn't separate api
and implementation. So a module would "require 'log4j'". It means that if
another module like slf4j doesn't "pretend to be" log4j, it's now going to
fail. Said differently, Jigsaw kills module replacements and fatjars.
201
This is not really practical. Basically it means that for every Gradle
build script on earth, we would either choose to make them fail on JDK 9,
or be bloated with warnings, that are actually handled.
2017-07-10 11:55 GMT+02:00 Alan Bateman :
> On 10/07/2017 09:49, Cédric Champeau wrote:
>
I second Uwe's comment here: I was surprised as well, I expected the
semantics of `trySetAccessible` to be: "let me know if I can do this,
respecting the semantics of modules, and if not, return false"
2017-07-10 10:43 GMT+02:00 Uwe Schindler :
> Hi Alan,
>
> I was trying to fix Groovy to use try
This looks like a very reasonable proposal, +1
2017-05-18 16:48 GMT+02:00 :
> Over time, as we've gotten closer and closer to the JDK 9 GA date, more
> and more developers have begun paying attention the actual changes in
> this release. The strong encapsulation of JDK-internal APIs has, in
> pa
Is there a specification of how the automatic module name is built? I'm
asking because we will likely have to do something like that in Gradle, and
we cannot use JDK 9 specific APIs for this (Gradle can run on JDK 8, for
example, while the compiler would be forked to use JDK 9, so JDK 9 APIs may
no
>
>
>
> So what is the background to this thread, are you running into a split
> package issue when trying to migrate something to modules?
>
> -Alan
>
I cannot speak for Jochen but at least this is something we have been
discussing for a long time on the Groovy MLs since we know Jigsaw will
preven
25
2016-10-20 19:50 GMT+02:00 Stephen Felts :
> 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, Octo
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
leak into the
runtime of the JVM that executes the test.
[1] https://melix.github.io/javaone2016-juggling-jigsaw/#/
>
>
> -- Kevin
>
>
>
> Alan Bateman wrote:
>
>> On 20/10/2016 08:25, Cédric Champeau wrote:
>>
>> Yes, Gradle, Groovy and other third party lib
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
As a member of both the Gradle and Groovy teams, I must say I am very
worried by this late change in strong encapsulation at runtime. As Jochen
explained, it severely broke Gradle and Groovy, but more importantly, it
breaks a lot of libraries. And it breaks for things that do _not_ care
about modul
Thanks for sharing this, David. We definitely have plans to support modules
"natively" but found like you that Gradle 3.0 makes it possible to work
around pretty easily.
2016-08-25 15:19 GMT+02:00 David Hill :
>
> Hi,
>I mentioned I was working on a modular compilation with Gradle 3 and
> JDK
> Just a related question:
>
> Do you expect the class file format to change in JDK9 and for what
> features? If it is only for supporting the module-info.class then would
> something like the following be possible:
>
> javac -source 9 -target 8 -mp modlib ...
>
> ...and produce JDK8 compatible
To add a bit of perspective from the build tool side (disclaimer, I'm on
the Gradle team), what we do today is that we rely on our model of exports,
which basically follows the Jigsaw one, to generate different artifacts
depending on the target JDK. This has several consequences:
- our model can (
f ProGuard).
2015-11-30 10:43 GMT+01:00 Alan Bateman :
>
> On 30/11/2015 08:50, Cédric Champeau wrote:
>
>> :
>>
>> Eventually, I would also not recommend to put a module-info class (jdk 9
>> format) into a jar built for java 8. Just because there are tons of
>>
2015-11-29 21:26 GMT+01:00 Simon Ochsenreither :
> Hi,
>
> > All told, it could complicates the build a bit and this is
> > where good tooling could help a lot.
>
> is there anything planned in this direction yet? Because the rest of the
> JVM ecosystem seems to remain largely apathetic towards it
ing 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 abo
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
>
> 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 -XaddExport
For what it's worth, the issue that triggered this conversation is the one
reported by Uwe. For Groovy we have a chicken and egg problem for testing,
because this change breaks Groovy, and Groovy uses Gradle to build. Since
Gradle itself uses Groovy, we have no compatible build tool to test the
fix
s.getFileSystem(new URI("jrt:/"));
for(Path root: jrtFs.getRootDirectories()) {
try(DirectoryStream directoryStream =
Files.newDirectoryStream(root)) {
for(Path path: directoryStream) {
System.out.println(path);
}
}
}
cheers,
Rémi
On 12/30/2014 01:57 PM, Cédric Champeau w
ent :)
Thanks!
--
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog
30 matches
Mail list logo
