我在 Internet 上看到的 Java EE 和 Java SE 类加载的区别在于
在 Java SE 中,类加载器将类加载委托给其父类加载器,然后尝试加载类本身
但是,在 Java EE 中,类加载器首先尝试加载类本身,然后将该类的类加载委托给其父类加载器。
请验证我的理解。
另外,为什么它在 Java EE 中是这样设计的(保持这样的任何优点。)
这是我听到这个的链接 [http://www.youtube.com/watch?v=t8sQw3pGJzM]
我在 Internet 上看到的 Java EE 和 Java SE 类加载的区别在于
在 Java SE 中,类加载器将类加载委托给其父类加载器,然后尝试加载类本身
但是,在 Java EE 中,类加载器首先尝试加载类本身,然后将该类的类加载委托给其父类加载器。
请验证我的理解。
另外,为什么它在 Java EE 中是这样设计的(保持这样的任何优点。)
这是我听到这个的链接 [http://www.youtube.com/watch?v=t8sQw3pGJzM]
那么好吧,
一个常见的应用程序有 3 个标准类加载器:
到现在为止还挺好。现在,这适用于单独运行且免费的单个应用程序。
但是当您说J2EE时会发生什么?您有多个应用程序在同一个地方运行,因此您必须想办法防止它们相互绊倒。这就是这些额外的类加载器发挥作用的地方。
考虑一个服务器实例。有一个带有两个已部署 EAR 的 JBoss。如果应用程序之间有冲突的类会发生什么?他们在自己的特定背景下没问题,但作为一个整体,他们是不一致的。
这些额外的类加载器是以应用程序的方式引入的,以确保它们之间的隔离。System-Classpath 类加载器下的类加载器只有在清单文件中为它的一个子类指定时才能识别一个类。
在 J2SE 中,三个基本类加载器基于三个原则以父子关系工作:
Integer
ArrayList
在 Java SE 中,类加载器将类加载委托给其父类加载器,然后尝试加载类本身。
确实,由于上述原理。
J2EE 中没有确定的类加载器结构(供应商拥有实现它的“诗意许可”),但它们有点遵循层次结构。在这种情况下,System-classpath类加载器加载主应用程序:服务器。然后,由于可见性原则,每个应用程序都可以使用服务器库(更具体地说是它的类) 。
在那里,应用程序具有特定的类加载器结构,但作为一个整体,它们是System-classpath 类加载器的不同子代。每个应用程序都加载其相关的特定类(应用程序和库)。
此处的加载不会传播到应用程序上下文之外的父级。为什么?因为如果System-classpath类加载器像往常一样加载应用程序,由于可见性原则,每个应用程序的类对其他人都是可见的,完全打破了它们之间的隔离。所以:
但是,在 Java EE 中,类加载器首先尝试加载类本身,然后将该类的类加载委托给其父类加载器。
这在一定程度上是正确的,但我宁愿将这种肯定限制在应用程序的上下文中,而忽略 Java 相关的类,这些类确实由顶级类加载器加载。
长话短说:这不是一个简单的过程,但我不会说 J2EE 以与 J2SE 相反的方式处理类加载。
我认为Java EE 类加载标准会帮助你。据我所知,标准 Java 没有强制的类加载方式。然而,对于 WebApps (WARs),它指定类加载是 parent-last。