Stephan van Hulst wrote:You would use these if the actual object you want to work with in your code is different from what you need to serialize the object.
The common example is instance-controlled classes. Other classes are not allowed to call their constructor because it shouldn't be possible to have more instances than the ones you already provide. Java's cloning and serialization mechanisms provide 'magic' ways to create new instances anyway. The writeReplace() and readResolve() methods allow your application to (de)serialize representations of these instances, and then convert between the representation and the controlled instance.
Another example is if you have written a class which enforces its invariants very strictly, which make it difficult for the serialization mechanism to create new instances. Let's say you have written an immutable class with final member variables, and you need to perform validation in the constructor before you can guarantee that the class is in a valid state. Because the serialization mechanism requires you to have a parameterless constructor that can't do validation, your type can't be deserialized. The solution here is to use writeReplace() to replace your object with a mutable representation (usually just a javabean) which gets serialized, and upon deserialization the readResolve() method is called to convert the bean back to your strict type.
Paweł Baczyński wrote:Hashtable has its method synchronized. Like:Collections.synchronizedMap wraps the collection using synchronized methods. Like:
With regards to thread safety, they both do the same thing.
There is also ConcurrentHashMap but it has a different thread-0sadety policy, Did you have a chance to check it?
code samples from JDK 1.8.0_40
Paul Clapham wrote:I just did a quick look through the API documentation and I see that HashMap allows null keys and null values whereas Hashtable doesn't. Hashtable has an elements() method which returns an Enumeration whereas HashMap doesn't. There could be plenty of other differences, I invite you to look at the docs for yourself.
Anurag Verma wrote:best place would be javadocs, did you go through that too? let us know what exactly you didn't get..Doing some hands-on will make stuff more clear, did you try that too?
Paul Clapham wrote:
Siddharth Bhargava wrote:so a+"deal" would make a new string literal "meowdeal"
No, this is the flaw in your thinking. It does indeed make a new String value, but it doesn't make a new String literal. Recall that a String literal appears in your code as a quote followed by a series of characters followed by a quote; your example contains three such literals.
And yes, it's true that your example does contain a String literal (at line 8) which contains the same series of characters as that String value created at line 6. But there's nothing which tries to match String values to entries in the String pool. So the literal at line 8 will be in the String pool, as you know, but the value at line 6 won't.
Gamini Sirisena wrote:If there is some problem in getting a connection getConnection is supposed to throw an SQLException
by catching this you can decide on a course of action.. in general terms if there is an opportunity to recover then take than action.. if not you bubble up the Exception.. probably wrapped in an application specific Exception