On 12/3/2015 2:04 PM, Peter Levart wrote:
On 12/03/2015 08:46 PM, Alex Buckley wrote:
On 12/3/2015 10:04 AM, Peter Levart wrote:
Loosely related to this debate, I would like to ask what's the story
with modular jars that can run on JDK8 classpath and as modules on JDK9.
How is one supposed to create such jar file as it must have:
- classes compiled with JDK8 javac (or JDK9 javac with -source 8 -target
8 or -release 8)
- module-info.class which can only be produced with JDK9 javac, but not
with -source 8 -target 8 or -release 8
Is one expected to invoke javac twice, 1st for sources (excluding
module-info.java), 2nd just for module-info.java ?
Yes (or get your build tool to do it).
More generally, anyone creating a multi-release JAR file (you didn't
ask about them, and they are not necessary to achieve what you want
above, but I mention them for completeness) will invoke javac multiple
times. It's the cost of doing business.
Wouldn't it be nice
for jar tool to be able to fabricate the module-info.class from scratch
using just command-line options?
No. How does a Java compiler know what's exported from a module, in
order to enforce accessibility, if the module declaration isn't
fabricated until packaging time?
In this case (of building a modular jar file that is able to run on JDK8
classpath), classes are compiled with javac -release 8, which can't run
in "modular" mode and consequently can't enforce any accessibility. When
module-info.java is then compiled separately, there are no classes to be
compiled and so there's nothing to enforce accessibility on....
Sure, this special case of build-for-JDK-8-then-add-modular-info could
be solved by passing the modular info to the jar tool. But the modular
info is non-trivial -- a list of module dependencies plus a list of
exported packages -- so in practice you'd stick the info in an @argfile
and now you've reinvented module-info.java.
Alex
