On 14/10/2016 23:26, Alexandre (Shura) Iline wrote:
Could you please take another look?
I have added more options, and fixed other things you have pointed out. I have
also picked up a couple more tests to cover the newly added methods.
http://cr.openjdk.java.net/~shurailine/8159523/webrev.02/
Hi Robert,
On 10/16/2016 08:52 PM, Robert Scholte wrote:
Hi,
with the introduction of the module-info something interesting is
happening. Up until now the scope of a Java project was limited to the
compilation of the classes. In case of Maven the end-user was in full
control regarding the c
On 16/10/16 19:52, Robert Scholte wrote:
> To enforce the discipline, the java compiler should IMHO at least
> check if all required modules are indeed required and if the
> transitive required modules are indeed transitive.
How can the compiler possibly know this? There are ways of requiring
a
On 17/10/2016 08:32, Peter Levart wrote:
:
Do we need an --exclude-modules (in addition to --add-modules) option
on javac, java and jlink commands?
--exclude-modules would be different to --limit-modules. If some
module requires module M and there is no module M on the module path
or it is
The compiler can not detect dead code because it can be a library.
jlink can detect dead code and provide a list of unneeded modules because it
has the view of the whole application.
RĂ©mi
On October 17, 2016 10:45:26 AM GMT+02:00, Andrew Haley wrote:
>On 16/10/16 19:52, Robert Scholte wrote:
Alan, Tom,
On 13/10/16 19:59, Alan Bateman wrote:
..
Speaking of net-dev, then maybe this thread should move there as this
topic is really more of a URL issue rather than module system issue.
I have replied to this over on net-dev [1] ( I hope that is ok ).
We can continue the discussion ther
Please review http://cr.openjdk.java.net/~sundar/8168091/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8168091
Thanks,
-Sundar
+1
> On Oct 17, 2016, at 2:23 PM, Sundararajan Athijegannathan
> wrote:
>
> Please review http://cr.openjdk.java.net/~sundar/8168091/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8168091
>
> Thanks,
>
> -Sundar
>
I didn't had dead code in mind. And as Remi explained it cannot be
detected on a jar-base, only on an application base. (which reminds me
that we also need to have a look at the minimizeJar option of the
maven-shade-plugin).
My idea was more about collecting all classes required to compile th
Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8167558/webrev.01/
This updates the exclude-jmod-section plugin not to filter specific modules.
Also clean up DefaultImageBuilder further and improve the exception message
when it detects duplicated resource entries.
Mandy
> On
On Mon, 17 Oct 2016 12:59:25 +0200, Alan Bateman
wrote:
On 17/10/2016 08:32, Peter Levart wrote:
:
Do we need an --exclude-modules (in addition to --add-modules) option
on javac, java and jlink commands?
--exclude-modules would be different to --limit-modules. If some module
requires
> On Oct 17, 2016, at 10:23 AM, Sundararajan Athijegannathan
> wrote:
>
> Please review http://cr.openjdk.java.net/~sundar/8168091/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8168091
The shell test can be removed and use
@run main/othervm/secure=java.lang.SecurityManager
You
Hi,
Thanks for your review. I've updated webrev with jdk.tools.jlink ->
jdk.tools.jlink.internal refactoring. But, when I attempted to get rid
of shell script in the test with your suggestion, I got:
Exception in thread "main" java.security.AccessControlException: access denied
("java.io.Fil
13 matches
Mail list logo