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
