See https://melix.github.io/javaone-2017-max-incremental/ for how Gradle
does it (and so it uses it not only for incremental compilation, but also
compilation avoidance).
Bazel's ijars are a similar mechanism to avoid unnecessary work.
On Wed, Oct 4, 2017 at 5:19 PM Thomas Broyer wrote:
> AFAIK,
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
meth
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
determinati
On Wed, Oct 4, 2017 at 6:38 AM, Farid Zakaria
> Could this be done as a maven extension?
What exactly would you like to have?
- Creating the "iJar" (Would need a specification first, IMO, which
might be obtained from Bazel.)
- Support for using the "iJar" in the dependency checking, as you
descr