Circular dependency in spring

if a is dependent on b, b is dependent on c  then how initialization will happen spring.

The Spring container is able to resolve Setter-based circular dependencies but gives a runtime exception BeanCurrentlyInCreationException in case of Constructor-based circular dependencies. In case of Setter-based circular dependency, the IOC container handles it differently from a typical scenario wherein it would fully configure the collaborating bean before injecting it. For eg., if Bean A has a dependency on Bean B and Bean B on Bean C, the container fully initializes C before injecting it to B and once B is fully initialized it is injected to A. But in case of circular dependency, one of the beans is injected to the other before it is fully initialized.

Note :we can generally trust Spring to do the right thing. It detects configuration problems, such as references to non-existent beans and circular dependencies, at container load-time. Spring sets properties and resolves dependencies as late as possible, when the bean is actually created.

Return in try

what will happen when we will put return in try block or in exception block,, will finally block will execute.
You can put return any where it will definitely execute finally block but if you put exit block then it will not execute finally.. it will terminate whenever it gets system.exit().

Strings are immutable but How?

We all know Strings are immutable but how:

When we create String from string literal like String s = "Ishaan"; it goes into separate area in heap called String Literal pool. Afterward any creation of string "Ishaan"  in such way return the same reference as we have. Now say your application is using 100 references of the same string s if string would be mutable it could be changed by malicious code and your whole application got crashed.

Another example you can take is say you have developed  a web application a gmail kind of application and your name is "Ishaan" when you sign in you get your name displayed on right top. This name must be coming from String literal pool since you should not be interested in creating String using new operation as it create new object in heap. So now your name is "Ishaan" which may belongs to another user of you email application or millions of people infact if your app is popular. So think in this case if String would be mutable millions of people starts getting wrong name .I hope this is more clear to any one here.

Problem for Hash Map

String was made final so that no one can compromise invariant of String class e.g. Immutability, Caching, hashcode calculation etc by extending and overriding behaviors.

Another reason of why String class is immutable could die due to HashMap.

Since Strings are very popular as HashMap key, it's important for them to be immutable so that they can retrieve the value object which was stored in HashMap. Since HashMap works in the principle of hashing, which requires same has value to function properly. Mutable String would produce two different hashcodes at the time of insertion and retrieval if contents of String was modified after insertion, potentially losing the value object in the map.

Contract between equal and hash code

In simple word

1. If two objects are equal, then they must have the same hash code.

2. If two objects have the same hashcode, they may or may not be equal.

or

General contract of hashCode is:

•  Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.

•  If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.

•  It is not required that if two objects are unequal according to the equals(java.lang.Object)   method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables.