Loading same class by two different class loader in java

here are, at least, two general ways to generate a ClassCastException under the conditions described. One is with a branched ClassLoader hierarchy, and the second is with a ClassLoader that does not preferentially delegate to its parent.
Read on for the long winded explanation ...

In a simple J2SE application (like "Hello World") there are at least three ClassLoader instances involved. In order (and order is very significant) these are:
1.) bootstrap classes,
2.) extension classes
3.) classpath (user) classes.
These form a hierarchy (parent-child relationship) where the child (higher number in the above list) class loaders delegate to their parent before trying to load a class themselves. The delegation behavior is by convention and is not enforced.
As long as this is a simple chain (one child per parent) and the contract for delegation is followed then ClassCastExceptions due to ClassLoader differences are impossible.
If the ClassLoader hierarchy branches (i.e. 2 or more children for any parent) then ClassCastExceptions may be thrown even if the class names are identical. This is the scenario illustrated in the earlier post by Mr Friedman-Hill where there are 2 instances of URLClassLoader, each a child of the classpath classloader.
Also, if a ClassLoader does not follow the convention of delegating first to its parent then the potential exists for ClassCastException due to different ClassLoader instances. The simplest way to do this would be to write a ClassLoader that loads a class before delegating to its parent, in which case it could load something that the parent already has loaded.
J2EE app servers use a ClassLoader hierarchy to enforce some security, e.g. not allowing EARs to access other EARs classes. The behavior depends on the app server. Some app servers use one ClassLoader per EAR and a child ClassLoader per WAR. Some use a sibling arrangement where a ClassLoader for a WAR delegates to a sibling classloader for an EJB-JAR.

A relavent reference from: http://java.sun.com/developer/technicalArticles/Networking/classloaders/index.html

"As of JDK 1.2, a bootstrap class loader that is built into the JVM is responsible for loading the classes of the Java runtime. This class loader only loads classes that are found in the boot classpath, and since these are trusted classes, the validation process is not performed as for untrusted classes. In addition to the bootstrap class loader, the JVM has an extension class loader responsible for loading classes from standard extension APIs, and a system class loader that loads classes from a general class path as well as your application classes.

Since there is more than one class loader, they are represented in a tree whose root is the bootstrap class loader. Each class loader has a reference to its parent class loader. When a class loader is asked to load a class, it consults its parent class loader before attempting to load the item itself. The parent in turn consults its parent, and so on. So it is only after all the ancestor class loaders cannot find the class that the current class loader gets involved. In other words, a delegation model is used.

why spring framework came in java?

Why Spring Framework?

Below is a chart given which shows the comparison between Spring and various other Frameworks.

It was named Interface 21, as a reference to 21st century and released under Apache 2.0 license.

This was the first milestone release. Spring framework rapidly evolved since this release. Interface21 supported AspectJ parallely with Spring Framework.

New Features were added – extensible XML configs, support for Java 5 and dynamic languages, IoC extension points and AOP enhancements.

New features were added – support for Java 6/ JEE5, annotation configs, component auto-detection in classpath and OSGi compliant bundles.

New features were added – support for reorganized module system, SpEL, JavaConfig, embedded databases, REST support and support for Java EE 6.

Spring Data Commons Project was released. Later in 2012, Rod Johnson left the Spring team.

All Spring projects shifted to Pivotal. New features were added – full support for Java 8, websockets, higher third party library dependencies, groovy DSL for bean definitions.

It was compatible with Java 6, 7 and 8, with a focus on core refinements and modern web capabilities.

It will be the final generation within the general Spring 4 system requirements. 4.3.8 is the current version.

Reasons for Spring Frameworks’s popularity




There are generally three main reasons for Spring Framework’s popularity.




Simplicity

Testablity

Loose Coupling

Let’s discuss these topics in details.




Simplicity: Spring Framework is simple because its non-invasive as it uses POJO and POJI models.<>




POJO (Plain Old Java Objects): A Java class not coupled with any technology or any framework is called “POJO”.

POJI (Plain Old Java Interfaces): A Java interface not coupled with any technology or any frame work is called “POJI”.

Testablity: For writing the Spring application, server is not mandatory. But for struts and EJB applications, you need a server, if you want to test the application. It may need lot of changes in the source and to view those changes, each time you have to restart the server. This becomes tedious and time consuming. In case of Spring Framework, it has it’s own container to run the applications.




Loose Coupling : Spring Framework is loosely coupled because it has concepts like Dependency Injection, AOP etc. These features help in reducing dependency and increasing the modularity within the code. Lets understand this with an example.




Here I have a Bike interface which has a start() method. It is further implemented by three classes, namely : Yamaha, Honda and Bajaj.

What is the difference between a Spring singleton and a Java singeleton(design pattern)?

The Java singleton is scoped by the Java class loader, the Spring singleton is scoped by the container context.

Which basically means that, in Java, you can be sure a singleton is a truly a singleton only within the context of the class loader which loaded it. Other class loaders should be capable of creating another instance of it (provided the class loaders are not in the same class loader hierarchy), despite of all your efforts in code to try to prevent it.

In Spring, if you could load your singleton class in two different contexts and then again we can break the singleton concept.

So, in summary, Java considers something a singleton if it cannot create more than one instance of that class within a given class loader, whereas Spring would consider something a singleton if it cannot create more than one instance of a class within a given container/context.