TL;DR

:::success 说明
基于互联网档案馆,维基百科,整合知乎等各个平台的资料,提炼出一些我认为重要的事情(提炼🤔算得上吗🤣?),简单的介绍Java的发展 :::

产生背景

1990年前后

  • 网络条件已经成熟,至少在美国是的
    • 距离TCP/IP协议得到美国国防部的肯定,成为多数计算机共同遵守的一个标准,已经过了6年。
    • Tim Berners-Lee提出web,发布了浏览器(当然这时候跟Java还八竿子打不着)
  • 系统多样,硬件多样,UNIX系统的分支多如牛毛,Windows也发布了几年

image.png

产生过程

说法1

Java 语言最开始只是Sun微系统(Sun MicroSystems)公司在1990年12月开始研究的一个内部项目。Sun微系统公司的一个叫做帕特里克·诺顿的工程师被公司自己开发的C++和C语言编译器搞得焦头烂额,因为其中的API极其难用。帕特里克决定改用NeXT,同时他也获得了研究公司的一个叫做“Stealth计划”的项目的机会。

  • Sun公司在1990年的时候,主要是做系统的,这时候还没Linux🤣
  • 在1990年的时候,已经有了cpp,Sun公司有人在倒腾cpp和c的编译器,但是做出来效果不好用

    “Stealth计划”后来改名为“Green计划”,詹姆斯·高斯林和麦克·舍林丹(Mike Sheridan)也加入了帕特里克的工作小组。他们和其他几个工程师一起在加利福尼亚州-门罗帕克市-沙丘路的一个小工作室里面研究开发新技术,瞄准下一代智能家电(如微波炉)的程序设计,Sun微系统预料未来科技将在家用电器领域大显身手。

  • Sun公司认为,嵌入式系统将在未来家用电器领域大显身手 有想法

  • 造一个给家电用的控制系统,至少是为这个方向探探路吧得到需求

    团队最初考虑使用C++语言,但是很多成员包括Sun微系统的首席科学家比尔·乔伊,发现C++和可用的API在某些方面存在很大问题。

  • 自己整的CPP和C不好用,满足不了需求使用的工具满足不了需求

    工作小组使用的是嵌入式系统,可以用的资源极其有限。很多成员发现C++太复杂以至很多开发者经常错误使用。他们发现C++缺少垃圾回收系统,还有可移植的安全性、分布程序设计、和多线程功能。最后,他们想要一种易于移植到各种设备上的平台。

  • 缺少GC 缺点

  • 不易于移植 缺点
  • 缺失多线程能力 缺点
  • 易于移植到各种设备上的平台 使用的工具满足不了需求,想办法解决

    权衡可用资金后,乔伊决定开发一种新语言,他提议在C++基础上开发一种面向对象的环境。于是,高斯林试图通过修改和扩展C++已有功能来满足要求,但后来他放弃了。他决定创造一种全新的语言——Oak(橡树)。他们都具有不将就精神,在具有资金的支持下不断寻求创新。

  • 最初打算修改

  • 修改还是不好用,自己造

    就像很多开发新技术的秘密工程一样,工作小组没日没夜地工作到了1992年的夏天,他们能够演示新平台的一部分了,包括Green操作系统,Oak的程序设计语言,类库及其硬件。最初的尝试是面向一种类PDA设备,被命名为Star7,这种设备有鲜艳的图形界面和被称为“Duke”的智能代理来帮助用户。1992年12月3日,这台设备进行了展示。

  • 伴随着造的设备,系统一起,Oak出来了 :::danger Oak的起源
    这儿得提一下,参考中文维基关于Java词条的说法,如上所说,是来自于1990年12月公司内部的一个项目
    但是在英文维基中关于Oak词条(指Java前身的那个)的说法,Sun早在1985年就有在做开发用于”编写下一代智能程序“的新技术 的尝试。
    > In 1985, Sun Microsystems was attempting to develop a new technology for programming next generation smart appliances, which Sun expected to be a major new opportunity.
    关于Oak产生的具体时间,英文维基的Oak词条指出是89年就有了(我不太相信)。起源于Sun公司的机顶盒项目,是否这个就是上面所提到的”Stealth”计划(即后来的Green计划)?🤔
    > Oak is a discontinued programming language created by James Gosling in 1989, initially for Sun Microsystems‘ set-top box project. The language later evolved to become Java). The name Oak was used by Gosling after an oak tree that stood outside his office.
    所以Oak到底产生于什么时候还需要再去考证。
    在互联网档案馆里面找到上面关于star7的视频,https://archive.org/details/Star7Demo_201905
    其中确实提到Green项目的时间是1991年~1992年

