On 04.11.2016 00:32, mark.reinh...@oracle.com wrote:
2016/11/1 14:17:43 -0700, neil.bartl...@paremus.com:
...
In scenarios where a module's author
can't foresee the need for such access (e.g., intrusive serialization
frameworks) then the framework's author must take more drastic measures
(e.g.,
Hi all,
I do often read about this "split package problem", but I never did see
a proper explanation about why it matters to jigsaw so much that we do
not allow it. Can somebody enlighten me?
bye Jochen
On 04/11/2016 08:05, Jochen Theodorou wrote:
Since Unsafe was mentioned here... All the ways I did know to get to
Unsafe required reflection on private members. Afaik
#AwkwardStrongEncapsulation will block that. So how can I still use
Unsafe in the future or did it get some "proper" public way
Hi Jochen,
the package sun.misc in the module jdk.unsupported is declared open,
do you can use deep reflection on it.
$ javap -m jdk.unsupported module-info
Warning: Binary file module-info contains jdk.unsupported.module-info
Compiled from "module-info.java"
module jdk.unsupported {
requires ja
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
On 04.11.2016 09:12, Alan Bateman wrote:
On 04/11/2016 08:05, Jochen Theodorou wrote:
Since Unsafe was mentioned here... All the ways I did know to get to
Unsafe required reflection on private members. Afaik
#AwkwardStrongEncapsulation will block that. So how can I still use
Unsafe in the futur
On 04/11/2016 08:57, Jochen Theodorou wrote:
That won´t get me access to private fields and constructors in Unsafe
with AwkwardStrongEncapsulation, right? So I see exported, but I don´t
know what you mean with "open" here. I thought we do not have open
modules yet... if we have, I missed the
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
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 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/
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
Please review http://cr.openjdk.java.net/~sundar/8166286/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8166286
Thanks,
-Sundar
On 04/11/2016 10:36, Sundararajan Athijegannathan wrote:
Please review http://cr.openjdk.java.net/~sundar/8166286/webrev.00/
for https://bugs.openjdk.java.net/browse/JDK-8166286
This is probably okay, if only to be consistent with the other tools.
Can you fix the overly long time in JmodTask.j
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/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
>
>
>
> 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
+1
> On Nov 4, 2016, at 7:36 AM, Sundararajan Athijegannathan
> wrote:
>
> Please review http://cr.openjdk.java.net/~sundar/8166286/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8166286
>
> Thanks,
> -Sundar
Hi,
Thanks for the review. Please find the updated webrev:
http://cr.openjdk.java.net/~sundar/8166286/webrev.01/
* Reduced line length in JmodTask.java
* Removed @bug comment - earlier I attempted a separate test file for
this - comment carried over from that step.
Using ordinary comment now
* On
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.
> 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 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.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 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/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 11:34, Sundararajan Athijegannathan wrote:
Hi,
Thanks for the review. Please find the updated webrev:
http://cr.openjdk.java.net/~sundar/8166286/webrev.01/
* Reduced line length in JmodTask.java
* Removed @bug comment - earlier I attempted a separate test file for
this - comment
Changeset: 92b89631b7b2
Author:alanb
Date: 2016-11-04 15:37 +
URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/92b89631b7b2
More clean-up of Provides
! test/javax/xml/jaxp/module/ServiceProviderTest/src/unnamed/Main.java
Changeset: 258783abd899
Author:alanb
Date: 2016-11-04 15:38 +
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/258783abd899
More clean-up of Provides
! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java
! src/jdk.jdeps/share/classes/com/sun/tools/j
Changeset: 92473a4168e5
Author:alanb
Date: 2016-11-04 14:54 +
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/92473a4168e5
Improve getResourceXXX to avoid scanning all resources in all modules
! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java
Change
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.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
31 matches
Mail list logo
