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. 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
