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
