7

The difference that I read on the Internet between Java EE and Java SE classloading is that

In Java SE, a classloader delegates the classloading to its parent classloader and then tries to load the class itself

However, In Java EE, a classloader first tries to load the class itself and then delegate the classloading of that class to its parent classloader.

Kindly validate my understanding.

Also, why is it designed like that in Java EE (Any advantages of keeping it like this.)

This is the link where I heard this [http://www.youtube.com/watch?v=t8sQw3pGJzM]

Mike Braun
  • 3,729
  • 17
  • 15
Sunny Gupta
  • 6,929
  • 15
  • 52
  • 80
  • 1
    Related http://stackoverflow.com/questions/4199158/java-ee-class-loading-standard (but if you found a place that says the order described above is mandated, please include the link. the SO answer seems to disagree). – fvu Aug 13 '13 at 13:29
  • @Gamb I have already gone through this link. But didn't get the idea. Still there is a confusion. BTW thanks for sharing the link. – Sunny Gupta Aug 13 '13 at 13:29

2 Answers2

12

Alright then,

A common application has 3 standard classloaders:

  1. Bootstrap Classloader
  2. Extensions Classloader
  3. System-Classpath Classloader

So far, so good. Now, this works for a single application running alone and free.

But what happens when you say J2EE? You have multiple applications running on the same place, so you have to figure out a way to prevent them from stumbling on each other. That's where these extra classloaders come into play.

Think about a server instance. There's a JBoss with two deployed EARs. What would happen if there were to be conflicting classes between applications? They're ok on their own particular context but as a whole they're inconsistent.

These extra classloaders are introduced in an application-wise way to ensure the isolation between them. Classloaders below System-Classpath Classloader recognize a class only if it is specified in the manifest file for one of its childs.

In J2SE, the three basic classloaders work in a parent-child relationship based on three principles:

  1. Delegation: If a class is not loaded (cache), the request is delegated to its parent. This goes on until the top of the hierarchy (Bootstrap classloader) who loads basic J2SE related classes (i.e. Integer, ArrayList, amongst others). This is what you reference in your question: A classloader delegates the loading until the top of the hierarchy, then each classloader tries to load the class if its parent couldn't find it, until someone loads it. Otherwise: ClassNotFound.
  2. Visibility: Classes loaded by a parent classloader are visible to its children, not the other way around.
  3. Uniqueness: If a parent classloader loads a class, a children will never reload it.

In Java SE, a classloader delegates the classloading to its parent classloader and then tries to load the class itself.

True, due to the principles explained above.

There's no determined classloader structure in J2EE (a vendor has "poetic license" to implement it), but they kind of follow a hierarchy. In this case, the System-classpath classloader loads the main application: The server. The server libraries (its classes, more specifically) are available, then, to every application due to the visibility principle.

Down there, the applications have particular classloader structures, but as a whole they are different children of the System-classpath classloader. Each application loads its related and particular classes (both application and libraries).

The loading here is not propagated to the parents outside the application context. Why? because if the System-classpath classloader were to load the applications as usual, the class of every application would be visible to others due to the visibility principle, completely breaking the isolation between themselves. So:

However, In Java EE, a classloader first tries to load the class itself and then delegate the classloading of that class to its parent classloader.

This is partly true, but I'd rather limit this affirmation to the context of an application and leave out the Java related classes, that are indeed loaded by the top level classloaders.

Long story short: It's not a straightforward process but I wouldn't go as far as to say J2EE handles the classloading the opposite way around of J2SE.

Fritz
  • 9,987
  • 4
  • 30
  • 49
  • My question is somewhat different, I already know about J2SE classloading but is it different from J2EE classloading or not. That is what my question is. Thanks. – Sunny Gupta Aug 15 '13 at 12:53
  • @John I understood your question, that's why I described the difference between both of them. Of course they are different, in a J2EE context you have to ensure application isolation. Being completely strict, they are different because they handle the classloading in a different way (J2EE has more classloaders involved and the handling is done differently). – Fritz Aug 15 '13 at 14:22
  • Ok thats nice, But nowhere you talked about the order of classloading in J2SE and J2EE, what I am trying to ask mainly in the question. – Sunny Gupta Aug 15 '13 at 14:53
  • @John You asked: *Kindly validate my understanding* and: *Also, why is it designed like that in Java EE (Any advantages of keeping it like this.)*. I tried to fuse both answers into one by describing the processes. No worries, I'll put it in simpler and more explicit terms, then. – Fritz Aug 15 '13 at 15:28
  • Is there any classes that are being shared between System-classpath classloader and the application specific classloader? – Sunny Gupta Aug 15 '13 at 17:15
  • Would you please explain this line "I'd rather limit this affirmation to the context of an application and leave out the Java related classes"? – Sunny Gupta Aug 15 '13 at 17:16
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/35534/discussion-between-john-and-gamb) – Sunny Gupta Aug 15 '13 at 17:17
1

I think Java EE class loading standard will help you on your way. As far as I know there is no mandated way of classloading for standard Java. For WebApps (WARs) however, it is specified that the classloading is parent-last.

Community
  • 1
  • 1
Robin van Breukelen
  • 527
  • 4
  • 17