Develop Reference

Why Map's general contract, which mandates the use of the equals method when comparing objects is violated in hazelcast Map

This is more of a design question. I would like to know why hazelcast uses hashCode() and equals() of binary (serialized) forms of the objects instead of the ones provided by the composite key objects.
I faced a problem in which I had to associate some metadata (lastModifiedTimeStamp, lastModifiedNode etc.) with the key object, which is not possible because of this violation.
While I do understand that there are other ways to tackle my problem, making these attributes a part of the key (followed by overriding hashCode() / equals() method to exclude the metadata) would've been a cleaner approach.

This is a very good question. There are multiple reasons for this, but one of them might be this:
We keep keys in a serialized (=binary) form. In other to use regular hashCode() and equals() from your domain objects we would need to have them in de-serialized (object) format.
Just this fact alone means:
- You would always need .class file of your domain objects on all cluster members. When members are dealing with serialized blobs only then you don't need that.
You could either keep keys in de-serialized format only, but then you would have to serialize them for each remote request -> performance penalty. Hazelcast is build on an assumption most your operations are remote.
Or you could maintain keys on both serialized & deserialized form -> space penalty.
I'm sure there are other reasons; These are just a few I can think of from top of my head.
Credits - Jaromir Hamala - Hazelcast mailing list.

Java HashMap vs JSONObject

I am wondering about the performance of Java HashMap vs JSONObject.
It seems JSONObject stores data internally using HashMap. But JSONObject might have additional overhead compared to HashMap.
Does any one know about the performance of Java JSONObject compared to HashMap?
Thanks!

As you said, JSONObject is backed by a HashMap.
Because of this, performance will be almost identical. JSONObject.get() adds a null check, and will throw an exception if a key isn't found. JSONObject.put() just calls map.put().
So, there is almost no overhead. If you are dealing with JSON objects, you should always use JSONObject over HashMap.

