Provide associate jars when compile java sources in _run_kt_java_builder_actions#1468
Conversation
fredm-spotify
requested review from
Bencodes,
ahumesky,
cgruber,
nkoroste and
restingbull
as code owners
| source_jars = generated_kapt_src_jars + srcs.src_jars + generated_ksp_src_jars, | ||
| output = ctx.actions.declare_file(ctx.label.name + "-java.jar"), | ||
| deps = compile_deps.deps + kt_stubs_for_java + [p[JavaInfo] for p in ctx.attr.plugins if JavaInfo in p], | ||
| deps = compile_deps.deps + kt_stubs_for_java + [p[JavaInfo] for p in ctx.attr.plugins if JavaInfo in p] + associate_java_infos, |
There was a problem hiding this comment.
Hm. If I'm not wrong, this undoes the advantages of the ABI jars for associates.
There was a problem hiding this comment.
oh no! My thinking is that since it's associated I should be able to access the internal symbols as a dependency to the compile task.
And I thought that whatever goes in deps doesn't end up in the final jar which would keep the internal symbols not-exposed.
There was a problem hiding this comment.
i guess we could flag this change behind the pair of experimental_treat_internal_as_private_in_abi_jars, experimental_remove_private_classes_in_abi_jars flags, but this concept (a modules java code should have access to its associates internals) is whats for discussion in #1467
There was a problem hiding this comment.
Inputs are part of the cache key, so changes would invalidate on any associate change. It's not a whole tree invalidation (just immediate downstream actions), but it will have an impact.
I suspect we'd really want to extend abi here -- a change to a private field shouldn't invalidate. Hm.
There was a problem hiding this comment.
Ok, one thing I'm not sure I follow. Let me come up with a specific example. I've hit this issue when I was compiling dagger in a bazel target called wiring which was associated with the target that had the implementation - impl.
The way I understand this, is that the dagger generated code placed in wiring might reference internal symbols from impl. shouldn't, in theory, a change to the internal code from impl actually invalidate the build from wiring?
There was a problem hiding this comment.
sounds good! thank you
There was a problem hiding this comment.
hmmm, so i have tried this out... assuming i could use the skip code gen plugin to avoid a full recompilation for the associates-abi.jar. Looks like that plugin is only good for k1 and i couldnt see any low risk options for having something similar for k2. So I could either do a full compilation and discard the output class jar in order to get an associates-abi.jar or maybe there is some jar processing that could be done to get something that would work, but that dosnt sound too great either
There was a problem hiding this comment.
the other thing im trying is to actually use the abigen plugin twice, one with the flags to produce a public only abi jar and the other to make the "associates abi jar" (containing the internal symbols). Given you cant register the plugin twice im trying a thin wrapper that registers it under a different ID in order to configure it differently
There was a problem hiding this comment.
WDYT of #1479 as a starter for ten @restingbull
you might want a cup of tea and a biscuit to take you through it
There was a problem hiding this comment.
@restingbull I'm closing this PR. I understand now that the jar I'm providing also include private symbols that once changed shouldn't invalidate the cache.
I've also gave a go at @rbeazleyspot's solution and it works within the Spotify project. I think we would prefer to go with his approach. Thanks for all the help!
3 participants
This attempts to fix an issue when Kapt generates Java code that requires access to internal classes that are stripped from ABI jars. @rbeazleyspot has opened an issue #1467 with much more detail and another approach at fixing it. This is a simpler way to go about it and we wanted your advice on these.
When
experimental_remove_private_classes_in_abi_jarsis enabledassociate[JavaInfo].compile_jarsdoesn't contain internal symbols. However, Kapt might generate code that requires access to these. An example is the Dagger generated code.If a target
Bassociates with a targetAandBis generating Dagger code, the call tojava_common.compilein_run_kt_java_builder_actionsdoesn't seem to have access to the internal symbols from the associates array. Hence, compilation of the Java code fails.