same Java Classes compiled with maven and mill give different runtime result

[fmantz]

Hello,

lately I was playing around with Mill. My plan was to adapt the build process a bit. My idea: I wanted to limit the size of the output jar by filtering the class files needed by some classes only. Therefore, I inspected the bytecode of my class files with Apache Commons BCEL, a library I had never used before, but it seemed like a good fit to me.

Strangely, my first steps using BCEL were behaving differently when I compiled it with Mill or IntelliJ. Then I tried Maven, and Maven behaved the same way as IntelliJ. I tried it using different JDK versions (Temurin) and also on my Mac... same result. I'm not so sure if Mill has really something to do with that; it's not a compiler, but I find it strange anyway:

Here is my example setup using Java only:
https://github.com/fmantz/compare_mill_maven

Has anyone an idea, whats the problem?

[lefou]

Mill is using Zinc to compile Java code, by default. It should produce the same bytecode as if you would invoke the JDK compiler directly, but maybe, you found a bug?

As you didn't provide a description of the actual problem, I just assume you mean the failing test case TransitiveHullTest.getHull finding the unexpected class G. Since I'm not familiar with BCEL, I can't classify that issue.

[fmantz]

I tested it with sbt in the lunch break. The same "problem" appears when using sbt. So, I guess you are right. The Zinc compiler create a slightly different byte code that BCEL is not able to fully understand. If this is a "bug" in Zinc or in BCEL is a different question.

At least it is not a bug in mill :-).

[lefou]

In case this is a showstopper for someone, it should be straightforward (and transparent to the rest of the tool chain) to replace Zinc with directly using the JDK compiler. All that is needed it to override the compile task and use the JDK compiler directly. This can be done in user projects directly, via a plugin or in Mill. For the latter, we need some feedback telling us why this is needed.

[fmantz]

I do not think that this is needed, thanks. It may be an option to opt it in for Java modules to have full byte compatibility but I guess this is required in rare cases only. In this case someone could simply override compile as you proposed.

[lefou]

You may still want to open an issue to zinc (or sbt), since this may be a bug or some not anticipated side-effect. Raising awareness is probably the best way to fix this issue in the long term.

[fmantz]

Yes, I will address the issue somewhere. If I de-compile the class files with Intellij the result looks okay. It could be that the byte codes are equivalent but BCEL is only aware of a "standard representation".