Re: Jlink and automatic module

2016-07-10 Thread Paul Benedict
Should this be considered a hack? If you have a nexus repository, for example, you couldn't realistically do that solution with existing jars. First, there are too many. Second, and more importantly, you wouldn't want to change the binaries to add module-info.class because it will change the

RFR 8161102: Regression test for JDK-8161101 (Recursive update error when a SecurityManager references a permission defined in a non-privileged module)

2016-07-10 Thread Wang Weijun
Hi All I filed a bug [1] on my recent finding [2] of a bug in SecurityManager. While I cannot find a fix, I'm able to provide a regression test, Therefore I created a sub-task [2] for the test. Please take a review at http://cr.openjdk.java.net/~weijun/8161102/webrev.00/ Whoever is able to

Re: Jlink and automatic module

2016-07-10 Thread Remi Forax
Hi Antoine, you were sleeping during my presentation at last Devoxx FR :) The issue is that an automatic jar can access to the classpath while a modular jar can not, so if jlink allows automatic modules, you may have surprising NoClassDefNotError at runtime ruining the whole idea of jigsaw. A

Jlink and automatic module

2016-07-10 Thread Antoine Sabot-Durand
Hi All, I encounter the same problem than Sander in [1] regarding automatic modules and Jlink. My project has a lot of modules and uses a lot of dependencies (Java EE spec and impls) so it took me a few days to walk thru the writing of all my module-info.java files. hopefully I only found 2

hg: jigsaw/jake/langtools: 14 new changesets

2016-07-10 Thread jan . lahoda
Changeset: d213ecfb98b2 Author:vromero Date: 2016-06-27 12:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d213ecfb98b2 8159439: javac throws NPE with Module attribute and super_class != 0 Reviewed-by: jjg !

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

2016-07-10 Thread Xavi MirĂ³ Guerrero
Hi, in my opinion, the problem here is that there are two types of use cases that need a different "default" behavior with respect to exporting packages in runtime and if we decide to use the current behavior, the use cases that need to export everything by default in runtime can lead to

A lot of questions around the configuration of a reflective style library

2016-07-10 Thread Jochen Theodorou
Hi, since Alan suggested to make a new thread for this (coming from "Feedback on proposal for #ReflectiveAccessToNonExportedTypes"), I will do just this. Let me rephrase the scenario from there a bit: I am trying to figure out the configuration and implications of the configuration and what

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

2016-07-10 Thread Alan Bateman
On 09/07/2016 12:22, Jochen Theodorou wrote: ok, let us assume I want to write a library that does what reflection can do today using bytecode generation. And let us assume I write a library, that will use this reflective module to call from private API to private API. How do we configure