Stub code attribute in ijar instead of deleting it

[AlessandroPatti]

Ijar simply drops the body of all public methods. However this might generate classes that are considered invalid per JVM specs. Tools that try and inspect the jar, might fail because of that. Instead of dropping the code, we can replace it with a fixed one. Particularly, throwing an unchecked exception is a valid code for all method signatures, so we just sub all code attributes with throw new java.jang.UnsupportedOperationException(). We have been using this internally for a long time, it fixes #13546

[fmeum]

@cushon

[AlessandroPatti]

@cushon @meteorcloudy @fmeum thoughts on this one?

[fmeum]

I support the idea of valid code attributes as it resolves a class of mysterious issues that are exclusive to Bazel. I remember @cushon thinking about the shortest valid code attributes for each method type.

Cc @hvadehra

[cushon]

Is the tool here that's trying to load the jars sbt like in #13546, or something else?

I support the idea of valid code attributes as it resolves a class of mysterious issues that are exclusive to Bazel.

I think that's a pragmatic way to look at it, but also compile-time jars are only intended to be used at compile-time and not loaded and executed, and it would be nice to avoid the additional logic in ijar and additional data in the compile-time jars that will never be used if they're being used as intended.

I remember @cushon thinking about the shortest valid code attributes for each method type.

Maybe #13546 (comment) ?

[AlessandroPatti]

Is the tool here that's trying to load the jars sbt like in #13546, or something else?

Yes, it is sbt, or better zinc, the incremental compiler used by sbt.

I think that's a pragmatic way to look at it, but also compile-time jars are only intended to be used at compile-time and not loaded and executed, and it would be nice to avoid the additional logic in ijar and additional data in the compile-time jars that will never be used if they're being used as intended.

Agree, but these are indeed only being used at compile-time, it just happens that this specific compiler might decide to load the jar to do additional analysis to optmize compilation.

I remember @cushon thinking about the shortest valid code attributes for each method type.

Maybe #13546 (comment) ?

Yeah, that could also work. I briefly looked into doing something more specific for each return type but it significantly increased the complexity and throwing unchecked exception does that trick very easily and did not see any clear advantage other than saving a few bytes.

[AlessandroPatti]

@cushon ping on this one, can it be moved forward?

[AlessandroPatti]

@cushon @hvadehra gentle ping

[cushon]

it would be nice to avoid the additional logic in ijar and additional data in the compile-time jars that will never be used if they're being used as intended

For me, this is a higher priority than supporting ijars with sbt/zinc.

I recognize this is a source of friction that it would be nice to have a solution to.

@hvadehra thoughts on the priority for this for Bazel?

In theory we could make this configurable or make ijar extensible for use by Bazel, in practice there's some process and maintenance overhead with that. Maybe doing this unconditionally isn't so bad if a lot of ijars usage has shifted towards hjars.

[hvadehra]

@hvadehra thoughts on the priority for this for Bazel?

I don't have a good sense of much ijar usage there is. I don't think we're using it anywhere in rules_java by default other than for java_import. But it's possible users are disabling header compilation and relying on ijar instead.