Re: Maven Extension Idea: iJar support

[Thomas Broyer]

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, 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 
> 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 
>> wrote:
>> >
>> > I was combing through Bazel  (google's build
>> tool) and
>> > found a concept called 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
>>
>>

Re: Maven Extension Idea: iJar support

[Thomas Broyer]

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  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 
> wrote:
> >
> > I was combing through Bazel  (google's build tool)
> and
> > found a concept called 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
>
>

Re: Maven Extension Idea: iJar support

[Russell Gold]

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  wrote:
> 
> I was combing through Bazel  (google's build tool) and
> found a concept called 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

Re: Maven Extension Idea: iJar support

[Jochen Wiedmann]

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
described. (Sounds much more difficult, and most likely depends on the
former.)

Jochen



-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org