With Zinc we can also compile Java classes, is it expected that the bytecode is fully compatible to the one a Java compiler produces?

[fmantz]

Hello,

I was doing some experiments with Apache Commons BCEL. I took an example program provided by the library that allows you to calculate the transitive hull of a class file. That means you can find classes that are "linked" to the class by type, e.g. by return type, parameter etc. I enhanced the example program to also find classes linked by local variables etc. Then I compiled the program with maven, mill and sbt. With maven I got the expected runtime results; but not with mill and sbt which both use zinc. My test you can find here:

https://github.com/fmantz/compare_mill_maven
(The type G of a local variable in my test case is not found by BCEL when compiled with zinc.)

I am not sure if this is a problem, or maybe a bug in BCEL, or maybe that BCEL cannot handle all valid variants of byte code.

Is this an issue?

[eed3si9n]

With Zinc we can also compile Java classes, is it expected that the bytecode is fully compatible to the one a Java compiler produces?

Yes. We expect Zinc to produce bytecode via the Java compiler. There are many projects, including sbt and Zinc itself that mixes both Java and Scala, and it will cause issue if Java somehow did not compile correctly. Having said that, there might still be some unexpected bugs that you may have discovered. But there might also be other subtle differences, like sbt uses Coursier to resolve version conflicts and download JARs. sbt also emulates test run in an isolated classloader instead of using a fresh JVM (forking didn't seem to solve your issue), etc.

[fmantz]

Thanks, for your reply. Library resolution and conflict resolution should not be the problem (I hope). The provided example is very basic and its not using many dependencies (apache.commons.bcel, apache.commons.lang3). BCEL is a library for analyzing, creating, and the manipulation of (binary) Java class files, therefore I was not sure if its really a compiler bug. Anyway, the code behaves different, depending on how I compile it, at least on my machines ;-). Since maven and sbt use the Java version set in my bash, this should also not be the difference.

[fmantz]

OK, I found the problem myself. Maven seems to use by default a compiler flag "-g", which sbt and mill does not automatically set. Adding the flag to the build.sbt makes the junit test run without error.

https://docs.oracle.com/en/java/javacard/3.1/guide/setting-java-compiler-options.html

[eed3si9n]

Interesting. Thanks for letting us know.