wood burning stoves 2.0*
The moose likes I/O and Streams and the fly likes Huge number of int arrays during deserialization. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » I/O and Streams
Bookmark "Huge number of int arrays during deserialization." Watch "Huge number of int arrays during deserialization." New topic

Huge number of int arrays during deserialization.

Raja Reddy Karri

Joined: Nov 29, 2013
Posts: 1
We see that there are huge number of int array instances during deserialization. We understand that this is due to creation of dependency tracking objects (java.io.ObjectInputStream$HandleTable$HandleList) created. As I understand, they are used to propagate ClassNotFoundException to "dependent" objects while reading an object.

I fail to understand the need to track this dependency of ClassNotFoundException over a target object? Why can't the implementation throw the exception right away, if the ClassNotFoundException is found?

Going through the code of ObjectInputStream, I think any ClassNotFoundException could be propagated immediately, rather marking the exception on every dependent object, thus avoiding HandleList and int[].

I do realize that HandleTable's "entries" are absolutely required to wire any previously read objects into dependent objects read later from the stream. Just to clarify, question is about significance of java.io.ObjectInputStream$HandleTable$HandleList, which I fail to understand.

Any insight is greatly appreciated.

It is sorta covered in the JavaRanch Style Guide.
subject: Huge number of int arrays during deserialization.
Similar Threads
Object serialization
Denny's DVD Serialize or standard file
Why HashMap.Entry is transient?
Marker interface Serializable
Serialization !!!!!!!!!!!!! Help me out