Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / January 2006

Tip: Looking for answers? Try searching our database.

How to write a deserializer?

Thread view: 
Wibble - 26 Jan 2006 03:30 GMT
I wrote a serializer/deserializer only to realize
that you can't create a new object that
doesn't have a noArg constructor or populate
final slots.

I'm serializing a large structure. Java default
serialization gets stack overflows and won't
deserialize final slots either.  The classes
I'm serializing are immutable data carriers.

Am I missing something or do I have to use JNI
to cheat object creation and field setting?
Roedy Green - 26 Jan 2006 05:42 GMT
>I wrote a serializer/deserializer only to realize
>that you can't create a new object that
[quoted text clipped - 5 lines]
>deserialize final slots either.  The classes
>I'm serializing are immutable data carriers.

IIRC the constructor is not executed on reconstitution.  Transient
fields are not reconstituted.  As far as I know, final values should
be reconstituted.  To deal with the problem, you compose a readObject
method for the class that calls the usual readObject the patches up
the missing fields.

See http://mindprod.com/jgloss/serialization.html
for what I have learned.  If you discover errors, please let me know.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Wibble - 26 Jan 2006 12:15 GMT
>>I wrote a serializer/deserializer only to realize
>>that you can't create a new object that
[quoted text clipped - 14 lines]
> See http://mindprod.com/jgloss/serialization.html
> for what I have learned.  If you discover errors, please let me know.

Thanks R,

I need this to be non-intrusive. I cant/dontWantTo modify the
class definitions.  I also need to be able to read this from
notJava.  I don't think I can rely on classes implementing
deserializers since I'm not using default java serialization
format.

I'll look at ObjectStreamClass.setPrimFieldValues
and see if it does the job.
Chris Uppal - 26 Jan 2006 12:39 GMT
> I wrote a serializer/deserializer only to realize
> that you can't create a new object that
[quoted text clipped - 3 lines]
> Am I missing something or do I have to use JNI
> to cheat object creation and field setting?

I fear that -- unless you can change the target classes -- you will be forced
to use JNI.

You might find a third-party serialiser that has already done the work for you,
either to use directly or as a source of code to cannibalise.  Someone
mentioned XStream a little while ago:

   http://xstream.codehaus.org/

it looks quite good, but I have never used it myself.

   -- chris
Wibble0@gmail.com - 26 Jan 2006 18:26 GMT
I figured this out, but its not pretty.

import sun.misc.Unsafe;

 private static Unsafe getUnsafe() {
   try {
     Field field = Unsafe.class.getDeclaredField("theUnsafe");
     field.setAccessible(true);
     return (Unsafe)field.get(null);
   } catch (Exception ex) {
     throw new RuntimeException("can't get Unsafe instance", ex);
   }
 }
 private static final Unsafe unsafe__ = getUnsafe();
 private static void setBoolean(Field f, Object o, boolean v) {
   unsafe__.putBoolean(o, unsafe__.objectFieldOffset(f), v);
 }
 private static Object newInstance(Class clazz) throws Exception {
   return(unsafe__.allocateInstance(clazz));
 }
Chris Uppal - 26 Jan 2006 18:33 GMT
> I figured this out, but its not pretty.
>
> import sun.misc.Unsafe;

I'd forgotten about the "unsafe" stuff; never more than glanced at it to be
honest.

Let's hope it's still there in the next release ;-)

(If not you can always stoop to JNI /then/ -- sufficient unto the day are the
evils thereof...)

   -- chris
Thomas Hawtin - 26 Jan 2006 19:22 GMT
>> I figured this out, but its not pretty.
>>
[quoted text clipped - 4 lines]
>
> Let's hope it's still there in the next release ;-)

Your hope may come to nowt. I suspect you might find the non-documented
packages disappearing from view.

http://weblogs.java.net/blog/ray_gans/archive/2006/01/where_we_are_wi.html
   "So why will Mustang slip to autumn?
   "We've recently decided to make changes to address some issues in
      sensitive areas of the codebase (e.g., the classloader) ..."

Elsewhere there have been various mumblings about not relying on
undocumented features.

> (If not you can always stoop to JNI /then/ -- sufficient unto the day are the
> evils thereof...)

Remember that sun.misc.Unsafe is not necessarily what it appears. Calls
to those methods will usually be considered intrinsics (just think how
slow NIO buffers would be without that). Using JNI in place may well be
significantly slower.

Tom Hawtin
Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.