Closed as not planned
Description
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:
java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file org/apache/spark/ml/linalg/VectorUDT
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.privateGetPublicMethods(Class.java:2902)
at java.lang.Class.getMethods(Class.java:1615)
at sbt.internal.inc.ClassToAPI$.toDefinitions0(ClassToAPI.scala:164)
at sbt.internal.inc.ClassToAPI$.$anonfun$toDefinitions$1(ClassToAPI.scala:121)
at scala.collection.mutable.HashMap.getOrElseUpdate(HashMap.scala:82)
at sbt.internal.inc.ClassToAPI$.toDefinitions(ClassToAPI.scala:121)
at sbt.internal.inc.ClassToAPI$.$anonfun$process$1(ClassToAPI.scala:28)
at scala.collection.mutable.ResizableArray.foreach(ResizableArray.scala:59)
at scala.collection.mutable.ResizableArray.foreach$(ResizableArray.scala:52)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
at sbt.internal.inc.ClassToAPI$.process(ClassToAPI.scala:28)
at sbt.internal.inc.javac.AnalyzingJavaCompiler.readAPI$1(AnalyzingJavaCompiler.scala:143)
at sbt.internal.inc.javac.AnalyzingJavaCompiler.$anonfun$compile$20(AnalyzingJavaCompiler.scala:161)
at sbt.internal.inc.classfile.Analyze$.readInheritanceDependencies$1(Analyze.scala:148)
at sbt.internal.inc.classfile.Analyze$.$anonfun$apply$14(Analyze.scala:154)
at sbt.internal.inc.classfile.Analyze$.$anonfun$apply$14$adapted(Analyze.scala:81)
at scala.collection.TraversableLike$WithFilter.$anonfun$foreach$1(TraversableLike.scala:789)
at scala.collection.mutable.HashMap.$anonfun$foreach$1(HashMap.scala:138)
at scala.collection.mutable.HashTable.foreachEntry(HashTable.scala:236)
at scala.collection.mutable.HashTable.foreachEntry$(HashTable.scala:229)
at scala.collection.mutable.HashMap.foreachEntry(HashMap.scala:40)
at scala.collection.mutable.HashMap.foreach(HashMap.scala:138)
at scala.collection.TraversableLike$WithFilter.foreach(TraversableLike.scala:788)
at sbt.internal.inc.classfile.Analyze$.apply(Analyze.scala:81)
at sbt.internal.inc.javac.AnalyzingJavaCompiler.$anonfun$compile$19(AnalyzingJavaCompiler.scala:161)
at sbt.internal.inc.javac.AnalyzingJavaCompiler.$anonfun$compile$19$adapted(AnalyzingJavaCompiler.scala:159)
at scala.collection.TraversableLike$WithFilter.$anonfun$foreach$1(TraversableLike.scala:789)
at scala.collection.immutable.List.foreach(List.scala:389)
at scala.collection.TraversableLike$WithFilter.foreach(TraversableLike.scala:788)
at sbt.internal.inc.javac.AnalyzingJavaCompiler.$anonfun$compile$17(AnalyzingJavaCompiler.scala:159)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:12)
at sbt.internal.inc.javac.AnalyzingJavaCompiler.timed(AnalyzingJavaCompiler.scala:196)
at sbt.internal.inc.javac.AnalyzingJavaCompiler.compile(AnalyzingJavaCompiler.scala:159)
at sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$4(MixedAnalyzingCompiler.scala:105)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:12)
at sbt.internal.inc.MixedAnalyzingCompiler.timed(MixedAnalyzingCompiler.scala:133)
at sbt.internal.inc.MixedAnalyzingCompiler.compileJava$1(MixedAnalyzingCompiler.scala:90)
at sbt.internal.inc.MixedAnalyzingCompiler.compile(MixedAnalyzingCompiler.scala:116)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1(IncrementalCompilerImpl.scala:307)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1$adapted(IncrementalCompilerImpl.scala:307)
at sbt.internal.inc.Incremental$.doCompile(Incremental.scala:106)
at sbt.internal.inc.Incremental$.$anonfun$compile$4(Incremental.scala:87)
at sbt.internal.inc.IncrementalCommon.recompileClasses(IncrementalCommon.scala:116)
at sbt.internal.inc.IncrementalCommon.cycle(IncrementalCommon.scala:63)
at sbt.internal.inc.Incremental$.$anonfun$compile$3(Incremental.scala:89)
at sbt.internal.inc.Incremental$.manageClassfiles(Incremental.scala:134)
at sbt.internal.inc.Incremental$.compile(Incremental.scala:80)
at sbt.internal.inc.IncrementalCompile$.apply(Compile.scala:67)
at sbt.internal.inc.IncrementalCompilerImpl.compileInternal(IncrementalCompilerImpl.scala:311)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileIncrementally$1(IncrementalCompilerImpl.scala:269)
at sbt.internal.inc.IncrementalCompilerImpl.handleCompilationError(IncrementalCompilerImpl.scala:159)
at sbt.internal.inc.IncrementalCompilerImpl.compileIncrementally(IncrementalCompilerImpl.scala:238)
at sbt.internal.inc.IncrementalCompilerImpl.compile(IncrementalCompilerImpl.scala:69)
...
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.
Activity