Closed jesse-gallagher closed 5 years ago
This is actually a bit different from an earlier error, so it's possible that some unrelated change in the project has either improved or worsened MoE's handling.
The next trouble has to do with Proguard not finding all the classes it needs, ending with messages like
java.lang.IllegalArgumentException: Can't find common super class of [java/lang/String] (with 2 known super classes) and [com/ibm/rmi/channel/orb/ORBServerChannel] (with 1 known super classes)
at proguard.evaluation.value.TypedReferenceValue.findCommonClass(TypedReferenceValue.java:443)
at proguard.evaluation.value.TypedReferenceValue.generalize(TypedReferenceValue.java:277)
at proguard.evaluation.value.TypedReferenceValue.generalize(TypedReferenceValue.java:201)
at proguard.evaluation.value.ReferenceValue.generalize(ReferenceValue.java:298)
at proguard.evaluation.Stack.generalize(Stack.java:143)
at proguard.evaluation.TracedStack.generalize(TracedStack.java:149)
at proguard.optimize.evaluation.PartialEvaluator.evaluateSingleInstructionBlock(PartialEvaluator.java:691)
at proguard.optimize.evaluation.PartialEvaluator.evaluateInstructionBlock(PartialEvaluator.java:609)
at proguard.optimize.evaluation.PartialEvaluator.evaluateInstructionBlockAndExceptionHandlers(PartialEvaluator.java:567)
at proguard.optimize.evaluation.PartialEvaluator.visitCodeAttribute0(PartialEvaluator.java:271)
at proguard.optimize.evaluation.PartialEvaluator.visitCodeAttribute(PartialEvaluator.java:188)
at proguard.optimize.evaluation.LivenessAnalyzer.visitCodeAttribute(LivenessAnalyzer.java:205)
at proguard.preverify.CodePreverifier.visitCodeAttribute0(CodePreverifier.java:109)
at proguard.preverify.CodePreverifier.visitCodeAttribute(CodePreverifier.java:82)
at proguard.classfile.attribute.CodeAttribute.accept(CodeAttribute.java:101)
at proguard.classfile.ProgramMethod.attributesAccept(ProgramMethod.java:81)
at proguard.classfile.attribute.visitor.AllAttributeVisitor.visitProgramMember(AllAttributeVisitor.java:95)
at proguard.classfile.util.SimplifiedVisitor.visitProgramMethod(SimplifiedVisitor.java:92)
at proguard.classfile.ProgramMethod.accept(ProgramMethod.java:73)
at proguard.classfile.ProgramClass.methodsAccept(ProgramClass.java:522)
at proguard.classfile.visitor.AllMethodVisitor.visitProgramClass(AllMethodVisitor.java:47)
at proguard.classfile.visitor.ClassVersionFilter.visitProgramClass(ClassVersionFilter.java:76)
at proguard.classfile.ProgramClass.accept(ProgramClass.java:364)
at proguard.classfile.ClassPool.classesAccept(ClassPool.java:124)
at proguard.preverify.Preverifier.execute(Preverifier.java:60)
at proguard.ProGuard.preverify(ProGuard.java:403)
at proguard.ProGuard.execute(ProGuard.java:162)
at proguard.ProGuard.main(ProGuard.java:538)
This is something of a rabbit hole, as those classes are present in a J9 JRE but not generally.
I'm not sure, though, why iOS is having this trouble when Android didn't.
The general problem is the second pass that MOE does after creating the Android-type dex - presumably, since it compiles all the classes, it's extremely strict about having all classes/methods available, which Android doesn't care so much about. This leads to trouble with deep dependencies.
The problems creep in during a late MoE compilation phase: