AssertionError from fjbg only when java '-ea' option is set

111 views
Skip to first unread message

Johannes Rudolph

unread,
Jun 1, 2012, 9:56:41 AM6/1/12
to scala-l...@googlegroups.com
Anyone has seen this one [1]:

java.lang.AssertionError: javax/mail/Message$RecipientType already
declared as ch.epfl.lamp.fjbg.JInnerClassesAttribute$Entry@5de9445c
at ch.epfl.lamp.fjbg.JInnerClassesAttribute.addEntry(JInnerClassesAttribute.java:74)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator$$anonfun$addInnerClasses$3.apply(GenJVM.scala:738)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator$$anonfun$addInnerClasses$3.apply(GenJVM.scala:733)
at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59)
at scala.collection.immutable.List.foreach(List.scala:76)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.addInnerClasses(GenJVM.scala:733)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.emitClass(GenJVM.scala:200)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.genClass(GenJVM.scala:355)
at scala.tools.nsc.backend.jvm.GenJVM$JvmPhase$$anonfun$run$4.apply(GenJVM.scala:86)
at scala.tools.nsc.backend.jvm.GenJVM$JvmPhase$$anonfun$run$4.apply(GenJVM.scala:86)
at scala.collection.mutable.HashMap$$anon$2$$anonfun$foreach$3.apply(HashMap.scala:104)
at scala.collection.mutable.HashMap$$anon$2$$anonfun$foreach$3.apply(HashMap.scala:104)
at scala.collection.Iterator$class.foreach(Iterator.scala:772)
at scala.collection.mutable.HashTable$$anon$1.foreach(HashTable.scala:157)
at scala.collection.mutable.HashTable$class.foreachEntry(HashTable.scala:190)
at scala.collection.mutable.HashMap.foreachEntry(HashMap.scala:45)
at scala.collection.mutable.HashMap$$anon$2.foreach(HashMap.scala:104)
at scala.tools.nsc.backend.jvm.GenJVM$JvmPhase.run(GenJVM.scala:86)
at scala.tools.nsc.Global$Run.compileSources(Global.scala:953)
at scala.tools.nsc.Global$Run.compile(Global.scala:1041)
at xsbt.CompilerInterface.run(CompilerInterface.scala:87)

I can't post the source code nor do I know where it exactly comes
from. Do you think that's rather an fjbg bug or a scalac bug when
generating InnerClass attributes which is only revealed by fjbg when
assertions are enabled? If you think it's worthwhile I can try to
minimize it.

--
Johannes

[1] There's some mentioning of something similar in this old (closed)
ticket: https://issues.scala-lang.org/browse/SI-1232

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

Paul Phillips

unread,
Jun 1, 2012, 9:59:50 AM6/1/12
to scala-l...@googlegroups.com


On Fri, Jun 1, 2012 at 6:56 AM, Johannes Rudolph <johannes...@googlemail.com> wrote:
I can't post the source code nor do I know where it exactly comes
from. Do you think that's rather an fjbg bug or a scalac bug when
generating InnerClass attributes which is only revealed by fjbg when
assertions are enabled? If you think it's worthwhile I can try to
minimize it.

You could implicate or absolve fjbg by trying the asm backend.

-target:jvm-1.6

Johannes Rudolph

unread,
Jun 1, 2012, 10:48:44 AM6/1/12
to scala-l...@googlegroups.com
This is enough to trigger the bug:

println(javax.mail.Message.RecipientType.TO)

Interestingly it appears to be a regression from 2.9.1. It happens in
2.9.2 and 2.10.0-M3. I'll file a bug and maybe try the asm backend as
well.
--
Johannes

Diogo Ferreira

unread,
Jul 18, 2012, 5:38:07 AM7/18/12
to scala-l...@googlegroups.com
Did you ever get past this? I'm hitting the same problem with a project that's running just fine with 2.9.1. Unfortunately we heavily depend on assertions for testing one of the components, but everything bar that works just fine, as long as assertions are disabled.

Diogo

Diogo Ferreira

unread,
Jul 18, 2012, 7:06:57 AM7/18/12
to scala-l...@googlegroups.com
I eventually got past this by changing one of my inner classes (it was conflicting with my code rather than with an external library code, so I could work around it).

I had something like this (not exactly, but it serves for demonstration purposes):

public enum Choice {
  YES {
    @Override
    public boolean value() { return true; } 
  },

  NO {
    @Override 
    public boolean value() { return false; } 
  };
  public abstract boolean value();
}

and changed it to 
public enum Choice { 
  YES,
  NO;

  public boolean value() { return this.equals(YES); }
}
This made the compiler happy, although I do not overly enjoy how it turned out.

--
Diogo
Reply all
Reply to author
Forward
0 new messages