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

Maven Extension Idea: iJar support

[Farid Zakaria]

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