RE: Bug with Current KJC Compiler
> Under the new KJC (from their website), it works a bit better: > > Administrator@BFULGHAM1 ~/java > $ javac PlusPlusTest.java > assertion "!INTS_DISABLED()" failed: file "exception.c", line 386 > Aborted (core dumped) > > I'm not sure which is worse -- however the second case > indicates an issue with the JVM so might be of more interest > to us as time passes. > Actually, it seems to be related to time. If I run in verbose mode, everything builds just fine... Administrator@BFULGHAM1 ~/java $ javac OldTest.java assertion "!INTS_DISABLED()" failed: file "exception.c", line 386 Aborted (core dumped) Administrator@BFULGHAM1 ~/java $ javac -v OldTest.java [ start compilation in verbose mode ] [ parsed OldTest.java in 344 ms ] [ checked interfaces in 273 ms ] [ checked body of OldTest.java in 188 ms ] [ optimized and generated OldTest in 187 ms ] [ compilation ended ] -Brent
Bug with Current KJC Compiler
The version of KJC that ships in Kaffe right now has a bug with the ++ operator when used with instance variables. Here's a sample program that highlights the problem (at least under a Cygwin build): public class PlusPlusTest { private int count = 0; public PlusPlusTest() { for (int i = 1; i < 5; ++i) { //count++; // This works ++count;// This fails } } public static void main(String[] argv) { PlusPlusTest ppt = new PlusPlusTest(); System.out.println("Test Key: " + new Integer(ppt.count).toString()); } } An attempt to compile results in: -1 / -2 10: N/A putfield 0: 1 aload_0 1: 0 invokespecial 2: 1 aload_0 3: 0 invokespecial 4: 1 iconst_1 5: 0 istore_1 6: 0 goto 7: 1 aload_0 8: 2 iconst_1 9: 1 iadd 10: N/A putfield 11: N/A iinc 12: 1 iload_1 13: 2 iconst_5 14: 0 if_icmplt 15: N/A return 0: 1 aload_0 1: 0 invokespecial 2: 1 aload_0 3: 0 invokespecial 4: 1 iconst_1 5: 0 istore_1 6: 0 goto 7: 1 aload_0 8: 2 iconst_1 9: 1 iadd 10: N/A putfield 11: N/A iinc 12: 1 iload_1 13: 2 iconst_5 14: 0 if_icmplt 15: N/A return 0: 1 aload_0 1: 0 invokespecial 2: 1 aload_0 3: 0 invokespecial 4: 1 iconst_1 5: 0 istore_1 6: 0 goto 7: 1 aload_0 8: 2 iconst_1 9: 1 iadd 10: N/A putfield 11: N/A iinc 12: 1 iload_1 13: 2 iconst_5 14: 0 if_icmplt 15: N/A return GenCode failure in source class: PlusPlusTest at.dms.classfile.ClassFileFormatException: stack underflow at at.dms.classfile.InstructionHandle.checkInstruction(InstructionHandle.java:122) at at.dms.classfile.CodeEnv.checkExecutionPath(CodeEnv.java:95) at at.dms.classfile.JumpInstruction.check(JumpInstruction.java:147) at at.dms.classfile.InstructionHandle.checkInstruction(InstructionHandle.java:133) at at.dms.classfile.CodeEnv.checkExecutionPath(CodeEnv.java:95) at at.dms.classfile.JumpInstruction.check(JumpInstruction.java:147) at at.dms.classfile.InstructionHandle.checkInstruction(InstructionHandle.java:133) at at.dms.classfile.CodeEnv.checkExecutionPath(CodeEnv.java:95) at at.dms.classfile.CodeEnv.checkExecutionPaths(CodeEnv.java:73) at at.dms.classfile.CodeEnv.check(CodeEnv.java:47) at at.dms.classfile.CodeInfo.resolveConstants(CodeInfo.java:289) at at.dms.classfile.AttributeList.resolveConstants(AttributeList.java:237) at at.dms.classfile.MethodInfo.resolveConstants(MethodInfo.java:221) at at.dms.classfile.ClassInfo.resolveConstants(ClassInfo.java:467) at at.dms.classfile.ClassInfo.write(ClassInfo.java:360) at at.dms.classfile.ClassInfo.write(ClassInfo.java:436) at at.dms.kjc.CSourceClass.genCode(CSourceClass.java:235) at at.dms.kjc.Main.genCode(Main.java:222) at at.dms.kjc.Main.run(Main.java:174) at at.dms.kjc.Main.compile(Main.java:68) at at.dms.kjc.Main.main(Main.java:59) error:stack underflow This happens under both Kaffe and the Sun JVM, so seems to indicate a bug in the actual KJC compiler code. Under the new KJC (from their website), it works a bit better: Administrator@BFULGHAM1 ~/java $ javac PlusPlusTest.java assertion "!INTS_DISABLED()" failed: file "exception.c", line 386 Aborted (core dumped) I'm not sure which is worse -- however the second case indicates an issue with the JVM so might be of more interest to us as time passes. Thanks, -Brent
RE: JRE file layout for 1.0.7?
> Is anybody opposed to this? It is breaking with tradition > somewhat, and it's for the upcoming release, so I figured > it would be best to ask. It'll also impact the Debian and > RPM packages. > Go for it -- this will also allow side-by-side testing with other JRE implementations by resetting the JAVA_HOME variable when so desired. -Brent