> Take a look at SerializableChecker$HandleTable, which I basically
> copied from ObjectOutputStream. That's what you should use instead of
> the hasmap you're using as you're looking for system hash rather then
> what the object thinks it's identity should be like. It's not only way
> cheaper to do that, but it also shields against problems that can
> arise when objects have a hashcode implementation that e.g. depends on
> a hibernate session being available and current. But anyway, the speed
argument alone is more than worth it.
ahh yes i already thought about that.. :)
what i do now is even better compression because if an object says it is
content equal
then i only do one.
At the cost of invoking a more expensive function (hashCode compared
to System.identityHashCode) which you should also guard with try/
catch as it may fail and when it does you don't want to fail the whole
serialization because of it (you probably should fall back on
indentity hashcode in that case).
Also, the benefit of using object identity proper would be mostly for
'domain objects' that properly provide a hashCode and equals function.
And only if they implemented it efficiently.
The problem is that that is the case for immutable
objects
especially string. I really don't want to print "Eelco" and "Eelco" twice
into the buffer
There i really want content equals (The same goes for all the Number
classes, but those are handled
already specially)
So i will make it identity equal for all objects
Good idea.
except String
Measure whether it makes a difference and whether the slightly more
expensive call to string justifies it.
Eelco