所以时间线大概是?🤔
85年有打算,然后90年前后开启Stealth计划->91年改名Green,开始实施->92年出成果Oak+star7 :::

92年11月,Green计划被转化成了“FirstPerson有限公司”,一个Sun微系统的全资子公司,团队也被重新安排到了帕洛阿尔托。FirstPerson团队对建造一种高度交互的设备感兴趣,当时代华纳发布了一个关于电视机顶盒的征求提议书时,FirstPerson改变了他们的目标,作为对征求意见书的响应,提出了一个机顶盒平台的提议。但是有线电视业界觉得FirstPerson的平台给予用户过多的控制权,因此FirstPerson的投标败给了SGI。与3DO公司的另外一笔关于机顶盒的交易也没有成功,由于他们的平台不能在电视工业产生任何效益,公司被并回Sun微系统。

  • 造的东西没效益

    时间来到1994年夏天,互联网和浏览器的出现不仅给广大互联网用户带来福音,也给Oak语言带来了新的生机。高斯林立即意识到,这是一个千载难逢的机会,于是对Oak进行了小规模改造,他们认为随着Mosaic浏览器的到来,因特网正在向同样的高度互动的远景演变,而这一远景正是他们在有线电视网中看到的,到了1994年秋,小组中的诺顿(Naughton)和乔纳森·佩恩(Jonathan Payne)完成了第一个Oak语言的网页浏览器——WebRunner,后来改名为HotJava。 1994年10月,HotJava和Java平台为公司高层进行演示,得到高度评价。1994年,Java 1.0a版本已经可以提供下载。

  • 但是造的轮子还有用啊🤣

  • 因为Oak商标已注册,改名java

    Java和HotJava浏览器在1995年3月23日SunWorld大会上公开发布,这个发布会与网景(Netscape)合作,网景宣布将在其浏览器中包含对Java的支持。

  • Java正式发布

  • emmm,这时候网景还考虑发明一种与Java搭配使用的辅助脚本语言并且语法上有些类似的语言,即之后的JS(所以,从JS起源的视角来看,有时候讲段子Java和JS的关系,类比雷锋和雷峰塔的关系,是不准确的,不过放到现在,也说得过去)
  • 距离JavaScript原型(5月)的产生还有两个月

    Java发展

    在Java语言出现之前,互联网网页实质上就像一张纸,不会有任何动态内容。有了Java语言后,浏览器的功能被扩大了,Java程序可以直接在浏览器里运行,可以直接与远程服务器交互。用Java语言编程,可以在互联网上像传送电子邮件一样方便地传送程序文件!

  • 这么看Java在当时是很先进的

    Java发布几个月之后,竟有10万多人次访问了太阳公司的网页,下载Java语言。然后,互联网上立即就有了数不清的Java小程序(Applet),演示着各种小动画、小游戏等。

  • Java发布之后很火 :::danger 这儿存疑,这时候没发布JVM,那么一次编写,到处运行的口号是无法实现的,无法做到平台无关。
    但是如果考虑到,这时候Java主要用来做Applet,用在浏览器里面,浏览器里面内建了对Java的支持,这时候是纯解释执行的,应该是说得过去的。 :::

    JDK 1.0

    Sun公司虽然推出了Java,但这只是一种语言,如果想开发复杂应用程序,必须要有一个强大的开发类库。因此,太阳公司在1996年年初发布了JDK 1.0。 这个版本包括两部分,运行环境JRE和开发环境JDK。 运行环境JRE包括核心API、集成API、用户界面API、发布技术、JVM 5个部分。 开发环境包括编译Java程序的编译器(即Javac命令)+开发类库+JRE。

  • 1.0 的JVM,纯解释执行

  • AWT(GUI工具库)
  • Applet

    这时候Java主要应用就是网页上的Applet以及一些移动设备。到了1996年年底,Flash面世了,这是一种更简单的动画设计软件,使用Flash几乎无须任何编程语言知识,就可以做出丰富多彩的动画。随后Flash增加了ActionScript编程脚本,Flash蚕食了Java在网页上的地盘。

  • Flash开始抢占Applet的市场

    JDK 1.1

    97年初发布JDK1.1

  • 反射机制

  • 内部类
  • AWT事件模型
  • JAR文件格式、JDBC、JavaBeans、RMI等
  • Java在浏览器网页编程的市场被抢占

    JDK 1.2(J2SE 1.2)

    98年底,Sun公司发布了Java历史上最重要的JDK版本,JDK 1.2,开始使用Java 2这一名称,我们已经极少使用JDK 1.1版本,因此我们所说的Java一般从Java 2开始。J2EE提供了企业应用开发相关的完整解决方案。这标志着Java已经吹响了向企业、桌面和移动三个领域进军的号角,这个时期也是Java高速发展的时期。在Java 2中,Java发生了很多革命性的变化,而这些革命性变化一直沿用至今,对于Java的发展形成了深远影响,直到今天还经常看到J2EE、J2ME等名称。

  • JDK 1.2 特性

    • JVM中内置JIT
    • Swing GUI库
    • 类库方面,在这个版本添加Java集合类
  • 将Java分成三个版本
    • J2SE(Java 2 Standard Edition),标准版
    • J2EE(Java 2 Enterprise Edition),企业版
    • J2ME(Java 2 Micro Edition),微型版,主要面向嵌入式设备

指针->J2SE,JavaEE,JDK等名词的关系

99年12月,J2EE 1.2 发布

  • JSP规范
  • Servlet规范
  • JavaBean规范

    JDK 1.3(J2SE 1.3)

    2000年5月,JDK 1.3发布,添加一些新类库

  • HotSpot JVM

  • Java Naming and Directory Interface (JNDI)
  • Java Platform Debugger Architecture (JPDA)
  • JavaSound
  • Synthetic proxy classes

    2001年9月,J2EE 1.3发布

  • JSR 58:JavaTM 2 Platform, Enterprise Edition 1.3 Specification

    JDK 1.4(J2SE 1.4)

    2002年2月,JDK 1.4发布,标志着Java真正走向成熟的一个版本,Compaq、Fujitsu、SAS、Symbian、IBM等著名公司都有参与功能规划,甚至实现自己独立发行的JDK 1.4。哪怕是在近二十年后的今天,仍然有一些主流应用能直接运行在JDK 1.4之上,或者继续发布能运行在1.4上的版本。

  • JSR 59:J2SETM Merlin Release Contents

    • 正则表达式
    • 异常链
    • 日志类
    • XML解析器
    • XSLT转换器
    • NIO

      2003年11月J2EE 1.4发布

  • JSR 151:JavaTM 2 Platform, Enterprise Edition 1.4 (J2EE 1.4) Specification

    JDK 5(J2SE 5.0)

    2004年9月 JDK 5发布

  • 从这个版本开始放弃了JDK 1.x的命名方式,将产品版本号修改成了JDK x

  • JSR 176:J2SETM 5.0 (Tiger) Release Contents

    06年5月,Java EE 5发布

  • 从这个版本,改变J2SE这种的命名,因此J2EE 5也就转为JavaEE 5这种命名

  • JSR 244:JavaTM Platform, Enterprise Edition 5 (Java EE 5) Specification
    JDK 6(Java SE 6)

    06年12月,JDK 6发布

JDK 6 发布之后,Sun开源了Java形成了openJDK项目

  • JSR 270:JavaTM SE 6 Release Contents
  • 一些改进,提供动态语言支持,同步垃圾回收。
  • J2SE命名方式 改成Java SE 6
  • 开源出现openJDK
  • 09年4月Sun被Oracle收购

    09年12月,Java EE6 发布

  • JSR 316:JavaTM Platform, Enterprise Edition 6 (Java EE 6) Specification

    JDK 7(Java SE 7)

    11年7月,JDK 7发布

  • JSR 336:JavaTM SE 7 Release Contents

    最终,JDK 7包含的改进有:提供新的G1收集器(G1在发布时依然处于Experimental状态,直至2012年4月的Update 4中才正式商用)、加强对非Java语言的调用支持(JSR-292,这项特性在到JDK 11还有改动)、可并行的类加载架构等

13年6月,Java EE 7 发布

  • JSR 342:JavaTM Platform, Enterprise Edition 7 (Java EE 7) Specification

    JDK 8(Java SE 8)

    14年3月,JDK 8 发布 从JDK 8开始,Oracle启用JEP(JDK Enhancement Proposals)来定义和管理纳入新版JDK发布范围的功能特性。JDK 8提供了那些曾在JDK 7中规划过,但最终未能在JDK 7中完成的功能。

  • JSR 337:JavaTM SE 8 Release Contents

    • JEP104:内置Nashorn JavaScript引擎的支持。
    • JEP122:彻底移除HotSpot的永久代。
    • JEP126:对Lambda表达式的支持,这让Java语言拥有了流畅的函数式表达能力。
    • JEP150:新的时间、日期API。
    • More…

      17年9月,Java EE 8 发布

  • JSR 366:JavaTM Platform, Enterprise Edition 8 (Java EE 8) Specification

    JDK 9 - JDK 11

    JDK 9以后,JDKOracle宣布每六个JDK大版本中才会被划出一个长期支持(Long Term Support,LTS)版,只有LTS版的JDK能够获得为期三年的支持和更新,普通版的JDK就只有短短六个月的生命周期。JDK11,JDK17是LTS,Spring表示SpringBoot3基于JDK 17,下一个LTS在JDK 23。

  • JDK9——JSR 379:JavaTM SE 9 Release Contents

    • JEP200:模块化,module-info.java,我还没搞明白,说是包的容器
    • JEP222:jshell: The Java Shell (Read-Eval-Print Loop),类似于交互终端
    • JEP269:集合工厂方法,直接传一批数据,得到一个不可变的集合
    • More…
  • JDK10——JSR 383:JavaTM SE 10 (18.3)
    • JEP286:局部变量支持类型推断,var
    • JEP307:G1垃圾收集器优化
    • JEP316:使 HotSpot VM 能够‎‎分配‎‎用户指定的内存设备(如 NV-DIMM)上的 Java 对象堆。‎
    • JEP317:使 Graal VM能够当作 Linux/x64 平台上的实验性 JIT 编译器。‎
    • More…
  • JDK11——JSR 384:JavaTM SE 11 (18.9)

    • JEP330:单文件源码程序直接运行,免除中间手动编译即,如java HelloWorld.java就可以看到结果。
    • JEP332:TLS1.3
    • JEP333:ZGC
    • JEP335:将Nashorn JS引擎标记为弃用,在后续版本移除,若有需要以Graal VM替代
    • More…
      JDK12 - JDK 17
  • JDK12——JSR 386:JavaTM SE 12

  • JDK13——JSR 388:JavaTM SE 13
  • JDK14——JSR 389:JavaTM SE 14
    • JEP343:打包工具jpackage(孵化中)
    • JEP359:records(preview),给POJO对象用的,但是还不能取代Lombok的@Data注解
    • JEP361:switch语法拓展(标准化)
    • JEP363:移除CMS GC
    • JEP368:文本块(second preview)
    • More…
  • JDK15——JSR 390:JavaTM SE 15
  • JDK16——JSR 391:JavaTM SE 16
  • JDK17——JSR 392:JavaTM SE 17

JDK12-JDK17所有改进->Here

More
  • JDK 18:JSR 393:JavaTM SE 18
  • JDK 19:JSR 394:JavaTM SE 19
  • Discussion

    JCP,JSR,JEP是什么
    JCP(Java Community Process)Java社区流程
    98年建立,根据JCP官网所言,JCP是一种为Java技术制定标准技术规范的机制。也就是 制定各个版本 Java SE规范的机制。
    JSR(Java Specification Requests)‎Java规范请求
    JSR就是每个就是JCP中具体的规范的请求,官网中提到:任何人都可以注册该站点并参与审查和提供 Java 规范请求 (JSR) 的反馈,任何人都可以注册成为 JCP 成员,然后参与 JSR 的专家组,甚至提交自己的 JSR 提案。
    JEP(JDK Enhancement Proposals)JDK改进提案
    是openJDK社区采用的流程,JEP 1 中对JEP的作用做了说明 :::success

    The primary goal of this process is to produce a regularly-updated list of proposals to serve as the long-term Roadmap for JDK Release Projects and related efforts. The Roadmap should extend at least three years into the future so as to allow sufficient time for the most complex proposals to be investigated, defined, and implemented.
    这个流程的主要目标是生成定期更新的提案列表,作为发布JDK项目和相关工作的长期路线图。提案至少有三年的时间,以便有足够的时间对大部分复杂的提案进行调研、定义和实现。

