Maven Extension Idea: iJar support

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Maven Extension Idea: iJar support

Farid Zakaria
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
Reply | Threaded
Open this post in threaded view
|

Re: Maven Extension Idea: iJar support

jochen-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven Extension Idea: iJar support

Russell Gold-3
In reply to this post by Farid Zakaria
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven Extension Idea: iJar support

Thomas Broyer-2
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 <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven Extension Idea: iJar support

Thomas Broyer-2
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>