Comments on: Revisiting J2ME Object Serialization http://j2me.synclastic.com/2006/07/25/revisiting-j2me-object-serialization/ Java ME Tutorials and Tips by Eric Giguere Thu, 28 Aug 2008 20:54:24 +0000 http://wordpress.org/?v=2.3.3 By: Eric Giguere, J2ME expert and author http://j2me.synclastic.com/2006/07/25/revisiting-j2me-object-serialization/#comment-34 Eric Giguere, J2ME expert and author Wed, 26 Jul 2006 22:02:16 +0000 http://j2me.synclastic.com/2006/07/25/revisiting-j2me-object-serialization/#comment-34 When I emailed the reader with my suggestion, I didn't actually provide any code, just a description of what to do.... so for this post I added a bit of code and I tried to make it simple. But there you go proving my point about how you need to keep optimizing! :-) When I emailed the reader with my suggestion, I didn’t actually provide any code, just a description of what to do…. so for this post I added a bit of code and I tried to make it simple. But there you go proving my point about how you need to keep optimizing! :-)

]]> By: stefan haustein http://j2me.synclastic.com/2006/07/25/revisiting-j2me-object-serialization/#comment-33 stefan haustein Wed, 26 Jul 2006 20:50:48 +0000 http://j2me.synclastic.com/2006/07/25/revisiting-j2me-object-serialization/#comment-33 Well, if you do not have a static list of classes, the 'cname.equals( "com.mypackage.Employee" )' approach does not work out, so I took that for granted :) Well, if you do not have a static list of classes, the ‘cname.equals( “com.mypackage.Employee” )’ approach does not work out, so I took that for granted :)

]]> By: Eric Giguere, J2ME expert and author http://j2me.synclastic.com/2006/07/25/revisiting-j2me-object-serialization/#comment-32 Eric Giguere, J2ME expert and author Wed, 26 Jul 2006 20:43:12 +0000 http://j2me.synclastic.com/2006/07/25/revisiting-j2me-object-serialization/#comment-32 Hi Stefan, thanks for your comments. Yes, a hash table is another possible way to handle the problem if it's the class lookup that's slow. If the instantiation view newInstance is slow that's another problem. The reader didn't test both cases so I don't know what the specific problem was, though I suspect it was the class lookup. As for your other comments: 1. You have to remember that with the J2ME Tech Tips I write code that is both compact and generic as much as possible. So that's why I stored classnames in the stream. Yes, if you had a static list of classes to work from then what you suggest is a good thing to do. 2. Agreed, and that's in fact what I've done in my own programs. 3. Again yes, though properly serializing subclasses is tricky and requires a good deal of thought. Eric Hi Stefan, thanks for your comments. Yes, a hash table is another possible way to handle the problem if it’s the class lookup that’s slow. If the instantiation view newInstance is slow that’s another problem. The reader didn’t test both cases so I don’t know what the specific problem was, though I suspect it was the class lookup.

As for your other comments:

1. You have to remember that with the J2ME Tech Tips I write code that is both compact and generic as much as possible. So that’s why I stored classnames in the stream. Yes, if you had a static list of classes to work from then what you suggest is a good thing to do.

2. Agreed, and that’s in fact what I’ve done in my own programs.

3. Again yes, though properly serializing subclasses is tricky and requires a good deal of thought.

Eric

]]> By: stefan haustein http://j2me.synclastic.com/2006/07/25/revisiting-j2me-object-serialization/#comment-31 stefan haustein Wed, 26 Jul 2006 20:37:21 +0000 http://j2me.synclastic.com/2006/07/25/revisiting-j2me-object-serialization/#comment-31 Hi Eric, did you try to use a hashtable to cache the mapping from class names to Class objects? BTW: 1. Why not use a static final int constants for all the classes (including those implementing persistent, not only primitive types), and then have a single large switch block? This will make the serialized data more compact and avoid string creation overhead while reading from the file. Make sure the code compiles to a jump table by chosing constants carefully. 2. Use resurect(DataInputStream dis) to avoid (possibly nested) byte array and stream creation overhead. 3. If you implement "public static Object resurrect(DataInputStream dis)", you can re-use this method it in the resurrect method of classes implementing Persistent, supporting polimorphism when reading members. Best regards, Stefan Hi Eric,

did you try to use a hashtable to cache the mapping from class names to Class objects?

BTW:

1. Why not use a static final int constants for all the classes (including those implementing persistent, not only primitive types), and then have a single large switch block? This will make the serialized data more compact and avoid string creation overhead while reading from the file. Make sure the code compiles to a jump table by chosing constants carefully.

2. Use resurect(DataInputStream dis) to avoid (possibly nested) byte array and stream creation overhead.

3. If you implement “public static Object resurrect(DataInputStream dis)”, you can re-use this method it in the resurrect method of classes implementing Persistent, supporting polimorphism when reading members.

Best regards,
Stefan

]]>