Reusing module name token `*` in -d
forax at univ-mlv.fr
Wed Jan 25 21:29:01 UTC 2017
----- Mail original -----
> De: "Stephan Herrmann" <stephan.herrmann at berlin.de>
> À: jigsaw-dev at openjdk.java.net
> Envoyé: Mercredi 25 Janvier 2017 21:05:21
> Objet: Re: Reusing module name token `*` in -d
> I found the general direction of this proposal interesting,
> but from the reluctance to accept this, I start to think,
> that maybe the role of multi-module compilation was overrated?
i don't think it is (overrated),
at the same time i think we all know that this required IDEs to change the way they represent a Java application which is not something easy
(the fact that a module can be in the classpath or in the modulepath is also a big change).
> I assume that the majority of source code out there is organized
> in some structure like
> + sourcefolder
> + binfolder
> + sourcefolder
> + binfolder
> Note there is nothing outside of projects.
> I don't believe this is going to change any time soon.
> Tools know how to find .class files in this structure.
> When projects become modules, at first look it sounds compelling to
> perform a multi-module compilation on several projects in one invocation.
> (Compelling for reasons of "simplicity" as well as performance ...).
Simplicity is a big reason !
Being able to develop an EE application into one project is something which is requested by my students every years, the argument to not do that is that you want to catch wrong dependencies,
(dependency between packages that lead to NoClassDefFoundError at runtime).
Given that the module-info solves that issue, introducing a simpler way to develop Java applications at the expense of IDEs/build tool having to be upgraded seems to good deal for me.
The other thing is that if you starts to use services (provides/uses), the fact that you deploy a service implementations as a module will create more smaller modules than currently.
By example, the JDK 9 comes with a system logger API  which is only one abstract class to implement.
> If scattering .class files into unrelated binfolders is not intended,
> this seems to suggest to forget about multi-module compilation,
> and keep compiling one project/module at a time, where we can specify
> individual output folders.
Putting several bin folders each containing one (exploded) module in the module path has not the same semantics as having one bin folder containing several (exploded) modules,
for the former, the first module with the right name will be choosen for the later, you can not have several modules with the same name.
As Jon already said, having all your exploded modules in one bin folder makes things very easy to test without having to package them into a jar.
> Is that the message?
> Maybe, at the end of the pipeline there will be one use case where
> multi-module compilation will indeed collect "everything" into one
> global bin folder, ready for packaging and shipping, but that would be
> the least frequently performed use case, and then it's much easier
> to just copy / merge (or link) the individual binfolders into one.
> Any positive reasons to consider multi-module builds after all?
> On 01/25/2017 07:38 PM, Jonathan Gibbons wrote:
>> On 1/25/17 12:20 AM, Nicolai Parlog wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>> Hi Jonathan,
>>> thanks for considering this.
>>>> If nothing else, it would require all the module-specific output
>>>> directories to be created ahead of time, so that javac can
>>>> determine which ones to use
>>> Why would that be the case? It is not necessary to create them now so
>>> why would using asterisk change that?
>> OK, I missed that you were not suggesting to adopt all of the functionality
>> of module source path, including the ability to specify a path of output
>> locations, so that module classes could be written into a directory that is
>> more closely associated with the source code.
>>>> It has always been the case that a single compilation for
>>>> different packages from different libraries would result in the
>>>> classes being placed in a single output directory hierarchy, and
>>>> that the classes could then be selectively packaged into different
>>>> files like .jar files.
>>> It has also always been the case that the compiler had no notion of
>>> projects/artifacts/modules but just of plain source files. ;) That
>>> changed, too, so why not do the same for class files?
>>>> If you're compiling modules together, why could you not do
>>>> something similar?
>>> I have no particular use case (except writing some demos) but I would
>>> guess that it would make it more comfortable for existing tools to
>>> move towards multi-module compilation.
>> I don't see any reason why the current design would make it harder
>> for tools to move towards multi-module compilation.
>>> I also like this idea for its symmetry. You can define input the
>>> compilers input, sorted by modules, with *, so why not do the same for
>>> its output? Conceptually that should be obvious (which does not mean
>>> that there are not plenty if reasons against it).
>> There is a much stronger, more compelling relationship in play.
>> The current -d option is designed so that you can put the output
>> directory on the class path or module path as appropriate. That's
>> always been the case for the classpath -- even though source
>> may come from a variety of directory hierarchies, the compiled
>> classes are put into a simple directory hierarchy that can be put
>> on the classpath. Now, with modules, that continues to be the case:
>> you can put the -d output directory on the runtime module path,
>> either as a single "exploded module" or as a directory of "exploded
>> modules". That is a compelling argument in favor of the current
>> design of the javac output directory.
>> In contrast, I don't see any compelling advantage to allowing
>> -d "./*/target/classes"
>> since that would make it significantly harder to place such a
>> directory on the runtime module path.
>> -- Jon
>>> so long ... Nicolai
>>> On 23.01.2017 20:51, Jonathan Gibbons wrote:
>>>> I don't think this proposal is a good way to go. If nothing else,
>>>> it would require all the module-specific output directories to be
>>>> created ahead of time, so that javac can determine which ones to
>>>> use, which would require additional setup commands to be executed
>>>> after a "make clean" or its equivalent in other build systems.
>>>> Also, I note that the output directory is typically never the
>>>> final location for the compiled classes; it is typically just a
>>>> "staging area". It has always been the case that a single
>>>> compilation for different packages from different libraries would
>>>> result in the classes being placed in a single output directory
>>>> hierarchy, and that the classes could then be selectively packaged
>>>> into different files like .jar files. If you're compiling modules
>>>> together, why could you not do something similar?
>>>> -- Jon
>>>> On 01/21/2017 02:00 AM, Nicolai Parlog wrote:
>>>>> Another feature request from the trenches regarding multi-module
>>>>> compilation. (It is possible that there was a similar thread a
>>>>> couple of days/weeks (?) back but I didn't find it.)
>>>>> It would be nice to have the ability to specify module specific
>>>>> target folders, so they do not automatically end up in
>>>>> It seems obvious (which could very well make it stupid) to reuse
>>>>> the asterisk here and allow something like
>>>>> javac --module-path mods --module-source-path
>>>>> "./*/src/main/java" -d "./*/target/classes" -module
>>>>> I have not thought through how this might or might not work with
>>>>> multiple module source paths. It looks like the only tractable
>>>>> approach would be to not allow more than one -d element.
>>>>> so long ... Nicolai
>>> - --
>>> PGP Key:
>>> a blog about software development
>>> high-quality Java/JVM content
>>> Free and Open Source Software for the City of Dortmund
>>> -----BEGIN PGP SIGNATURE-----
>>> -----END PGP SIGNATURE-----
More information about the jigsaw-dev