JAVAEE里面都包含啥?

Posted 2023-02-16

JAVAEE里面都需要学的内容都是什么ASP JSP 的一些东西吗?还有别的吗?请具体说说我需要真正明白的人因为我学了很久JAVASE是否是好的东西一看就知道了

Java EE 5是不是象Sun说的是Java EE史上最简单的版本，它将大大降低开发难度呢？Java EE 5面世后，企业该如何选择呢？以前使用J2EE1.4及以前版本的企业会升级到Java EE 5吗？

Java今年已经11岁了。在这11年里，被应用到了企业、桌面、Web、移动等各个领域。其中覆盖面最广的J2EE及相关产品被广泛应用到企业中。但从1999年诞生的第一个J2EE版本一直到 J2EE1.4总被人们不断地抱怨，这并不是因为它不够强大，恰恰相反，正是因为它太强大了，强大得让人难以使用。

Sun这些年也一直在试图改变这一切，但一直未能如愿。在2002年J2EE1.4推出后，它的复杂程度达到了顶点。尤其是EJB2.0，开发和调试的难度非常大。也许是Sun要下决心改变这一切，或者是受到市场和开发人员的压力，终于在今年5月份正式发布了J2EE5(现已经改名为Java EE 5)规范，并宣称Java EE 5将是Java EE史上最简单的版本，它将大大降低开发难度。但业界对此却表示怀疑。Java EE 5真的变简单了吗？这好像有点突然！Java EE在未来是否能走上一条简单的光明之路呢？

Java EE 5横空出世

Java EE 5终于在千呼万唤中诞生了。在今年的JavaOne会议上，Sun特意派去了一个宣讲团，对Java EE 5进行了大吹特吹，并称Java EE 5最大的改变就是简化开发。同时，还特别提到了EJB3.0可以通过Java最新提供的注释（annotations）以及其它一些特性来提高开发和测试的效率。Sun的鼓吹声还没有完全散尽，业界的嘘嘘声就此起彼伏。一位高级分析师，Richard Monson-Haefel，称Java EE 5虽然做了很多改进，但仍然无法克服它的庞大和复杂。这位高级分析师目前是EJB3.0规范的设计者之一，从Java EE 5的设计者口中说出这样的话，我想它的分量一定不轻。

也许Sun并不愿意听到这样的评论。但Monson-Haefel还是喋喋不休地数落着Java EE 5的种种不是。

Monson-Haefel说：“Java EE中的功能高度集成，我们将无法单独使用其中的一部分。而且许多Servlet、Java数据库和JavaServer Pages开发人员一般只使用Java EE的某些相关的特性。但Java EE规范要求必须使用所有的特性[APIs]。为了使程序可以正常运行，这些开发人员不得不建立一个复杂的工程来满足这些要求。这是因为Java EE仍然保持了上世纪90年代后期的编程方法，也就是说Java EE是以API为中心的”。Monson-Haefel甚至危言耸听地称“Java EE的应用已经走到了尽头！”。

也并不是所有的人都象Monson-Haefel这么悲观。一位JBoss公司的发言人说：“我们并不完全反对Burton集团高级分析师 Richard Monson-Haefel的关于平台复杂性的观点，但是没有人同意他关于Java EE的应用已经走到尽头的这个结论。”

IBM一向是Java的忠实支持者，也站出来为Java EE说话。Jim Knudson，作为IBM 的Java EE架构师，曾公开表示“虽然Java EE平台在使用上是有一些复杂，但这并不能成为我们放弃这个平台的理由”。

Java EE 5刚一问世，就引来了这么多的议论，当然，这些议论有好的，也有对Java EE 5不利的。那么Java EE的主要用户群：企业，该如何做出选择呢？

企业会为Java EE 5埋单吗？

Java EE 5面世后，企业该如何选择呢？以前使用J2EE1.4及以前版本的企业会升级到Java EE 5吗？

也许Monson-Haefel的一席话会吓倒很多企业。但Jim Knudson对此仍然很乐观。虽然他表示同意Java EE平台很复杂这一观点，但是他说某些复杂性是来自于用户的需求，并且我们要使用户达到他们期望的效果。他说IBM的那些预期实现SOA的用户都打算在 Java EE 5平台上面构建SOA。

JBoss产品管理部主管Ram Venkataraman也支持这样的观点：Java EE平台增加了复杂性是有必要的，因为需要使用它来处理各种服务，不仅仅是简单的调用关系数据库的Ajax风格Web服务，而且还有大容量事务处理的财务服务。

也许很多企业的负责人听了这些对Java EE 5赞扬的话，他们会迫不急待地尝试一下Java EE 5。这对于那些已经或即将搭建SOA构架的企业尤其重要。由于基于Java的SOA一般都是建立在J2EE服务器上，这就迫使企业必须做出是否升级到新版 Java EE的选择。

如果企业选择了Java EE 5，那可能会增加后续的成本。这是因为Java EE 5是基于Sun最新的JDK的，因此，Java EE 5增加了很多新的API。虽然这些API好象使Java EE 5变得更简单了，但开发人员必须要学习一整套新的编程模型持久化的API。而这些企业必须为此增加培训的费用。

其实Sun的初衷也是好的，只是简化Java EE的做法不妥。也许Sun还不明白，一味地增加功能并不能有效地简化Java EE的使用难度，有时还可能适得其反。如果Sun能够加一个用于开发的所见即所得（WYSIWYG）的拖放系统，那才叫真正地简化开发。而象这样增加很多的API，甚至将编程的思维方式都改变了，这样做并不能使Java EE平台变得更简单，而只是换汤不换药而已。

