And so it came to pass: I, too, encountered adversity of enhanced bytecode :) It was puzzling to get a finger on it, as the only exception I've seen was a java.io.EOFException that would be thrown in the client. So, the stream of data was suddenly interrupted by the server. But server would give no explanation why... So until I attached debugger to server process and tried to inspect the values in the collection a server was about to return, it was not clear that DTOs produced by Hibernate were "incomplete". The infamous LazyInitializationException was presented to me in IntelliJ IDEA's debugger clear and obvious. Now this piece of work to deal with: walk through all methods of the service's class and see where else lazily-loadable associations need to be Hibernate.initialize()'d. Hmm... but speaking of adversities of instrumented bytecode, I'm anxious to see what the reaction would be to stacktraces that are bound to become twice longer due to service class being wrapped into two dynamic proxies (by means of Spring container), one, to take care of transactionality of it all, and the other, to translate Hibernate exceptions.
Update: Hibernate has nothing to do with this. What had? watch this:
public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException {
first = in.readLong();
second = in.readLong(); third = in.readLong();
}
public void writeExternal(ObjectOutput out) throws IOException {
out.writeLong(first);
out.writeObject(second); out.writeLong(third);
}
Thanks to the magic of Java 5 autoboxing, this error sneaked in: field is being serialized as an Object, but attempted to be read as a primitive. (This field was an object in prior version of software, now it becomes primitive, but the change was made only to have the class compile...) Few bugs like this one could be still sneaking around.