A secondary goal of this process is to define a uniform format and a central archive for enhancement proposals so that they are easy for all interested parties to find, read, comment upon, and contribute to. Proposal documents evolve as work upon them progresses so that, in the end, a completed proposal serves as an authoritative, though not necessarily self-contained, record of what was changed and why.
第二个目标是为改进提案定义统一格式和中心化的归档存储,以便所有人都可以轻松地查找、阅读、评论和贡献。随着工作的推进,提案不断改进,最终会成为一份包含了更改和原因的权威性记录。

This process is open to every OpenJDK Committer. Decisions about specific proposals will be made in a transparent manner but are ultimately up to the OpenJDK Lead.
这个过程面向所有openJDK Committer,具体提案的决定将以透明的方式作出,但最终由OpenJDK牵头。

This process does not in any way supplant the Java Community Process. The JCP remains the governing body for all standard Java SE APIs and related interfaces. If a proposal accepted into this process intends to revise existing standard interfaces, or to define new ones, then a parallel effort to design, review, and approve those changes must be undertaken in the JCP, either as part of a Maintenance Review of an existing JSR or in the context of a new JSR.
这个流程不会以任何形式取代JCP,JCP仍然是所有标准Java SE API和相关接口的管理机构。如果在JEP中有提案打算修改现有标准接口或定义新接口,则必须在JCP中同时进行对应的设计、审查和批准这些更改的工作。 :::

也就是说,JCP通过JSR制定java SE标准,JEP则对JavaSE进行实现,JEP也会对JCP进行反哺。

J2SE,Java SE等名词与JDK的关系

