Creating modules with JDK8

[Cédric Champeau]

2015-11-29 21:26 GMT+01:00 Simon Ochsenreither <simon at ochsenreither.de>:

> Hi,
>
> > All told, it could complicates the build a bit and this is
> > where good tooling could help a lot.
>
> is there anything planned in this direction yet? Because the rest of the
> JVM ecosystem seems to remain largely apathetic towards it.
>
>
Not all the JVM ecosystem is apathic about this. Gradle already
demonstrated support for building for Jigsaw during JavaOne,
with our software model. It's still under heavy development but we plan to
have something testable for general public by early
next year (it is already testable by "power users"). Basically you can
already have build scripts that contain configuration like this:


model {
    myLib(JvmLibrarySpec) {
         targetPlatform 'java8'
         targetPlatform 'java9'
         api {
            exports 'com.acme.mylib.util'
            exports 'com.acme.mylib.client'
         }
    }
}

And we're building the Java 8 and Java 9 versions separately for this
specification. By separately, we mean that it's really 2 different jars.
Also this modelling allows us
to check *at compile time* today if a dependent component makes use of
non-exported (internal) APIs, and this works for pre-Jigsaw platforms. We
want to get away
from the traditional "Maven" way of things which is not good enough for
what we want to do, and doesn't scale to real industrial challenges. In
particular, we
want to express that the dependencies for a platform (Java 8) are different
from the dependencies for a different platform (Java 9). As well, runtime
dependencies
are very different from compile time dependencies. Depending on your target
deployment environment, you would want to express different dependencies
(targetting
WildFly is not the same as targetting Tomcat, but one model can describe
both). This also means that while for us it is pretty easy to support
"multi-version jars", this
is definitely not something we will ever recommend to do, because it's a
very weak model. It doesn't allow you to have different dependencies for
the same library. We
think that support for this problem of separating the runtime from the
compile process is something that the build tools have to deal with, not
the JVM. So because
we're a generic build tool we will support multi-version jars, but not by
default.

Eventually, I would also not recommend to put a module-info class (jdk 9
format) into a jar built for java 8. Just because there are tons of changes
that it will blow up
at runtime for legacy applications that use classpath scanning, and will
fail when they see an unrecognized class format.

I won't want to dig more into the details here, but no, the JVM world is
not apathic about this, it's not just Maven and Ivy.


> A small list of issues which remain to be tackled:
>
> - No usable separation between runtime of the build tool and runtime of
> the code to be compiled. (You can do it, but it's annoying and hard to
> setup.)
> - No support for runtime versioning in Maven/Ivy. (Currently people seem
> to use horrible hacks like using one major version for e.g. Java 6, and
> another major version with Java 8), meaning it is completely impossible
> to specify currently "I want to have versions of my dependencies that
> run on JDK X".
> - Versioning/artifact structure differences between major tools like
> Maven and Ivy cause a lot of unnecessary churn and complexity.
> - JDK artifacts are not available through dependency resolution tools,
> meaning installing the JVM/JDK is a separate step which needs to be
> handled outside of the usual build tools. (Which in turn makes
> reproducible builds across different machines annoying.)
> - No small enough _supported_ JVM runtime which could be bundled with
> build tools, meaning the setup is yet-another step beginners have to
> deal with.
> - The two things above combined mean that it's currently not possible to
> have a build tool which can bootstrap itself properly.
>
> While I understand that Oracle doesn't make money with developer
> happiness or ease-of-use it holds some of the important keys to
> improvements in its hand.
>
> > As you bring up JMOD files then it's just an alternative packaging
> > format. At this time then it's mostly for modules that are intended to
> > be linked into a run-time image (meaning a JRE, JDK or custom run-time)
> > - it isn't currently an execution format. I could imagine Maven plugins
> > supporting it as a new artifact type in the future.
>
> How would we read these files when running on earlier JDK versions?
>
> Thanks,
>
> Simon
>
>