保持领先
VMware 提供培训和认证,为您的进步注入动力。
了解更多招聘信息是衡量技术实际采用情况的良好指标。它们表明公司是否正在花钱,从而能够区分实质内容和炒作;它们表明开发人员获取和发展相关技能的重要性(这是技术永续发展的重要因素);它们还为公司采用特定技术的安全性提供了很好的指导。
因此,作为招聘信息聚合网站 Indeed.com 的 jobtrends 网站是一个重要的资源。它允许跟踪一段时间内招聘需求的数量趋势,并便于比较各种技术。
有时,这些趋势可能具有戏剧性的影响。Indeed.com 显示,在 2007 年 11 月,Spring 在 Java 招聘信息中作为技能要求超越了 EJB。截至昨天,Spring 的相关职位数量为 5710 个,而 EJB 为 5030 个。
比较绝对职位数量,我们可以看到趋势线以及它们交叉的位置
考虑到大量的遗留 EJB,这令人惊叹。据推测,现在很少有新项目使用 EJB 了。
比较各自增长率的“相对”图表更加有趣,显示了这两种技术之间的鲜明对比
我们看到 EJB 的需求停滞不前或正在下降,而 Spring 的需求正以不断增长的速度增长。
当然,Spring 和 EJB 并非互斥。使用 Spring 并不会妨碍您使用 EJB,反之亦然。在某些情况下,EJB 提供的有用服务可能是使用 Spring 的应用程序所需要的。在不使用 Spring 的情况下使用任何版本的 EJB 都意味着放弃许多宝贵的额外能力。事实上,很大程度上是支持 EJB 的游说者(出于某种原因)将这两种技术视为直接竞争对手。
这两种技术之间的重叠是显著且不断增长的,但增长速度不及 Spring 需求增长的速度
虽然这不是一个完全对等的比较,但将 Spring 和 EJB 视为企业 Java 应用程序核心组件模型的替代方案是合理的。而且很明显,现在哪一个正在崛起。
我必须承认有一定的个人满足感,考虑到我自 2003 年初以来一直在预测 EJB 将成为遗留技术,并且在 此之前 就认为 EJB 被过度使用。在 《不用 EJB 的 J2EE》 一书中,我详细分析了 EJB 模型的缺点以及它如何未能实现其既定目标或满足开发者和客户的需求。那时,这样的说法极具争议性。
EJB 3.0 在一定程度上有所改进,但仍然太少、太迟:其 DI 能力低于实际世界所需的证明;拦截 API 认识到需要解决横切关注点,但提供的解决方案是目前为止最无能、最笨拙且最容易出错的(这是我一直想写博客的主题);它背负着与现已无关的上一代技术向后兼容的包袱;完整的 EJB 合同(比“简化编程模型”长数百页)规定了一个复杂且开销过大的运行时环境;尽管有语法糖,它未能解决 EJB 中的许多缺点,例如启动操作、单例和过时的线程模型。最后,在基础设施不断变化的时代,它实际上与应用服务器环境紧密绑定。
我可以滔滔不绝地讲述这些缺点,但招聘数字反映了数千家公司的实际经验和结论。
请注意,我这里谈论的是会话 Bean 和消息驱动 Bean;JPA 现在是一个独立的规范,基于现代技术,并且正在证明其价值。
EJB 的衰落对整个行业以及个人开发者意味着什么?
坦白说,EJB 时代是个反常现象。EJB 未能解决本世纪初的问题;对于未来的问题,它更加不适用。EJB 的大多数最初前提现在已被否定;该规范对向后兼容性的坚持并不能为其带来的权衡付出代价辩护。它的衰落是进入一个崭新、更流畅的世界的自然结果,在这个世界中,OSGi 等技术以及朴实的 Servlet API 被证明更加相关。当然,由于绝对数字仍然很高,EJB 不会在短时间内完全消失。但趋势线清楚地表明,它正在成为遗留技术。
在我们宣布 SpringSource Spring 认证计划 之前,招聘要求中出现这一里程碑是及时的。现在 Spring 是市场上如此重要的技能,对于雇主和开发者来说,有一个明确衡量 Spring 知识的标准非常重要。
关于 Spring 发展势头的进一步证明,最近由行业领先网站发布的 2007 年统计数据给出。在 ServerSide 上,排名前 5 的文章中有 2 篇 关于 Spring,其中包括排名第一的文章。在 InfoQ 上,排名前 10 的文章中有 3 篇关于 Spring,其中排名第一的文章(我的 Spring 2.0 Update)的页面浏览量是下一篇最受欢迎文章的 4 倍。