Dual testing is a minimum. In practice, it depends on the kind of tests. Typically, before JDK 9 for unit tests you never needed a jar to execute unit tests. Maven happens to built it, but in practice a class directory + resources is enough (what Gradle does when it knows a jar is not required). For integration or functional tests, you need the jar though, which means there are more combinations to test (class directory, jar on classpath, jar on module path, different runtime, ...). This is not necessarily a problem, we have the tools to do this, but the setup might not be super convenient.
2018-03-26 23:57 GMT+02:00 Stephen Colebourne <scolebou...@joda.org>: > On 26 March 2018 at 19:08, <mark.reinh...@oracle.com> wrote: > > Stephen Colebourne's recent blog entry > > Thanks for the thoughtful reply, of which I agree with much of it. > > > Stephen's main complaint here is only about the need > > to test a library on both the class path and the module path if it's > > intended to work on Java 9 or later. With automated testing this > > shouldn't, in principle, be a huge burden, > > To a degree this depends on the size of your test suite. Some suites > are large, and running the entire suite twice in continuous > integration could be onerous. > > I think the main complaint however is more subtle than a need to test > twice. It is the need to test twice _forevermore_. > > ie. if this were just a transition phase, which would pass when Java > 11 is the baseline, the situation would be painful but manageable. But > as things stand, there is no future time when my module will be > guaranteed to be treated as a module. > > > Stephen closes with a specific suggestion: > > [snip] > > Yes, this would eliminate the need for dual testing, but only if you're > > willing to baseline to Java 11. > > And that is exactly the point. At some point, Java 11 will be the new > baseline. The trade-offs jigsaw chose for the Java 8 to 9 transition > will at some point not be the right ones for the long term. There has > to be a time when a library developer can rely on strong encapsulation > and when the class-path can't just be used to completely nullify > module-info.java. Otherwise, whats the point in modularisation? > > I'm arguing that it should be the module authors choice to apply the > tougher rules, but I'm very happy to hear other alternatives in the > problem-space. > > > There's also at least one improvement in the JDK worth > > considering, which a few of us have already discussed, namely a small > > enhancement to javac that would allow a single invocation to compile a > > module, in module mode [2], but target class files other than > > `module-info.class` to an earlier release [3]. > > +1 > > Stephen >