自从Sun将Java EE平台的设计移交给JCP后，对于Java EE逐渐增加的复杂性，JCP也难辞其咎。作为JCP的成员，Monson-Haefel和JCP的所有成员应该为Java EE 5变成今天这个样子而负责。实际上JCP的成员很早就和Sun的Java EE 5开发团队讨论过这个问题，但Sun表现得并不积极。这样看来，JCP和Sun都应该为此负一定的责任。

JCP的主管，Onno Kluyt却有不同的看法：“Monson-Haefel所看到的复杂性问题并不是JCP所负责的范围。JCP是一个制定标准的组织，并不是一个负责优化的组织，并不应该为Java EE 5的复杂性负责”。同时Kluyt还提到让Java EE 5变得更简单最好方法就是有一个好的IDE，简单是每个JSR所关注的，也是它们的中心任务。然而Java EE的开发者并不知道怎么去做。毕竟，Java EE是否简单，它的开发人员并没有发言权，而最有发言权的是那些使用Java EE的人。”

Java EE：路在何方

也许上面的喋喋不休使我们的头都大了，但我们可以不必管它。最后还得让Sun来盖棺定论。终于，Sun公司负责企业Java平台的副总裁Karen Padir为Java EE 5作了比较中庸的阐述：“平台当然要复杂了，因为它是应用服务器的规范。而且，应用服务器是很复杂的，因为复杂性的存在主要是为了开发人员能够在应用服务器上工作，但是应用程序的开发人员并不一定会涉及到复杂性，因为他们仅仅使用那些完成工作所必需的工具就可以了。开发人员可以忽略他们所不需要的复杂性”。

就象微软的Office一样，虽然复杂，但并不是所有的人都会涉及到所有复杂的功能。因此，Java EE并没有我们想象的那样复杂。反而通过JDK5的支持，在某些应用的性能上，如Web Services，会有很大的提高。因此，如果企业要建立新的应用（尤其是SOA），还是可以考虑Java EE 5的。对于那些已经使用多年的系统来说，升级时得要慎重一些。不过，从总体来说，Java EE 5还是非常不错的。 参考技术A 1.JavaEE就是我们常说的J2EE。J2EE核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共通的标准及规格，让各种依循J2EE架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容。
2.对于开发者来说主要的对J2EE框架的应该。
3.常用的主流J2EE应用框架：struts、hibernate、spring等。当你会用以上主流框架之后我想其它的框架你也应该有所了解了吧 ^_^ 参考技术B asp 是.NET里面的
你加我吧 我告诉你 我是个编程的
81474617 参考技术C 每一种语言都有其自身的特点，只有掌握了其自身的特点，才能用它编写出高效的程序。下面就我个人实践所知谈谈javaSE方面的性能问题，
javaEE方面的性能暂不讨论，要是时间可以再写一javaEE方面的性能问题的帖子。

1， 尽量不要使用+号来连接字符串。
2， 对小数据int的Integer封装，尽量的使用Integer.valueOf()创建，而不要使用new来创建。因为Integer类缓存了从-128到256个 状态的Integer。
3， 对Boolean类，要用valueOf()或使用Boolean.TRUE或Boolean.FALSE来创建对象。我个人觉得对Boolean类用private构造函数，可能就会避免不好的使用Boolean类了。
4， 在设计类时应尽可能地避免在类的默认构造函数中创建，初始化大量的对象。
5， 合理的申请数组空间，如果数组中所保存的元素占用内存空间较大或数组本身长度较长的情况，我们釆用可以釆用软引用的技术来引用数组，以“提醒”JVM及时的回收垃圾内存，维护系统的稳定性。
6， 避免创建重复的对象，我们在编写一个方法的时候应该先考虑方法里的局部对象域能否改为private static final，从而避免创建重复的对象。
7, 把try/catch块放入循环体内，会极大的影响性能，如果编译JIT被关闭或者你所使用的一个不带JIT的JVM，性能会将下降21%之多!
8，StringBuffer的构造器会创建一个默认大小(通常是16)的字符数组。在使用中，如果超出这个大小，就会重新分配内存，创建一 个更大的数组，并将原先的数组复制过来，再丢弃旧的数组。在大多数情况下，你可以在创建StringBuffer的时候指定大小，这样 就避免了在容量不够的时候自动增长，以提高性能。
9, 使用Java NIO提高服务端程序的性能。
10，考虑用静态工厂方法替代构造函数。
11，在对大量的数组拷贝时，可以考虑用Arrays.copyOf()来拷贝。
12, 在并发的情况下，要合理的选择同步的策略，应该谨慎的控制synchronized块的大小，不可以将一个操作分解到多个synchronized 但也要尽量地从synchronized块中分离耗时的且不影响并发的操作。
13，要合理的选择集合框架，例如：ArrayList和LinkedList在某些不同的场合，其性能相差很大。对要做大量的插入时，LinkedList 的性能比ArrayList的性能好。对要做大量随机查找的时候用ArrayList的性能比用LinkedList的性能好。还有在不需要并发操作的 情况下，选择非线程安全的集合比线程安全的集合要好。如在非线程安全的要求下，选择ArrayList要比Vector好。
14，如果是想把数据封装成Double类型的，不要这样使用new Double("1.23")，而要应这样使用new Double(1.23),虽然二者都没有语法 的错误，也都能达到预期的结果，但其性能有着很大的差异。
15, 应尽量的通过缓冲流类来提高I/O操作效率,但也要合理的选择缓冲大小 。
呵呵，好了，今天就写到这吧，以后要是有时间再继续写。小弟我初学java，不对之地，欢迎大家指正，补遗。