Java EE和Java SE类加载

我在互联网上阅读的Java EE和Java SE类加载的区别在于

在Java SE中,类加载器将类加载委托给其父类加载器,然后尝试加载类本身

但是,在Java EE中,类加载器首先尝试加载类本身,然后将该类的类加载委托给其父类加载器。

请validation我的理解。

另外,为什么它的设计与Java EE中的设计相同(保持这种优势的任何优点。)

这是我听到的链接[http://www.youtube.com/watch?v=t8sQw3pGJzM]

好吧,那么,

一个常见的应用程序有3个标准的类加载器:

  1. Bootstrap类加载器
  2. 扩展程序类加载器
  3. System-Classpath类加载器

到现在为止还挺好。 现在,这适用于单独运行且免费运行的单个应用程序。

但是当你说J2EE时会发生什么? 您有多个应用程序在同一个地方运行,因此您必须找到一种方法来防止它们相互绊倒 。 这就是这些额外的类加载器发挥作用的地方。

想想服务器实例。 有一个JBoss有两个部署的EAR。 如果应用程序之间存在冲突的类,会发生什么? 他们对自己的特定背景感到满意,但总的来说它们是不一致的。

这些额外的类加载器以应用程序方式引入,以确保它们之间的隔离System-Classpath Classloader下面的类加载器仅在类的一个子项的清单文件中指定了类时才识别它。

在J2SE中,三个基本类加载器基于三个原则在父子关系中工作:

  1. 委派:如果未加载类(缓存),则将请求委派给其父级。 这一直持续到层次结构的顶层( Bootstrap类加载器)加载基本的J2SE相关类(即IntegerArrayList等)。 这是您在问题中引用的内容: 类加载器将加载委托给层次结构的顶部,然后每个类加载器尝试加载该类,如果其父级无法找到它,直到有人加载它。 否则:ClassNotFound。
  2. 可见性:父类加载器加载的类对其子项是可见的,而不是相反。
  3. 唯一性:如果父类加载器加载一个类,子项将永远不会重新加载它。

在Java SE中,类加载器将类加载委托给其父类加载器,然后尝试加载类本身。

是的,由于上面解释的原则。

J2EE中没有确定的类加载器结构(供应商具有实现它的“诗意许可”),但它们遵循层次结构。 在这种情况下, System-classpath类加载器加载主应用程序:服务器。 由于可见性原则 ,服务器库(更具体地说,它的类)可用于每个应用程序。

在那里,应用程序具有特定的类加载器结构,但作为一个整体,它们是System-classpath类加载器的 不同子代。 每个应用程序加载其相关的和特定的类(应用程序和库)。

此处的加载不会传播到应用程序上下文之外的父项。 为什么? 因为如果System-classpath类加载器像往常一样加载应用程序,由于可见性原则,每个应用程序的类对其他应用程序都是可见的,完全打破了它们之间的隔离。 所以:

但是,在Java EE中,类加载器首先尝试加载类本身,然后将该类的类加载委托给其父类加载器。

这部分是正确的,但我宁愿将这种肯定限制在应用程序的上下文中,而忽略了Java相关的类,这些类确实是由顶级类加载器加载的。

简而言之:这不是一个简单的过程,但我不会说J2EE处理类似于J2SE的相反方式的类加载。

我认为Java EE类加载标准将帮助您。 据我所知,标准Java没有强制的类加载方式。 但是,对于WebApps(WAR),指定类加载是父级的。