Having done some rather detailed debugging, I've made some progress here. The problem appears to be that somewhere in between jacl/tcl reading in the .class file (set fin [open Foo.class r]; fconfigure ... ; set data [read $fin] ; close $fin), and it being handled internally by java::defineclass (or equivalent), the binary data representation is simply corrupted!!
In fact I've duplicated with both Jacl and Tcl, that the eventual byte[] classData sent to defineClass(className, classData, 0, classData.length), has, in a number of places (the same places for both Jacl and Tcl), some bytes replaced by '0x3f'.
In fact for my file 'Customer.class' (which I'm happy to send anyone), the 166th byte is changed from 0x9e to 0x3f, and the 213th byte is changed from 0x8f to 0x3f. There were no other bytes modified in the first 480 (I got bored after that).
I do not know whether every occurrence of 9e/8f was changed to 3f and I do not know if other codes are affected differently. However all of the above has been very carefully checked.
----
Now, where is the problem happening? That I don't yet know. The basic sequence of actions is that a Tcl/Jacl string (or could it be bytearray internally, at least on Tcl 8.2?) is passed to java::defineclass and ends up in a java TclObject. From there the route is simply:
TclObject tObj; // arrives from Tcl/Jacl
classData = tObj.toString().getBytes();
Perhaps someone who knows the internals of jacl/tclblend might be able to shed some light on this?
thanks for any help,
Vince.
p.s. I'm quite happy to mail my Customer.class file to anyone who'd like to check this.
