Bikeshed: JDK 9 is supposed to be feature complete 5/26/16 and be RC by next January. Is this really enough time for EE Application Server projects and other tools like Maven to vet the capabilities?
Cheers, Paul On Tue, Mar 8, 2016 at 4:08 PM, David M. Lloyd <david.ll...@redhat.com> wrote: > The only rational solution to this problem is to completely forego the > JDK's capabilities and generate the file exclusively from the build > tooling. I expect that at some point we'll end up with a series of tools > which construct the exports list from annotated package-infos, the requires > list from a mapping or static list in the build, and a bunch of build- and > application-system specific miscellany besides. I don't believe that any > nontrivial program is likely to bundle a module-info.java source file all, > which makes me wonder if there's actually a point to having support for it > at all. Why write it when you can generate it, and at the same time, keep > all your build-related information in one spot? > > > On 03/08/2016 02:06 PM, Paul Benedict wrote: > >> Robert, it's sounds like a chicken-and-egg problem. You need the module >> name to compile but don't know it until you have compiled. >> >> Too bad this file isn't XML so that any tool could read the module >> information outside of compiling. That's what I advocated for a long time >> but that battle has been lost. >> >> >> >> Cheers, >> Paul >> >> On Tue, Mar 8, 2016 at 1:36 PM, Robert Scholte <rfscho...@apache.org> >> wrote: >> >> On Mon, 07 Mar 2016 14:53:28 +0100, Sander Mak <sander....@luminis.eu> >>> wrote: >>> >>> >>> I don't think I understand the issue here. Using -Xpatch doesn't change >>>> >>>>> the module declaration or export. It can be used to override or >>>>> augment the >>>>> module content, it just can't override the module declaration. It can >>>>> be >>>>> used in conjunction with -XaddReads and -XaddExports to read additional >>>>> modules or export additional packages. For example, if a patch adds >>>>> types >>>>> to a new package then you could export that package with -XaddExports. >>>>> If >>>>> the patch injects tests into an existing package then those tests might >>>>> have new dependences and requires compiling or running with >>>>> -XaddReads:$MODULE=junit for example. >>>>> >>>>> >>>> I was playing around with exactly this yesterday, and this is what I >>>> ended up with: >>>> >>>> javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \ >>>> >>>> >>>> -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit >>>> \ >>>> -mp mods:lib-test \ >>>> -d >>>> mods-test/javamodularity.easytext.algorithm.naivesyllablecounter >>>> $(find src-test -name '*.java') >>>> >>>> java -Xpatch:mods-test \ >>>> >>>> >>>> -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit >>>> \ >>>> >>>> >>>> -XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit >>>> \ >>>> -mp mods:lib-test \ >>>> -addmods >>>> javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \ >>>> -m org.junit/org.junit.runner.JUnitCore >>>> >>>> javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest >>>> >>>> Which patches my application module to contain a unit test, and then >>>> exposes my application module to junit at runtime (which is used as >>>> automatic module here). This works as expected. >>>> >>>> >>>> -- Sander >>>> >>>> >>> When translating this to Maven it assumes that Maven is aware of the >>> module name of the project is it building. >>> Up until now that's not true. Developers specify the moduleName in the >>> module-info.java and it doesn't make sense to ask them to add the same >>> modulename to the pom (it that was possible) or the maven-compiler-plugin >>> configuration. Instead Maven could use some new java9 APIs to discover >>> the >>> moduleName, but that would imply that from now on maven-compiler-plugin >>> requires Java9 runtime. I don't think that's the way we want to go right >>> now. Several Maven plugins have their own kind of multi-release pattern >>> where some codeblocks depend on a specific Maven version, but we really >>> want to avoid this. >>> I hope we can find a way where Maven can simply refer to the >>> classes-directory or the jar for some java/javac arguments where one >>> would >>> now need to be aware of its module name. >>> From Mavens point of view the output directories are facts, dependencies >>> from the pom.xml too, as is the packaged artifact name & location, the >>> content of java files are a mystery and not of any interest (at least in >>> a >>> classpath world ;) ). >>> >>> thanks, >>> Robert >>> >>> > -- > - DML >
