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
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
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:
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
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 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
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 classpath and the order of entries. With the order
of th
