On 01/12/2018 08:45, Christian Stein wrote:
Hi,
jar --create (and --update) perform type API validation checks when used in
combination with --release option. This detects invalid "version overlays"
at package time, where the API doesn't match a previous one.
Having a jar --verify mode that performs the same checks consuming an
already existing jar file would be useful as most "3rd-party packaging
tools" don't perform those checks.
A possible work-around could be to explode an existing jar and re-create it
using jar --create...
I think it would be useful to create a list of the popular tools and
plugins in the eco system that create or update JAR files and see what
their current capabilities are. The addition of modules and MR JARs have
extended the JAR format quite a bit in recent years and it's not clear
if the eco system has caught up, e.g. if I package a module as a modular
JAR with the `jar` tool then it will do the right thing and add/update
the ModulePackages class file attribute. It will also do check such as
ensuring that the JAR files contains the service provider that the
module claims to provide. MR JARs are more complicated, and modular MR
JARs more complicated again. Beyond the API validation check that you
are asking about, there is also checking that any module-info.class in
the versioned section match (API wise) the module-info in the base
section. So I agree there may be merit in a -verify like option with the
benefit that it helps identify where the build tools or plugins may not
be doing the right thing. There may also be merit is seeing if some of
these tools or plugins should move to using the jar tool, by way of
ToolProvider.findFirst("jar"), or having the jar tool introduce an API
(as the exit code and stdout/stderr output might not be sufficient for
tools that need fine control).
-Alan.
