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