ClassCastException caused by bug in Just In Time ?

Question

Given this piece of code :

public static void writeFile(File file,List buffer)throws IOException{
    File fic = new File(file.getCanonicalPath());
    cat.debug("writing file : "+fic.getAbsolutePath());
    FileOutputStream out = new FileOutputStream(fic);
    PrintStream ps = new PrintStream(out);
    for(int i=0;i<buffer.size();i++){
        ps.println(buffer.get(i));
    }
    ps.flush();
    ps.close();
    out.close();
}

(please no advice about how to close streams safely, this is legacy code and the new version makes use of try / finally)

I get a ClassCastException at the "ps.println(buffer.get(i))"

this method is called several times (say 5 times) with a list only filled with Strings then, it is called with a list filled with String and an other object (say ErrorObject) At the point we reach the 1st ErrorObject, we get the ClassCastException.

com.mycompany.ErrorObject incompatible with java.lang.String

This problem occurs in production environment, but cannot be reproduced in Dev environment : Prod : jvm=IBM J9 VM 2.4 J2RE 1.6.0 IBM J9 2.4 AIX ppc-32 jvmap3260-20081105_25433 (JIT enabled, AOT enabled) Dev : WinXP, JDK 1.6.0_16

Is there any reason this code could fail ?

It was patched recently, i fear that the production team did not upgrade the jar correctly, but my boss already checked that the patch was applied correclty ...

I was wondering if the Just in Time compiler could "wire" the ps.println to the ps.println(String) instead of the ps.println(Object). That could explain such a problem, but I have no idea if this possible.

Any advices welcome, thank you in advance

EDIT : i was asked full stack trace so here it is :

java.lang.ClassCastException: com.mycompany.util.ErrorObject incompatible with java.lang.String
    at com.mycompany.util.FileUtils.writeFile(FileUtils.java:91)
    at com.mycompany.util.FileUtils.writeFile(FileUtils.java:50)
    at com.mycompany.itools.task.DBCompareInits.doDBTask(DBCompareInits.java:959)
    at com.mycompany.itools.task.DBTask.doTask(DBTask.java:115)
    at com.mycompany.itools.task.TaskGroup.startGroup(TaskGroup.java:115)
    at com.mycompany.runner.Runner.main(Runner.java:209)

EDIT 2 : javap -c

   65:  invokeinterface #20,  1; //InterfaceMethod java/util/List.size:()I
   70:  if_icmpge   92
   73:  aload   4
   75:  aload_1
   76:  iload   5
   78:  invokeinterface #21,  2; //InterfaceMethod java/util/List.get:(I)Ljava/lang/Object;
   83:  invokevirtual   #31; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V
   86:  iinc    5, 1
   89:  goto    62
   92:  aload   4
   94:  invokevirtual   #32; //Method java/io/PrintStream.flush:()V
   97:  aload   4
   99:  invokevirtual   #33; //Method java/io/PrintStream.close:()V
   102: aload_3
   103: invokevirtual   #28; //Method java/io/FileOutputStream.close:()V

Answer 1

Declare toString() method with converting to string inside in ErrorObject class and add +"" to println() call. Like pintln(errorObjList+"");

Answer 2

I was wondering if the Just in Time compiler could "wire" the ps.println to the ps.println(String) instead of the ps.println(Object). That could explain such a problem, but I have no idea if this possible.

It is not possible. Or at least not unless there is a bytecode compiler or JIT compiler bug. And you should only blame compiler bugs if you have irrefutable evidence that this is so.

However, the first thing I would check is that the code being executed was really compiled from the source code that you are looking at. One way to confirm this would be to recompile from source, and then compare the results of running javap on respective copies of the class. Looking at the bytecodes will also tell you which overload of println the bytecode compiler is saying to use.

EDIT - the javap output clearly shows that that version of the bytecode should call println(Object), and there is no checkcast opcode in sight. A JIT compiler bug that calls the wrong method and spontaneously inserts code to do a classcast is sounding more and more implausible.