ijar should produce valid class files with code attributes #13546
Comments
|
I think this is a duplicate of #632 |
|
#632 is about preserving the code attributes for use in macros. This has nothing to do with macros and ijar should not preserve code in this case but generate stubs. |
comius
added
P4
|
I don't think it's a good idea to load ijar generated classes. Additionally such change would probably cause a regression - longer ijar class file. |
|
I don't see how this would cause a regression. Yes, the ijars would get bigger, but they would still be deterministic. |
The motivation behind ijar is to improve build performance, so having ijar do additional work and produce slightly larger outputs would have some small effect there, the idea is that it's a potential performance regression. Most compilers don't need to do regular classloading on the compile-time jars, or check that they have code attributes that verify. |
JVMS 4.7.3: "If the method is either native or abstract, its method_info structure must not have a Code attribute. Otherwise, its method_info structure must have exactly one Code attribute." As hack around this, we instead emit a (dummy) Code attribute that does not depend on the actual implementation of the method. This should fix compatibility with tools like https://spotbugs.github.io which seem to care about the Code attribute of dependencies and currently fail with ijar enabled. Since there are some performance concerns about emitting a code attribute at all, we start with only reading the Code attribute in this PR and add the code to emit the dummy attributes in a follow-up to make benchmarking easier. Progress on bazelbuild#13546
|
There's a related work-around for this in desugar: |
|
Thinking about this a little more, I wonder what the simplest code attributes we can get away with that would still verify are. For regular non- For constructors, I think we need to invoke super-constructors, which isn't trivial. Now we're looking at examining the existing code to minimize it, or understanding the class hierarchy. I think we don't need to worry about final fields if the constructor never completes normally. |
|
Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale. |
github-actions
bot
added
the
stale
Description of the problem / feature request:
ijar strips out all code attributes, thus producing invalid classfiles that cannot be loaded into the JVM. Instead of removing code attributes it should replace them with a dummy implementation that throws an Exception.
Feature requests: what underlying problem are you trying to solve with this feature?
Our Scala tooling uses Zinc which may load dependent classes from the compiler classpath into the JVM when analyzing classes produced by javac in mixed Scala/Java compilation. This fails because the classfiles produced by ijar do not pass classfile validation:
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Sorry, I don't have a reproduction that I can share. This is based on our internal Scala rules, currently running on our Fork of Bazel 3.2.0.
The text was updated successfully, but these errors were encountered: