Java EE要死掉了?
最近有人问我说: 欣哥, 我们现在都用Spring, Hibernate, SpringMVC了,这Java EE是不是已经死掉了?
这个问题让我哭笑不得,因为他似乎还没有搞清楚Java EE到底是怎么回事,就给Java EE判了死刑。
Java EE是什么呢?
简单来讲Java EE 就是一个技术规范的集合,一些核心的技术规范包括:JDBC, Servlet, JSP, JNDI, EJB, RMI, XML , JMS , JTA, JPA,JavaMail 等等。 这些规范的目标很美好, 就是帮助程序员开发大规模的、分布式的、高可用的“企业级”应用, 只是实际的效果可能就没那么美好了。
我们先来看一看这些核心的技术规范都是干嘛的,然后再来评判Java EE是不是快要死掉了。
JDBC : Java程序访问数据库的核心技术,不管是使用Hibernate , MyBatis, EJB, 还是自己写类库, 只要你访问数据库, JDBC是绕不过去的, 我还没见过在Java 中用其他技术读取数据库的案例。
(参见文章:《JDBC的诞生》)
Servlet : 简单地说,Servlet就是Web应用让外界访问的入口。 当然现在直接写Servlet的越来越少, 因为在框架的包装下,应用程序只需要直接写Action 或者 Controller就可以了, 但这并不能否定Servlet的核心和基石地位。
JSP & JSTL: 由于前后端的分离和其他更优秀的替代技术,现在用JSP当做视图层也是凤毛麟角了, 更多的是在遗留系统中在使用, JSP确实在走向没落。
JSTL 是JSP Standard Tag Library, 一套标准的标签库, JSP不受人待见,JSTL就更不行了。
(扩展阅读: 《JSP:一个装配工的没落》)
EJB : 曾经最为热门的技术, 寄托了大家最美好的期望,但事实证明EJB 1.x 2.x 简直就是灾难, EJB3.x 虽然吸收了Hibernate的很多优秀特性,奈何大家使用轻量级类库和框架的习惯已经养成, 无法翻身了。
更要命的是使用EJB需要昂贵、复杂、笨重的应用服务器(如Weblogic, Websphere等), 这也是使用它的巨大障碍,再加上Spring 这个轻量级框架的崛起, EJB被彻底打入冷宫。
RMI : 远程方法调用, 让Java程序可以像访问本地对象一样来访问远程对象的方法, 早期和EJB搭配用的最多, 因为EJB会被部署在分布式的应用服务器中, 一个机器上的程序需要访问远程的EJB,RMI是个基础的技术。 随着EJB的失宠, RMI似乎也用的很少了。
RMI应该是RPC的一种实现,只能在Java 世界中使用, 相对于被广泛使用的基于Web、 基于HTTP的RPC调用, RMI更不受待见。
(参见文章《我是一个函数》)
JNDI: 这是一个基础性的技术, 可以把名称和对象进行绑定,最常见的就是通过一个名称来访问数据源,而不用关心这个数据源到底在什么地方。 依然在广泛使用。
JAXP: XML在Java 中无处不在,Java EE 通过Java API for XML Processing(JAXP)来读取/解析XML文件,只是这个接口实在是不太好用,学院派气息过浓, 所以现在大家都用民间开源的JDOM,DOM4J 了。
等到JSON开始流行, “悲剧”又重演了,大家都在用民间的fastjson, jackson , 似乎选择性的忘记了 官方的 Java API for JSON Processing。
官方的不如民间的,也是Java世界的一大特色。
JMS: Java世界访问消息队列的标准方式, 各大消息队列产品都支持, 没有理由不用它。
(扩展阅读《Java帝国之JMS的诞生》)
JavaMail : 在Java中发送邮件,又一个基础性的技术。
JTA: Java Transaction API, 主要是为了在多个数据源之间实现分布式事务, 但是JTA在在高并发和高性能的场景下表现不佳, 很多时候并没有用JTA, 而是用异步的方式来解决问题。
(扩展阅读:《Java帝国之宫廷内斗(上)》 《Java帝国之宫廷内斗(下)》)
除了上面列举的,Java EE还有很多规范
Java API for WebSocket
Java Persistence
Concurrency Utilities for Java EE
Java EE Connector Architecture
Java API for RESTful Web Services (JAX-RS)
Java API for XML-Based RPC (JAX-RPC)
Java Management Extensions (JMX)
JavaBeans Activation Framework (JAF)
......
这些规范在日常的Web开发中可能用的更少,SSH/SSM 中也可以找到对应物, 给大家的感觉就是这Java EE的规范没用了, 要死掉了。
我倒是觉得应该是Websphere , Weblogic这些应用服务器不行了, 从上面的描述中可以看到,活得最滋润的几个是JDBC, Servlet, JMS, 最不如意的就是EJB了, 而EJB恰恰是昂贵的商业应用服务器Weblogic , Websphere 的一个核心功能。
在云计算的环境下, 在容器技术、微服务当道的情况下, 那种集中式的、繁琐的、笨重的部署注定要走向消失。 现在很多后端开发,用Tomcat这种主要支持Servlet/JSP的Web服务器,再配上轻量级的SSH,或者SSM就足够了。
说了这么多,可能有人想到这个问题: 这些规范是怎么制定的的呢?
答案是JCP(Java Community Process), 在这个组织中,一些特定的成员(Full Memeber)如果想把某个技术如JDBC变成Java 规范,就需要发起一个叫做Java Specification Request (JSR) 东西,公开让大家进行评判, 最后由执行委员会投票,决定是否可以发布成为正式规范。
理论上每个人都能够成为JCP的成员, 但是有发言权的, 能上桌玩牌的还是一些巨头,如Oracle, Google, IBM, SAP等等,所以有很多人认为JCP制定出来的Java EE规范只是考虑大厂商的利益, 不顾普罗大众的死活, 这种脱离人民群众的规范是没人用的, 是要死掉的。
这么说确实有一定的道理, 我个人觉得Java EE规范中有一些精华会保留下来,被一直使用,直到Java退出历史舞台。 至于其他的Java EE规范, 就让他们自生自灭去吧。
(完)

浙公网安备 33010602011771号