On 05.11.2016 13:56, Alan Bateman wrote:
On 05/11/2016 10:29, Jochen Theodorou wrote:
On 05.11.2016 08:39, Alan Bateman wrote:
The application module reads other modules rather than layers, in this
case it results in the application module reading C, B-1, D, and B-2
(assuming that the applic
On 05/11/2016 10:29, Jochen Theodorou wrote:
On 05.11.2016 08:39, Alan Bateman wrote:
The application module reads other modules rather than layers, in this
case it results in the application module reading C, B-1, D, and B-2
(assuming that the application modules `requires C` and `requires D
On 05.11.2016 08:39, Alan Bateman wrote:
On 04/11/2016 16:50, Jochen Theodorou wrote:
:
Attempting to do this with multiple configuration + layers isn't going
to help, it's just not safe, and you'll get the same exception.
One layer with B-1 and C and another with B-2 and D and my applicati
On 04/11/2016 16:50, Jochen Theodorou wrote:
:
Attempting to do this with multiple configuration + layers isn't going
to help, it's just not safe, and you'll get the same exception.
One layer with B-1 and C and another with B-2 and D and my application
"reading" from those layers... is that
On 04.11.2016 15:54, Andrew Dinn wrote:
[...]
Problem number 1, how to start this if application, A, D, B-1 and B-2
are modules? You don't care that the module system does not allow for
this, you have to run it in that configuration and you have to have a
way around this. Which means you will hav
On 04.11.2016 15:29, Alan Bateman wrote:
On 04/11/2016 13:22, Jochen Theodorou wrote:
:
well... assume you have an application and it requires the library A,
which transitively requires B-1. the application also requires library
C, which transitively requires B-2. B-1 and B-2 are not compatibl
On 04/11/16 13:22, Jochen Theodorou wrote:
> "classloader hell" goes far beyond the classpath. The problem is rarely
> caused by a classloader that loads two versions of the same library with
> different classes. But happens then more easily if your classloaders
> suddenly have to become forests. F
On 04/11/2016 13:22, Jochen Theodorou wrote:
:
well... assume you have an application and it requires the library A,
which transitively requires B-1. the application also requires library
C, which transitively requires B-2. B-1 and B-2 are not compatible.
library A and D leak instances of cl
On 04.11.2016 11:50, Andrew Dinn wrote:
[...]
- Modules stop you providing two versions of a package in the same
layer, a problem for classpath deployment which, as Remi noted, can
easily lead to you mixing classes from two different versions of a library.
but sometimes you have to do someth
On 04.11.2016 12:36, Sander Mak wrote:
On 04 Nov 2016, at 12:06, Cédric Champeau wrote:
It's a very big issue, typically all Gradle plugins written in Groovy would
break. Gradle itself would break. There are things to mitigate that, like
rewriting classes at load time, or an easier solution
> On 04 Nov 2016, at 12:06, Cédric Champeau wrote:
>
> It's a very big issue, typically all Gradle plugins written in Groovy would
> break. Gradle itself would break. There are things to mitigate that, like
> rewriting classes at load time, or an easier solution which is to have a
> single Groov
On 04/11/2016 11:06, Cédric Champeau wrote:
:
We haven't made any decision yet. Not something we can take easy.
Understood, and not for me to say, but I would assume the priority has
to be to get Groovy working with JDK 9 first, maybe this is what
Jochen's other thread about Unsafe is about.
>
>
>
> 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
On 04/11/16 10:04, Jochen Theodorou wrote:
> What I see mostly is that all the problems you have now on a per class
> level, you later have on a per module level again... for example needing
> two versions of the same library being active at the same time... and
> the movement away from the static
On 04/11/16 09:33, Alessio Stalla wrote:
> Also, I think there is a problem related to how class loading works. In the
> vanilla world of Java apps with a single classloader, if you load classes
> in the same (source) package from different sources, the end up in the same
> (runtime) package. But
On 04/11/2016 10:04, Jochen Theodorou wrote:
:
What I see mostly is that all the problems you have now on a per class
level, you later have on a per module level again... for example
needing two versions of the same library being active at the same
time... and the movement away from the stat
On 04.11.2016 10:33, Alan Bateman wrote:
[...]
This is all part of reliable configuration where you can prove
correctness by construction. Alex's "Under the Hood" session from
JavaOne 2016 [1] is a great resource for understanding the science.
-Alan
[1] http://openjdk.java.net/projects/jigsaw/
Also, I think there is a problem related to how class loading works. In the
vanilla world of Java apps with a single classloader, if you load classes
in the same (source) package from different sources, the end up in the same
(runtime) package. But if you have different classloaders at play, and lo
On 04/11/2016 09:22, Jochen Theodorou wrote:
On 04.11.2016 09:25, Remi Forax wrote:
There are two issues with split packages,
- if you have the same class in each part of the package, the
behavior of your problem depend on the order in the classpath,
i've experienced this kind of bugs with
On 04.11.2016 09:25, Remi Forax wrote:
There are two issues with split packages,
- if you have the same class in each part of the package, the behavior of your
problem depend on the order in the classpath,
i've experienced this kind of bugs with two different libraries requiring
different ve
There are two issues with split packages,
- if you have the same class in each part of the package, the behavior of your
problem depend on the order in the classpath,
i've experienced this kind of bugs with two different libraries requiring
different version of ASM, at runtime, a class of the o
21 matches
Mail list logo
