我有这位朋友......
我有这个朋友在2000年初开始的java ee应用程序（j2ee）应用程序上工作。目前，他们在这里和那里添加了一个功能，但是有一个很大的代码库。多年来，该团队缩减了70％。
[是的，“我有这位朋友”。这是我，试图幽默地将少年高中辅导员的羞耻注入混合中]
Java，Vintage 2002
应用程序使用EJB 2.1，struts 1.x，DAO等直接jdbc调用（存储过程和预准备语句的混合）。没有ORM。对于缓存，它们使用OpenSymphony OSCache和本地缓存层的混合。
在过去的几年里，他们一直在努力使用UI实现UI的现代化 ajax技术和库。这主要涉及javascript库 （jquery，yui等）。
客户端
在客户端，缺少从struts1到struts2的升级路径阻止了他们迁移到struts2。其他Web框架变得流行（wicket，spring，jsf）。 Struts2不是“明显的赢家”。将所有现有的UI从Struts1迁移到Struts2 / wicket /等似乎并没有以非常高的成本提供太多的边际收益。他们不希望拼凑出各种技术 - 两种技术（Struts2中的子系统X，Wicket中的子系统Y等），因此开发人员使用Struts 1编写新功能。
服务器端
在服务器端，他们考虑转向ejb 3，但从未有过大的推动力。开发人员都熟悉ejb-jar.xml，EJBHome，EJBRemote，“ejb 2.1原样”代表了阻力最小的路径。
关于ejb环境的一个大抱怨：程序员仍然假装“ejb服务器在独立的jvm中运行而不是servlet引擎”。没有任何应用服务器（jboss / weblogic）强制执行此分离。该团队从未在应用服务器的单独盒子上部署ejb服务器。
ear文件包含同一jar文件的多个副本;一个用于'web层'（foo.war / WEB-INF / lib），另一个用于服务器端（foo.ear /）。 app服务器只加载一个jar。重复会造成歧义。
缓存
至于缓存，它们使用多个缓存实现：OpenSymphony缓存和自行开发的缓存。 Jgroups提供群集支持
现在是什么？
问题： 该团队目前有多余的周期来投资现代化应用程序？聪明的投资者会在哪里花钱？
主要标准：
1）提高生产力。特别是减少了开发新子系统功能和减少维护的时间。 2）性能/可扩展性。他们不关心时尚或技术的街头信誉。
你们都推荐什么？
在持久性方面
将所有（或仅新开发）切换到JPA / JPA2？
直接冬眠？
等待Java EE 6？
在客户端/网络框架方面： 迁移（部分或全部）到struts2？ 便门？ JSF / JSF2？
至于缓存： 红陶？ 的Ehcache？ 相干？ 坚持他们拥有的东西？ 如何最好地利用64位jvms提供的巨大堆大小？
提前致谢。
答案 0 :(得分：7)
答案 1 :(得分：3)
让我这样做的工具是Spring（当时的v1.2）。当您从Spring中删除所有流行语时，您剩下的就是一个简单的框架，用于集成不同的应用程序组件，从而可以更轻松地将这些组件交换为替代方案，随时进行现代化。
例如，Spring为您提供integration with Struts 1，从而可以更轻松地将Struts 1组件引入“Spring方式”。您的Struts应用程序应该像以前一样运行，但现在它们已经具备了从下到上实现现代化的杠杆作用。
接下来，Spring的数据访问抽象将允许您插入现有的JDBC DAO，并开始引入DA抽象，以使它们更容易实现现代化。如果你选择坚持使用JDBC，那很好，Spring提供了extensive JDBC support来让它感觉不那么石器时代。如果你想修改JPA或Hibernate，那么这些将与Spring管理的应用程序集成，就像JDBC一样容易。
对于EJB，Spring可以wrap the EJB access layer进入一些不那么史前的东西，使它们更容易吞下。一旦您将客户端层与EJB数据访问的细节隔离开来，如果您选择，您可以使用更简单的Spring管理组件（具有任何远程处理，事务，安全性或无）替换EJB（一次一个） （如果你选择的话），或者你可以保留EJB（也许使用EJB3）。
总之，让Spring接管应用程序“backbone”的角色，同时开始使用您已有的相同遗留组件。然后，您可以按照自己的速度和风险增加现代化的自由度。
这并不容易，但有了一些耐心和毅力，你就可以到达你想去的地方而不会有太多的干扰。
答案 2 :(得分：1)
好的，这里的答案不要求用不同的语言重写或学习弹簧并编写2000行XML。建议你的朋友尝试在glassfish v3中部署应用程序，EJB 2.1可以工作（并且可以使用任何新的EE 6代码）。
展望未来，他们现在可以在EJB 3.1中开发新代码，并且可以在闲暇时重构旧的EJB 2.1代码。
他们可以继续使用Struts或者慢慢地将新代码迁移到JSF / Wicket / ???
同样适用于JPA，虽然他们的领域模型可能需要在一个大爆炸或许多小爆炸中发生，但是按照自己的节奏转移到JPA 2。
缓存？ EclipseLink（JPA 2 RI）有一些相当不错的缓存。 Read more
最重要的是这个布丁有证据。我刚刚在glassfish v3中部署了一个遗留的EJB 3 + Struts 1.3应用程序，不仅工作简单（我花了很多精力就是将它从jdeveloper项目移到了netbeans项目中），但它的基础很好开始重构EE 6，我们打算这样做，因为要求提供错误或功能。
基本上这归结为“如果没有破坏就不要修复它”。为什么改变工作（虽然很旧）的代码？让它继续存在，在EE 6中编写新功能，如果某个功能涉及到旧代码，请考虑将它重构为EE 6。
最重要的是，与此相关的努力将部署到glassfish v3 ......
答案 3 :(得分：0)
如果我是你，我会从测量开始。也许采取一些典型的操作，最好是那些在高负载或其他情况下烦人用户的操作，将他们的路径切换到某些阶段并测量每个步骤消耗多少时间。一旦你找到一个需要很长时间的步骤，你可以缩小范围直到你有可能的罪魁祸首。如果它是数据库访问，也许缓存可以帮助等。你可能会发现一些简单的旧优化，但这也没关系，对吧？
如果您运行的是较早版本的应用。服务器，然后我建议升级它。它通常具有更好的性能/可伸缩性，并且在JBoss的情况下它更有意义，因为更好的支持（可以更容易地找到信息/人力资源）。
对于EJB2.1到EJB3的迁移，我测试了EJB3依赖注入与EJB2.1 JNDI查找，它更快，更快。也许摆脱EJBHome的东西也让事情变得更快，尽管我不确定。一旦你完全迁移到EJB3，你将拥有JPA，并且很容易让ehcache工作，我可以告诉你，ehcache非常有效。 （我不知道它与你现在使用的那个相比如何......）
答案 4 :(得分：0)
我理解你朋友的痛苦:)。
然而，更新，更有光泽的框架并不一定能让您的终端用户的生活更美好，毕竟这就是您所付出的代价。有些问题已经出现了一段时间，缓存数据以加快速度，自动将请求参数连接到方法调用，管理事务，将相关组件联系在一起......多年来人们已经开发了“足够好'实施。
我的感觉是，框架交换机只有在带来很多改进的情况下才值得付出代价。例如，如果切换到其他东西使AJAXify您的应用程序，那么它可能是值得的。但是你必须让最终用户感受到这种改进。
我的建议是开始将您的业务模型与其他任何东西（DAO，UI，事务管理......）分离，然后引入新框架（ORM？）会更容易。即使它最终不起作用，您也可能通过解耦来提高代码库的质量。
答案 5 :(得分：0)
老实说，你可能只是重做grails中的整个事情，并且比2002年花费的时间快20倍;）
对于我绝对需要使用真正Java堆栈的项目，我坚持使用Spring 3.0和 Hibernate 3.5。您甚至可以使用Roo快速启动项目，如果您不再需要它，请将其关闭。使用像IntelliJ这样的想法来快速编码。
不幸的是，我不得不说这不再富有成效了。虽然它对于原始Java来说很棒......但是，除非你绝对需要Java提供的所有功能，否则原始Java就会很糟糕。
另外，Ajax对Spring来说非常糟糕。如果你想在你的MVC中使用数据库映射，你必须对自定义杰克逊反序列化器进行编码...所以你必须解析原始的JSON。这太糟糕了，春天人们已经意识到了这个问题。祝你好好快速看到高级修复。
我曾经嘲笑Ruby on Rails的人......但是我得把它交给他们，他们做对了。对于中小型项目，它确实有效。如果你想要Java堆栈的可扩展性，Grails是一个很好的解决方案。
如果你真的，真的，真的不想朝那个方向前进，那么只需使用带有Hibernate 3.5的现代化Spring 3.0即可。