我相信Java EE Java堆栈实际上非常好。有几个原因可以解释Java EE的低生产力：
- 作为“企业堆栈”，它通常用于创建无聊，丑陋，“足够好”的应用程序，并且一般来说，企业往往不会吸引喜欢编程，思考和关心他们所做的事情的优秀开发人员。企业世界中的软件质量并不高。
- 作为有钱的企业堆栈，软件供应商试图向他们出售一些东西。他们创造了巨大，复杂和昂贵的解决方案，不是因为它们很好，而仅仅是因为他们可以将它们出售给企业。
- 企业往往非常规避风险，他们做得更好的一切都被“标准化”。标准是在一些技术被证明是成功的之后或之前创建的。在这两种情况下，它对企业（和Java）都是不利的。企业最终要么使用好的技术太晚，要么使用彻底失败的技术。后一种情况也非常危险，因为它会产生一种错误的感觉，即如果一项技术（否则是完全失败的）是标准化的，并且每个人都在使用它，那么它一定是好的。
- 从历史上看，Java EE平台似乎吸引了许多架构宇航员和大公司的开发人员，他们被提升为架构师，他们的唯一目的是创建更多的层，更多的框架，更多的抽象和更多的复杂性。
这并不是说没有好的Java工具和框架;而是有太多的坏标准，太多过度设计的，太多的官僚主义流程和方法，太多无用的标准。
在这样一个混乱的世界里，影响你生产力的不仅仅是你选择的工具。这主要是关于你，关于你的价值观，关于你如何拒绝社区，供应商，同事和经理向你提出的大多数解决方案。这是关于你违背潮流，关于你的常识，关于你质疑每一个主流信念和“最佳实践”。
也就是说，仅靠工具不会改变你的生产力，相反，合适的人也可以使用劣质工具提高生产力。
我的建议：
- 不要仅仅因为某种技术是标准的，因为每个人都在使用它，或者因为它是Sun正式推荐的。只有当你个人认为某种技术是你工作的最佳工具时，才使用它。通过这种方式，您可能会发现自己拒绝了诸如JSF，JSP，Web服务，JMS，EJB，JTA，OSGi，MDA之类的技术。
- 保持简单，运用你的常识，质疑一切。是否确实需要发布对象以进行远程访问？你真的需要创建另一个抽象层，以便你可以从Hibernate切换到TopLink吗？您是否真的需要在每次需要时将数据转换为 XML 十次/从 XML 转换数据？您真的需要 XML 架构吗？你真的需要所有东西都是可配置的可互换的吗？在运行时？由非开发人员？
- 保持流程简单。保持敏捷。你真的需要那个文档吗？你真的需要描述一个巨大的表格中的每个屏幕，让它得到批准，把它输入到一些自制的工具中，然后生成JSP吗？您是否拥有称职的程序员，或者您首先设计所有内容，而程序员只“翻译”到Java？
- HTML的所见即所得设计不起作用。
- 图形化编程通常不起作用。这包括UML作为蓝图和UML作为编程语言，MDA，绘制页面流程图。代码生成很糟糕。
- 永远不要在使用之前设计一个框架，总是收获一个框架。
- 首选只有很少 XML 配置的框架。
- 力求降低 LOC 计数。查看代码中的实际字符。每个角色都重要吗？想。你能做些什么来缩小你的代码？你需要那门课吗？它有什么作用？为什么需要这样做？
- 测试不是神圣的牛;您不需要100%的测试覆盖率。仅测试有意义的内容。如果很难测试，请使其更简单;或者根本不测试它。不要测试视觉外观。
最后，一些具体的Java建议：
- 对于表示层，请尝试 Tapestry。我为什么喜欢它？因为使用Tapestry，您可以创建漂亮的代码。它是专门为此设计的，因此您的代码可以很漂亮。您的代码。我说的美丽是指所有重要的东西 - 它简短，易于更改，易于阅读，易于创建抽象，并且仍然灵活，它不会试图掩盖您正在为Web开发的事实。当然，仍然是你让你的代码变得美丽。
- 随意使用休眠，特别是对于CRUD和大型应用程序。不要为JPA而烦恼。不过，这不是一个银弹，使用ORM，你总是会用另一组问题交换一组问题。
- 只有一点点春天，你应该不需要太多，因为你已经小心翼翼地避免了所有的Java EE陷阱。谨慎使用依赖关系注入。
- 在所有这些之后，您可能会发现Java语言过于冗长，并且在抽象出复制/粘贴代码时不是很有帮助。如果你想尝试，试试Scala。问题在于，Scala的主要卖点是，你既能获得现代语言的所有好处，又能保持类型安全，同时，没有坚实的IDE支持。习惯于超酷的Java IDE，除非有稳定可靠的IDE支持，否则切换到Scala没有多大意义。足够稳定是不够的。
