Reusing module name token `*` in -d

[Nicolai Parlog]

 Hi!

> 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".

And you can continue to do so unless you use a new feature. The lack
generality is maybe not beautiful but is that generality itself really
required? How many cases are there where code/scripts rely on the fact
that the same path can always be put into both places? (Honest
question, I have no clue what the answer might be.)

 so long ... Nicolai



On 25.01.2017 19:38, 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