在Java刚出来的那段时间,Java是Sun提供的,没有开源,没有标准,那么能够提供JDK的也就是Sun。
就只有JDK
在JDK1.2 的时候,Sun说分三个平台,J2SE,J2ME,J2EE。
J2SE定义了一些标准规范,对应版本的JDK则实现了这些规范,在那种语境下,因为是一对一的关系,所以说,用J2SE去指代对应版本的JDK是正常的,也不会出现歧义。实现的JDK叫 Java 2 Standard Edition Development Kit。
再往后,J2SE改名Java SE
Sun在09年开源了Java SE,开启openJDK项目,之后Sun被Oracle收购。
Oracle发布自己的JDK,openJDK社区也可以发布自己的JDK,这时候再说Java SE是对应版本的JDK,就有歧义了。
有了openJDK,我改一下JVM,对里面的类库进行修改,替换。再打个包,这就是我发行的JDK。
我认为,简而言之,Java SE 是标准,JDK实现(应该没错的🤔

Java SE 与Java EE

每次发布的时候,JavaSE 带了一个对应的JDK。
Java EE 是对Java SE的扩充,定义了了一些高级API和编程模型,如servlet,jsp等。
从发布时间上来看,JavaEE 发布的时间要比同版本的JavaSE晚一年,发布的时候,JavaEE也会带有对应版本的JDK。在以前,这个JavaEE是要付费的吧?🤔
因此Java EE实现的JDK可以视为是JavaSE JDK+ 框架,类比Spring这样的框架。区别就是Spring是第三方,要自行引入,而JavaEE 是官方的,JDK自带。
但是现在的Web开发,Spring占了半壁江山,JavaEE没市场,所以Oracle才会开源JavaEE吧

JavaEE 与 Jakarta EE

17年oracle开源JavaEE,把JavaEE移交给eclipse基金会,成立EE4J来管理,但是又不让用JavaEE的名号🤣,所以Eclipse就把Java EE的名号改成Jakarta EE(就不能起个好记一点的吗?☹️,比如jvav EE,ಥ_ಥ)
在JCP社区里面查JSR,可以看到JavaEE的规范提案,只到了Java EE 8,没有更高的版本,关于JavaEE平台的最近的一个JSR也是2018年4月的。

Jakarta EE现状
  • 2019年9月发布 JakartaEE 8 ,兼容 JavaEE 8
  • 2020年9月发布 JakartaEE 9 ,基于 Java SE 11(版本号就不能对齐吗☹️?
  • JakartaEE 10 正在开发中,预计在22年9,基于Java SE 11, 从Release plan 来看,这个版本是改名jakarta EE以来的第一个主要版本(LTS)

官网给出的定位是“一个云原生时代开发,构建,部署企业级微服务的开源技术栈”,我很好奇未来与Spring体系的竞争
不过Jakarta EE没发布对应的JDK,只有规范。。。起码JavaEE的时候,还有对应的JDK啊,可能是要集成的东西太多,所以这些包都分开发布了🤔?
它在2020年的调研中,表明自己在云原生这块占有率有35%(what?!!🧐,难以相信,他2019年才发布第一个版本,即使前身有JavaEE,但是这么多的份额,怎么可能?后来一看,参与调研人数只有几百人,emmm,可信度不高)

JavaEE 与 Spring 等第三方库

传言Spring曾加入JCP一段时间,后来退出了。Spring实现了部分JavaEE的规范,形成了JavaSE + Spring体系,慢慢发展出来的东西越来越多,也没有完全按规范来(JavaEE规范跟不上),社区发展出来了许多东西,Spring就成了与JavaEE平行的东西,从结果来看Spring成了事实标准,还有自己的实现。

Java EE 和 Spring 之间的关系已经进入了“最好的敌人”模式。 Spring 诞生于 2004 年,由 Rod Johnson 发起,作为对 J2EE 和 EJB 2 复杂性的反击。从那个时候开始,Spring 和 Java EE 之间就没有停止过竞争,并彼此影响对方:

  • Spring(以及 Hibernate)的出现刺激了 Java EE 社区,促使他们推出了 EJB 3 和 JAP 1.0。
  • Spring Batch 直接影响到了 Batch 规范(JSR 352)。
  • Spring Dependency Injection 启发了 CDI(Context and Dependency Injection)。
  • Spring 恰到好处地使用了 J2EE 和 Java EE 中的某些标准,如 Servlet、JMS 和 JPA。
  • Spring 5 宣称兼容 Java EE 8。

从诞生之日起,Spring 就因为超强的实用性受到了开发者的青睐,而且它的演进速度很快,可以快速地集成新技术:NoSQL、AMQP、微服务、云原生应用…… 从 2006 年开始,Java EE 也将提升易用性和对开发者的友好放在首位,但在演进速度方面还是很慢,主要有两个原因:

  • JCP 制定规范需要很长时间:即使是一个轻量级的规范,也需要多方参与,需要更长的时间才能达成一致。
  • 实现和认证:在规范发布之后,需要几个月时间才能找到符合认证的应用服务器。

而最近,这方面的差距在加大:

  • Spring Boot 将“约定大于配置”的原则发挥到了极致,进一步提升易用性。
  • Spring Cloud 利用 Netflix 的开源组件解决了与云原生应用开发相关的问题,如服务注册、服务发现、弹性、负载均衡、监控……
  • Spring 5 将反应式编程提升为一等公民。

Java EE 在这方面的速度要慢的多。在 2013 年发布 Java EE 7 之后,经历了一段消停期。2016 年,在社区的压力下,Oracle 才发布了一个新的路线图。 除了监管和技术之外,EE4J 必须为自己找到合适的位置,因为没有了 JCP 的支持,它作为标准的地位就不复存在。在这样的情况下,EE4J 已无力与 Spring 展开竞争。或者说,整个 Java 生态系统经不起这样的“内战”。Java 在应用服务器方面的霸主地位已经一去不复返,它必须与其他平台展开竞争,比如 Node.js、Go 和 Python。如果能够将整个社区甚至整个行业的力量带动起来,那就更好了。 为什么不呢?如果 EE4J 能够推出一些独立的兼容规范,Spring 团队就可以参与进来,让 Spring 成为 EE4J 的主要参与者。

总结
  • Java SE由JCP维护
  • openJDK通过JEP实现Java SE
  • Java EE 移交Eclipse基金会改名Jakarta EE
  • Jakarta EE由EE4J通过JESP维护
  • Spring与Java EE是相互影响的竞争关系