I would say the question doesn't make sense for a few reasons:
Comparing apples to oranges: HashMap and JSONObject are intended for 2 completely different purposes. It's like asking "is the Person class or Company class more efficient for storing a PhoneNumber object". Use what makes sense.
If you are converting to/from JSON, you are likely sending the data to a far away place (like a user's browser). The time taken to send this data over the network and evaluate it in the user's browser will (likely) far eclipse any performance differences of populating a Hashmap or JSONObject.
There is more than 1 "JSONObject" implementation floating around out there.
Finally, you haven't asked about what sort of performance you would like to measure. What are you actually planning to do with these classes?

Existing answers are correct, performance differences between the two are negligible.
Both are basically rather inefficient methods of storing and manipulating data. More efficient method is typically to bind into regular Java objects, which use less memory and are faster to access. Many developers use org.json's simple (primitive) library because it is well-known, but it is possible the least convenient and efficient alternative available. Choices like Jackson and Gson are big improvements so it is worth considering using them.

JSONObject does not have too much additional overhead on top of a HashMap. If you are okay with using a HashMap then you should be okay using a JSONObject. This is provided you want to generate JSON.
JSONObject checks for validity of values that you are storing as part of your JSONObject, to make sure it conforms to the JSON spec. For e.g. NaN values do not form a part of valid JSON. Apart from this, JSONObject can generate json strings (regular | prettfied). Those strings can get pretty big, depending on the amount of JSON. Also, JSONObject uses StringBuffer, so one of the many things that i would do would be to replace all occurrences of StringBuffer with StringBuilder.
JSONObject (from org.json) is one of the simple JSON libraries that you can use. If you want something very efficient, use something like Jackson.

The only performance overhead is on casting data! As you JSONObject stores data on a HashMap of objects and it casts the datatype you want.

Java's Representation of Serialized Objects

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?

When to use the various generic containers in Java

Does anyone know of any resources or books I can read to help me understand the various Java collection classes?
For example:When would one use a Collection<T> instead of a List<T>
and when would you use a Map<T, V> instead of aList<V>, where V has a member getId as shown below, allowing you to search the list for the element matching a given key:
class V {
T getId();
}
thanks

You use a Map if you want a map-like behaviour. You use a List if you want a list-like behaviour. You use a Collection if you don't care.
Generics have nothing to do with this.
See the Collections tutorial.

You can take a look at sun tutorial. It explains everything in detail.
http://java.sun.com/docs/books/tutorial/collections/index.html (Implementation section explain the difference between them)

This book is very good and covers both the collection framework and generics.

You can check the documentation of the java collection API.
Anyway a basic rule is : be as generic as possible for the type of your parameters. Be as generic as possible for the return type of your interfaces. Be as specific as possible for the return type of your final class.

A good place to start would be the Java API. Each collection has a good description associated with it. After that, you can search for any variety of articles and books on Java Collections on Google.

The decision depends on your data and your needs to use the data.
You should use a map if you have data where you can identify each element with a specific key and want to access or find it by with this key.
You take a List if you don't have a key but you're interested in the order of the elements. like a bunch of Strings you want to store in the order the user entered it.
You take a Set if you don't want to store the same element twice.
Also interesting for your decision is if you're working in am multithreaded environment. So if many threads are accessing the same list at the same tame you would rather take a Vector instead of an ArrayList.
Btw. for some collections it is usefull if your data class implements an interface like comparable or at least overrides the equals function.
here you will find more information.

Most Java books will have a good expanation of the Collections Framework. I find that Object-Oriented-Software-Development-Using has a good chapter that expains the reasons why one Collection is selected over another.
The Head first Java also has a good intropduction but may not tackle the problem of which to select.

The answer to your question is how are you going to be using the data structure? And to get a better idea of the possibilities, it is good to look at the whole collections interfaces hierarchy. For simplicity sake, I am restricting this discussion only to the classic interfaces, and am ignoring all of the concurrent interfaces.
Collection
+- List
+- Set
+- SortedSet
Map
+- SortedMap
So, we can see from the above, a Map and a Collection are different things.
A Collection is somewhat analogous to a bag, it contains a number of values, but makes no further guarantees about them. A list is simply an ordered set of values, where the order is defined externally, not implicitly from the values themselves. A Set on the other hand is a group of values, no two of which are the same, however they are not ordered, neither explicitly, nor implicitly. A SortedSet is a set of unique values that are implicitly sorted, that is, if you iterate over the values, then they will always be returned in the same order.
A Map is mapping from a Set of keys to values. A SortedMap is a mapping from a SortedSet of keys to values.
As to why you would want to use a Map instead of a List? This depends largely on how you need to lookup your data. If you need to do (effectively) random lookups using a key, then you should be using a set, since the implementations of that give you either O(1) or O(lgn) lookups. Searching through the list is O(n). If however, you are performing some kind of "batch" process, that is you are processing each, and every, item in the list then a list, or Set if you need the uniqueness constraint, is more appropriate.

The other answers already covered an overview of what the collections are, so I'd add one rule of thumb that applies to how you might use collections in your programming:
Be strict in what you send, but generous in what you receive
This is a little controversial (some engineers believe that you should always be as strict as possible) but it's a rule of thumb that, when applied to collections, teaches us to pick the collection that limits your users the least when taking arguments but gives as much information as possible when returning results.
In other words a method signature like:
LinkedList< A > doSomething(Collection< A > col);
Might be preferred to:
Collection< A > doSomething(LinkedList< A > list);
In version 1, your user doesn't have to massage their data to use your method. They can pass you an ArrayList< A >, LinkedHashSet< A > or a Collection< A > and you will deal with. On receiving the data from the method, they have a lot more information in what they can do with it (list specific iterators for example) than they would in option 2.

When to use Enum or Collection in Java

Under what circumstances is an enum more appropriate than, for example, a Collection that guarantees unique elements (an implementer of java.util.Set, I guess...)?
(This is kind of a follow up from my previous question)

Basically when it's a well-defined, fixed set of values which are known at compile-time.
You can use an enum as a set very easily (with EnumSet) and it allows you to define behaviour, reference the elements by name, switch on them etc.

When the elements are known up front and won't change, an enum is appropriate.
If the elements can change during runtime, use a Set.

I am no java guru, but my guess is to use enumeration when you want to gurantee a certain pool of values, and to use a collection when you want to gurantee uniqueness. Example would be to enumerate days of the week (cant have "funday") and to have a collection of SSN (generic example i know!)

Great responses - I'll try and summarise, if just for my own reference - it kinda looks like you should use enums in two situations:
All the values you need are known at compile time, and either or both of the following:
you want better performance than your usual collection implementations
you want to limit the potential values to those specified at compile time
With the Collection over enumeration links that Jon gave, you can get the benefits of enum performance and safety as an implementation detail without incorporating it into your overall design.
Community wiki'd, please do edit and improve if you want to!

Note: you can have both with an EnumSet.

In some situations your business requires the creation of new items, but at the same time business logic based on some fixed items. For the fixed ones you want an enum, the new ones obviously require some kind of collection/db.
I've seen projects using a collection for this kind of items, resulting in business logic depending on data which can be deleted by the user. Never do this, but do create a separate enum for the fixed ones and a collection for the others, just as required.
An other solution is to use a collection with immutable objects for the fixed values. These items could also reside in a db, but have an extra flag so users cannot update / delete it.