Reusing module name token `*` in -d

Thu Jan 26 18:15:32 UTC 2017

On 1/26/17 6:30 AM, Nicolai Parlog wrote:
>   Hi,
>
> I see that this feature is unlikely to be in Java 9 ;) , but I want to
> give it one last push before conceding:
>
>> Comparing the two ways of compiling a set of modules ...
>>
>> Compiling modules one at a time (when that is possible) is the
>> smallest overall change for both the IDE and developer. Each module
>> can be compiled and built separately, and the resulting modules can
>> be put individually on the module path.
>>
>> Compiling modules together may yield a faster overall compilation
>> times, and the use of a single output directory makes it much
>> easier to set up the module path at runtime.
> Compiling all modules at once with a module name token in the path
> "may yield faster overall compilation times" and "the resulting
> modules can be put individually on the module path". Looks like a mix
> of characteristics that is otherwise not possible to achieve convenientl
> y.
>
>   so long ... Nicolai
That does not seem to be an obviously desirable combination.

Being able to compile a bunch of modules together, and put the resulting
single output directory on the module path would seem to be more
convenient and thus more desirable.

-- Jon

>
>
> On 25.01.2017 23:50, Jonathan Gibbons wrote:
>> Stephan,
>>
>> There will be many cases where one project contains one module and
>> for those cases, the single module mode compilation will be
>> sufficient and bears the most similarity to the way people
>> organize their project today.
>>
>> At the other end of the scale, there will be cases where a set of
>> closely-coupled modules have to be compiled together, and
>> multi-module mode was designed to address those cases. In this
>> situation, having the class files end up in a single directory
>> hierarchy organized by module should not be surprising.
>>
>> In between, there may be projects that contain a set of loosely
>> related modules, such that they can be compiled one module at a
>> time in a topologically sorted order. For these projects, it
>> becomes a design choice for the IDE vendor and/or a use choice for
>> the developer whether to use a series of compilations, one per
>> module, into distinct class output directories, or whether to
>> compile them all together, and have the classes written to a single
>> module-oriented output directory. Either way, the effective
>> compilation will be the same, and the same checks for strong
>> encapsulation should be in effect between the modules.
>>
>> (For your example of a set of separate projects, each with its own
>> sourcefolder and binfolder, I would expect each project to have
>> its own independent build "script", which each come down to one of
>> the three preceding cases.)
>>
>> Comparing the two ways of compiling a set of modules ...
>>
>> Compiling modules one at a time (when that is possible) is the
>> smallest overall change for both the IDE and developer. Each module
>> can be compiled and built separately, and the resulting modules can
>> be put individually on the module path.
>>
>> Compiling modules together may yield a faster overall compilation
>> times, and the use of a single output directory makes it much
>> easier to set up the module path at runtime.
>>
>> -- Jon
>>
>>
>> On 01/25/2017 12:05 PM, Stephan Herrmann wrote:
>>> 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 assume that the majority of source code out there is organized
>>> in some structure like Project1 + sourcefolder + binfolder
>>> Project2 + 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 ...). 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.
>>>
>>> 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?
>>>
>>> thanks, Stephan
>>>
>>> On 01/25/2017 07:38 PM, Jonathan Gibbons wrote:
>>>>
>>>> On 1/25/17 12:20 AM, Nicolai Parlog wrote:
>> 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:
>>>>>>> Nicolai,
>>>>>>>
>>>>>>> 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:
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> 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 `<whatever-was-given-to-d>/<module-name>`.
>>>>>>>>
>>>>>>>> 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
>>>>>>>> initial.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:
>> http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509
>>
>>   Web: http://codefx.org a blog about software development
>> https://www.sitepoint.com/java high-quality Java/JVM content
>> http://do-foss.de Free and Open Source Software for the City of
>> Dortmund
>>
>> Twitter: https://twitter.com/nipafx