Reusing module name token `*` in -d

[Jonathan Gibbons]

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:
>> 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
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCAAGBQJYiF/pAAoJEMo7rS6czNUJx9wP/338lKXahsdkn2x0I3BDRNFK
> t2IPuDTyFtzeEEuJjDkFVSIsGxfIWsZRtvUpZT23gZrOQikR+lqmdawYUmob+7pd
> ir+1MmxJjUWoVCxd/6n557gxtcCJxIcUUcTwMthRwepnZdEQBHfxgd1Qs6QPJlvK
> h87wvAubDjIn7ssm5PQnAB4i/kHbSBs8ZZFFcdzQpXPN/9dMMGwKliYXfYponzfo
> 79rQORyt5MBufj+ufPyzu7PixbfSXADqFOvofzSo793vE7jpPD0lfBOofeVIwoWq
> 0CK3FREapTDYiv3NNKtLt1no8/AGP5nTR//QmhAf2V+fmw0brVbmyBNKAfPqwQKN
> 3XCX+MfWaLBSonGMyvihXBlSiFT5feqsBPkBiRTMk7QI2eR3NADVvWCQwM8uvO+p
> Yul6XOqTKoFf3EWJDTyg3X5vRqcuX+n7utI9ii4Jw2R1fUmO1cYMk6jHP4pqmQ/t
> tgrEj0b8kqNKBLrWcndap76KgRIGBZRmmvZGe1EXqELt1x/72T/0PclfcuArHVjq
> nYJz/iranyR3s/MtAk50krvgSrGTcbjD+YCf6APNKW06vCvKX7PXUY+i2e5FCbNB
> zGka80aricdsmq5De9jF7+g7/mQWodO9lUlgur3Vh042Qe3DD8pwoLcrMLLm8mNQ
> fjldcnfa+hXTe+aongGg
> =H7sH
> -----END PGP SIGNATURE-----