I'm looking for the format that Java uses to serialize objects. The default serialization serializes the object in a binary format. In particular, I'm curious to know if two runs of a program can serialize the same object differently.
What condition should an object satisfy so that the object maintains its behavior under Java's default serialization/deserialization round-trip?
You need the Java Object Serialization Specification at http://java.sun.com/javase/6/docs/platform/serialization/spec/protocol.html.
If you have two objects with all properties set to identical values, then they will be serialized the same way.
If it weren't repeatable, then it wouldn't be useful!
They will always serialize it the same way. If this wasn't the case, there would be no guarantee that another program could de-serialize the data correctly, defeating the purpose of serialization.
Typically running the same single-threaded algorithm with the same data will result in the same result.
However, things such as the order with which a HashSet serialises entries is not guaranteed. Indeed, an object may be subtly altered when serialised.
I like #Stephen C's example of Object.hashCode(). If such nondeterministic hash codes are serialized, then when we deserialize, the hash codes will be of no use. For example, if we serialize a HashMap that works based on Object.hashCode(), its deserialized version would behave differently than the original map. That is, looking up the same object would give us different results in the two maps.
If you don't want binary then you can use JSON (http://www.json.org/example.html) in java http://www.json.org/java/
Or XML for that matter http://www.developer.com/xml/article.php/1377961/Serializing-Java-Objects-as-XML.htm
I'm looking for the format that Java
uses to serialize objects.
Not to be inane, it writes them somehow. How exactly that is can and probably should be determined by you. A Character maps to .... uh, it gets involved but rather than re-inventing the wheel let us ask exactly what do you need to have available to reconstruct an object to what state?
The default serialization serializes
the object in a binary format.
So? ( again, not trying to be inane - sounds like we need to define a problem that may not have data concepted )
I'm curious to know if two runs of a
program can serialize the same object
differently.
If you had a Stream of information, how would you determine what states the object needed to be restored to?
Related
I am getting different children sometimes, for an xml node for single execution of program at different debugs, but still hashcode is same.Will it possible to be like this?
Is there any way how to know and when my xml node data being changed?
Please help on this?
If you are talking about org.xml.dom.Node and its subclasses like org.xml.dom.Element, these do not override the equals() and hashCode() methods. That means they do the same as Object.equals() - which means the hash code depends only on the Java object identity, and doesn't change with the object's content. This effectively makes equals() useless for nodes (you don't even get a guarantee that the same node is always represented by the same Java object). DOM provides two methods for comparing nodes: isSameNode and isEqualNode - but neither of them provides a corresponding hash code function.
Lousy design, yes. Frankly, I don't know why anyone still uses DOM. There are much better alternatives available, like JDOM2 and XOM.
Yes, it is possible.
All a hash code promises is that it is always the same if the content hasn’t changed. However, it does not promise that it will always change when the object changes. In fact, it cannot promise this, since objects are arbitrary size and a hash code is of fixed size. Once the object size exceeds than the hash size, you can no longer bijectively map the hash to the objects and there are at least 2 objects with the same hash.
Externalizable interface seems to be hard to use. Reasons
Strings in an object can be null. So, I have create and serialize flags to mentioned weather or not to do inReader.readUTF()
For Java Lists its even more hard.
I am not sure, what is the best way to externalize a java HashMap, since I would know at reading time, how many keys are there and if any value is null.
I need a solution to the following problem. Suppose I have different fields in a class. Each of different type, some may be basic types such as Integers, some may be complex object type fields. I need to find a way to compare those fields after exit and restart of the app. By I am limited to dumping the values to file and comparing those. How can I put something on file and compare them so that I can determine whether they have changed or not. I do not need the values. Will getHashCode() help?
If I understand your question, you would like to compare content in a file after exit and before restart. One way would be to use a message digest. As in calculating the SHA1 of the contents and comparing that before restart.
It sounds like Java object serialization might do the trick for you. With serialization, you can write any object to a file, and later read it in again and reconstruct the original object. If you then have an isEqual() method on the object, you can use that to simply check whether the object is the same.
EDIT: reread the question. If you want to compare the file contents, then serialization is not particular useful, as there are bound to be small differences between the two files.
I guess hashCode() will help only if it's implemented in such a way that will return the same result for two objects if the objects have the same values. Of course, for non-primitive fields you'll have to decide what does "same value" mean, and you would be probably required to implement hashCode() for the types of those fields as well.
If you can't/don't want to implement hashCode() maybe JSON could help. I suggest using a library like Google's Gson to render a string representation of your object which you can then dump to file. If the way in which the object (or any of its members) is converted to string does not suit your needs you can specify the conversion with a JsonSerializer.
String strRep = new Gson().toJson(myObject);
I want to understand the reason and/or core-logic for JSONObject is being an un-ordered set. Because in most of my cases there would be a request which needs response as a JSONObject in the order of time/position. After searching, I found lot of members telling to use JSONArray which I do not feel a good solution.
I want to get a clear idea before proceeding further.
Thank you in advance.
JSONObject is unordered because objects described by JSON are unordered, by specification:
An object is an unordered set of name/value pairs.
(Which is because JSON is derived from [is a subset of] JavaScript's object initializer syntax, and JavaScript objects are unordered — because there's no reason for the properties of an object to be ordered in the general case. That can be left to specializations of objects, like JavaScript's arrays, which are nothing more than objects with some special handling of property names, and associated array-like functions.)
The true, complete reason is only known by the members of the ECMA committee which finalized the ECMAScript specification since JSONObjects are a subset of JavaScript Objects; however, here is my guess.
To require that the properties of a JSON Object maintain a fixed order would likely add additional implementation overhead to a data structure which would otherwise be simpler without having that requirement. For example, a JSON object could be implemented as a simple hashtable; however, if the order of the properties was to remain fixed then an additional data structure would be required to list their order.
If JavaScript prescribed ordering of object properties, it would preclude the usage of hashtables in their implementation. On the other hand, why would an object's properties be ordered in the first place? It seems like an arbitrary constraint with, as we can see, far-reaching negative consequences.
It is obvious that immutability increases the re-usability since it creates new object in each state change.Can somebody tells me a practical scenario where we need a immutable class ?
Consider java.lang.String. If it weren't immutable, every time you ever have a string you want to be confident wouldn't change underneath you, you'd have to create a copy.
Another example is collections: it's nice to be able to accept or return a genuinely immutable collection (e.g. from Guava - not just an immutable view on a mutable collection) and have confidence that it won't be changed.
Whether those count as "needs" or not, I don't know - but I wouldn't want to develop without them.
A good example is related to hashing. A class overrides the equals() and hashCode() methods so that it can be used in data structures like HashSet and (as keys in) HashMap, and the hash code is typically derived by some identifying member attributes. However, if these attributes were to change then so would the object's hash code, so the object is no longer usable in a hashing data structure.
Java provides a nice example: String.
This article has a good color example (since color definitions don't change).
http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html