对于2009年Java相关技术的变化，在这一点上，它与JavaOne大会给人的感觉非常类似，其中第一年充满了规范、标准和新框架，紧随之后的第二年就是规范的落实和前一年标准的成熟。在本篇文章中，我所提到的技术并不一定都是最新的，但是它一定是将被应用到现实开发中的。为了让文章更生动有趣一点，我不仅仅会列出我认为会日渐重要的技术，还将列出那些我认为将逐渐衰落的技术。
日渐重要的技术
1.Java内容仓库(JCR)
我认为，2008年是Java内容仓库技术在规范上取得成功的一年，而在2009年则将是它被广泛采用的一年。Jackrabbit是其中非常成功的一个实现。尽管在某些地方数据库可能更加符合要求，不过我发现目前在越来越多地方，仓库或许更加适合。最初的时候，Web内容管理系统似乎是唯一最适合Java内容仓库的领域，但是我认为这一情形将在2009得以改变。
另外，我将来可能会对使用诸如db4o之类的对象数据库更有兴趣。我认为对象数据库和仓库之间有一些类似之处，因此对象数据库如果日渐重要，也不是一件令人吃惊的事情。既然我们现在都在使用面向对象编程语言，为什么就不能使用一个对象数据库呢?
2.Flex
从一个开发者的角度来看，Flex在2008年已经变成一个重要的备选工具，但是它似乎还缺少一些来自企业用户的支持。我认为这个不足将在2009年得以弥补。
随着企业越来越接受富互联网应用(RIA)这个概念，它们也会发现Flex才是唯一真正切实可行的解决方案。就我个人来言，我更喜欢使用Flex来开发未来所有的Web应用。它与AIR联合使用可以离线运行Web应用，这无疑是锦上添花的一个功能。我一直感觉在桌面应用和基于浏览器的Web应用之间存在一段距离。事实证明，AIR弥补了这个空白。
最后，我非常喜欢它的完全将业务层与展现层分开的特点。这是RESTful服务的成功之处，而Flex对这一点可以很好的支持。那么，我们可以想创建多少客户端都可以，而不用管它们是使用Flex、Silverlight或传统的AJAX技术。
3.RESTful服务
当然这不是一个新技术，但是随着JAX-RS的发布，我认为在2009年企业将开始开发越来越多的RESTful风格的服务。
在2008年，SOAP网络服务和RESTful服务的比例大约是70：30或60：40，显然SOAP服务占据优势。但是我认为在2009年两者之间的比例将反过来。我甚至认为RESTful服务将实现更大的突破。
热议技术：云计算，软件即服务(SaaS)
众多IT巨头已经纷纷进军云计算领域，云计算的出现，恰好解决了SaaS发展过程中面临的一些问题，当SaaS提供商的客户快速增加到一定程度，客户所消耗的巨大资源将迫使SaaS供应商提供更多的硬件资源，但由于成本的问题，SaaS又不想花费大量资金购买硬件或带宽资源的时候，云计算无疑是个不错的选择。
穷途末路的技术
1.ESB的衰落
坦白的说，我已经彻底对失去了对“SOA需要ESB”说法的信心。我只在一个项目(使用Mule ESB)中感觉这个说法言之有理，我们具有需要同步的多个完全不同应用(数据库、命令行、服务)，Mule ESB证明了自己是这个问题的最完美解决方案。在其它项目中，我看到企业只是简单的使用一个ESB来代理/路由/监控服务请求。但是我可以使用Apache来完成这些任务。
而且，SOAP只是企业整合的途径之一，但并非唯一途径。另外，如果人们甚至没有任何企业整合需求时，又有多少人会实施SOA呢?
2.Web框架/AJAX的下滑
我曾经认为所有这些Web框架都是好东西，我喜欢尝试新产品，我喜欢具有创新性的事物。但是现在它们却让我感到厌烦。
先来说一下AJAX，的确你可以使用它来做出许多非常酷的东西，但是这些是否是你想要或真正需要的呢?很明显，人们没有从需要的角度来考虑其能实现什么功能，而只是为了实现这个功能而使用这个功能。不过我认为，如果你不能放弃你喜爱的Web框架，那你将不得不继续使用AJAX。
3.复杂的“组合”
这是Web框架下滑的一种延伸影响。我对到处充满各种“组合”的过去记忆深刻，我们有Hibernate、Struts和Spring。然后我们必须增加一个安全框架和Web服务客户端，诸如此类举不胜举。
我们最终得到的是一个相当复杂的组合，因为这样就有了一个真正模块化的应用程序，你可以使用其它同类技术来替换出特定的层。不过，这没有多大意义，这种需要很少发生。一旦一个组合被设定后，很少再会去修改它。现在我喜欢让我的应用程序尽可能的简单。我宁愿手动编写一些代码，也不愿意去增加另一个框架。
其它可疑技术：商业化开源，应用程序服务器
对于商业化开源这个业务模式，我没有异议，我怀疑的人们对它的期望太高，一个产品不能因为开源了就放松对其投入，这样会致使其体系架构变陈旧，代码质量下滑。
【编辑推荐】
