AFAIK, the ijar (for "interface jar") is a standard JAR, with standard
*.class files *except* that the method bodies and private members have been
stripped out (and timestamps are normalized too). That way, if you change a
method implementation, or a private member (add/remove private field or
method, change private method signature, add/remove private inner class),
the resulting ijar won't change. Any *.java compiled against such a *.class
would produce the exact same *.class, so by checking the ijar checksum you
can determine whether a dependency has changed in a way that would require
recompiling the code. You'd however use the "normal" jar checksum to
determine whether to re-run tests (Maven unconditionally re-runs tests, but
neither Bazel nor Gradle, they avoid re-running them if the inputs haven't
changed), as implementation matters in determining the outcome (whether the
tests pass or fail).

On Wed, Oct 4, 2017 at 4:27 PM Russell Gold <russell.g...@oracle.com> wrote:

> Does this iJar have more information than a regular JAR? If not, what is
> the benefit? If so, where is this information coming from?
>
> The closest thing I can think of is the new Java 9 module system, which
> defines what is visible; presumably, that information would be useful in
> such a determination.
>
> > On Oct 4, 2017, at 12:38 AM, Farid Zakaria <farid.m.zaka...@gmail.com>
> wrote:
> >
> > I was combing through Bazel <https://bazel.build> (google's build tool)
> and
> > found a concept called iJar
> > <https://github.com/bazelbuild/bazel/tree/master/third_party/ijar>
> > iJar is basically a stripped out version of the Jar removing everything
> but
> > the public method signatures (very stripped out byte code jar).
> >
> > Their build tool uses iJars in determining if upstream dependencies can
> be
> > skipped to be rebuilt. The idea being: if the interface (iJar) of the
> > current project hasn't changed (SHA), there's no need to rebuild upstream
> > dependencies since any possible method they'd have used did not change.
> >
> > My guess is this would be a good way to speed up "-amd"
> > (also-make-dependents) by quickly stopping the build based on the iJar.
> >
> > Could this be done as a maven extension?
> >
> > Farid Zakaria
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Reply via email to