Java在发行以后迅速的获得了关注，大量的公司，不管大的，还是小的，都想成为这个令人兴奋的新的软件平台的一部分。 在最初的日子里，IBM迅速的参与了进来，他们通过建立了一个由IBM和苹果公司合资成立的 Taligent 公司，最初是要开发一个面向对象的应用框架。Taligent 在国际化方面也颇具优势，为JDK1.1 贡献了不少的类（比如像
java.text 包 和
微软也成为了一个Java的被许可方，它把Java集成进了Internet Explorer的早期版本里。微软的实施造成了不小的麻烦，导致了 一场长期且旷日持久的官司，这场官司在于争论微软是如何破坏了他们的证书许可协议条款。这场官司最终在Sun公司的帮助下解决了，但是也从根本上促使了对C#语言的提升发展。
在1997年左右，Sun微系统公司感觉有很大的压力，如何将Java的标准化工作交给一个著名的国际标准化组织，比如 ANSI或者 ECMA. Sun并不热衷于做这件事情，是基于两点原因。首先，他将会把Java平台的控制权转给其他人，Sun已经意识到Java对于他们的价值非同小可，当然是基于市场的考虑，而并非纯粹的利润而言。
第二个原因则是 更多考虑Java如何随着时间的推移快速的进化。标准化流程可以视为一个频谱，其中一端是一个用友完全控制权的单一的公司，而另一端则是一个完全开放的过程，所有参与者都有平等的发言权。 这两个都有有事和弱点。如果Sun公司继续单独的控制着Java的开发，开发者们则只能简单被动的接受Sun公司的产品管理者认为的最好的特性。如果Sun公司将Java转交给像ANSI这样的组织，那么开发的速度将会受到影响。开放的国际化的标准组织在开发和批准标准上是臭名昭著的缓慢（ANSI 在过去的26年里仅仅只产生了3个版本的C标准！）
Sun公司的管理层决定开发Java规范的最好方式是创立一个新的标准实体，它的流程就是在频谱的两端之间。 在10月份发布了最初的建议稿之后，Sun公司在1998年12月8日又正式地发起了Java社标准组织 (JCP)， 也就是在当天也同时发布了JDK 1.2。它也同时利用此机会将Java 更名为 Java 2，并引入了不同“版本”的概念，详述如下：
- Java 2 Micro Edition (J2ME) ，是为了移动和嵌入式设备使用；
- Java 2 Standard Edition (J2SE)，覆盖了整个语言、核心类库以及JVM；
- Java 2 Enterprise Edition (J2EE)，是为了企业级应用，在一个应用服务器容器中开发像servlets或者Enterprise Java Beans (EJBs)之类的组件（谁说微服务是新事物来着？）
JCP的最初结构中包含两个执行委员会 (EC)，他们的职责是通过过程的关键点来审批规范段落。 其中一个EC负责J2ME，另外一个则是负责J2SE 和 J2EE。在2012年八月份，他们被合并为一个EC，用于处理Java所有的标准化活动。
Today, under JCP rules Version 2.10 the EC is formed of the following:
- 16 ratified seats
- 6 elected seats
- 2 associate seats
- 1 permanent seat for Oracle America
Members serve 2-year terms that are staggered so that 12 of the 24 seats are normally up for ratification or election each year. The latest version of the JCP charter also removed the requirement for membership fees. The current goal is clearly to increase membership and therefore participation from the community.
Changing Java through the JCP
Any full member of the Java Community Process can submit a Java Specification Request (JSR), which consists of a variety of information about the proposed specification including a description of what it will standardise, estimated dates for development and why it is required. The EC votes on the JSR and, if accepted, the process of developing the standard begins.
To do this an Expert Group (EG) is formed from full JCP members or member representatives who are interested in helping to develop the specification. The specification lead (typically the person who submitted the JSR, but this can change over time) decides who to accept for the EG. Once the EG has created the specification it is published for public review before the JCP membership votes for its approval.
The deliverables of a JSR consist of three parts and make up the “golden triangle” of the JCP:
- The formal specification
- A Reference Implementation (RI) of the specification
- A Test Compatibility Kit (TCK)
The diagram below shows the relationship of these three parts.
Initially, the JCP saw a storm of activity with many JSRs being filed, expert groups created and specifications defined. At the time of writing, there are 380 JSRs listed on the JCP website with a further 27 maintenance JSRs covering existing specifications.
Another mechanism also exists for accepting and tracking changes to the Java platform: that of JDK Enhancement Proposals (JEPs). Sun finally released the source code of it’s Java Development Kit (JDK) in 2006 under an open source license and started the OpenJDK project to manage this. The Java SE specification defined through the JCP only covers the Java language, virtual machine and class libraries. JEPs cover any modification to the JDK, which may lead to changes being passed into relevant JSRs. As we will see later, these have recently become a topic of some debate.
The Java Specification Participation Agreement
Another important part of the JCP, which I have not mentioned so far, is the Java Specification Participation Agreement (JSPA, pdf). This is significant because it covers the intellectual property (IP) rights associated with JSR specifications. Initially, the JCP did not provide any way for independent implementations of JSRs so there was no ability to produce open source versions.
At JavaOne in 2002, the big announcement was that the Apache Software Foundation (ASF) was joining the Java SE/EE EC. It was also announced that all current and future JSRs led by Sun would be made available under a license that allowed for open source implementations.
Section 5 of the new JSPA covered outbound IP and ensured that the specification lead granted a perpetual, royalty-free, irrevocable license for copyrights and patents covering the specification to anyone who wished to create an independent implementation of the specification. In order to qualify for this, the implementation would have to fully implement the specification, not modify, subset or superset the specification and pass the TCK.
Harmony Strikes the Wrong Chord
For some years the JCP ran smoothly with a wide variety of JSRs submitted, specifications written and both commercial and open source implementations created.
On September 30th, 2004 Java 2 SE 5.0 was launched. This included significant changes to the Java language syntax and also changed the numbering scheme of Java once again. To indicate the level of change to the platform the release number was moved forward to 5.0. Through the JCP, the release contents were specified in JSR 176, which was an “umbrella” JSR. This specification defined contents that also included elements specified by other JSRs, for example generic types from JSR 14, annotations from JSR 175, etc.
Then things got more complicated.
Enter Project Harmony
In May of the following year, a new incubator project was created by the ASF whose goal was “architecting and implementing J2SE 5”. This was known as Project Harmony. For some time prior to this announcement proponents of Free and Open Source Software (FOSS) had wanted the source code of Java to be freely available with an open source license. Sun had resisted this call for a variety of reasons; not least of which was the sheer amount of work that due diligence would require to enable them to release the source code under an open source license, but also, as we’ll see, because of how Sun made money from Java.
Since Java’s specifications were freely available from the JCP, in theory, it would be possible to produce a “clean room” implementation that could be distributed free of Sun’s binary licensing terms. The most significant of these was the Field-of-Use (FoU) restriction. The FoU essentially said that Java could be used freely (i.e. without paying Sun a licensing fee) as long as it was used on “General Purpose Desktop Computers and Servers”.
At this time, the only place that Sun made any revenue directly from Java was licensing Java Card (a tiny subset of Java that ran in only a few kilobytes of RAM) and Java 2 ME, which was used by mobile phone manufacturers. Sun wanted to protect this (not insignificant) revenue stream.
Work on an open source version of Java had started back in 1998 in the form of the GNU Classpath project, but that had only focused on the standard class libraries of Java, not the virtual machine. Project Harmony intended to produce a complete open-source Java runtime environment.
Unfortunately, this is where the problems started. In order for an implementation of JSR 176 to be granted free use of all necessary IP and for it to be called Java that implementation must pass all the tests in the TCK. In August 2006 the ASF approached Sun to gain access to the TCK for JSR 176 (to make things a little more confusing the TCK, in this case, is also referred to as the Java Compatibility Kit (JCK)). Despite the announcements made at JavaOne in 2002, Sun would only provide the TCK/JCK to Apache under certain licensing restrictions. These restrictions meant that any implementation tested would still be constrained by a FoU very similar to Sun’s binary distribution.
Apache clearly felt that this was in contravention of the JSPA and wrote an open letter to Sun Microsystems on April 10th, 2007 essentially demanding that Sun honour the terms of the JSPA and provide them with the TCK under an appropriate license. Sun refused to do this.
The impasse was finally resolved after Oracle acquired Sun Microsystems and put the proposed Java SE 7 JSR to a vote of the Java SE/EE EC. This was effectively a vote on whether the licensing terms of the TCK for Java SE would change to allow the ASF access the way they wanted. However, despite the objections of several members of the EC, the vote was passed paving the way for the JCP to return to developing standards as normal.
Tim Peierls 和 Doug Lea，都是SE/EE EC的独立成员，为了表示抗议就辞职了。而ASF则又尝试想让Oracle尊重JSPA的承诺，但是最终还是在2010年的12月份从JCP SE/EE EC中退出。
在过去几年里，只有两个JSR只跟Java ME相关的，他们分别是关于 Connected Limited Device Configuration (CLDC) 发布版本 8 和Java ME嵌入式配置文件。既然移动电话已经不再使用Java ME了，而且很多嵌入式设备已经很强大，很轻松的就能运行一个完整的Java SE实现，很难看到Java ME 未来的出路在哪里。
自Java SE 8起，Oracle就计划要让Java ME跟Java SE同步发布。但目前看来，明年是不可能发布Java ME 9了。
Oracle的Java工程师组管理层最近向JCP EC做了关于Java SE的JSRs的主题报告。他们的问题是在过去的二十年里软件开发行业已经变化了很多， Java核心平台的开发需要一个更加敏捷的方式。JSRs使用了一个结构化的流程来开发，但是并没有很好跟这种方法论融合在一起。
为了满足这一点，OpenJDK项目就引入了JDK增强建议 (JEPs) 。JEPs 比一个完整的JSR要覆盖较小的工作内容片段， 可以很容易而且快速的从一个JDK发布版本中被移除或加入（JDK9已经验证了这一点）。
尽管使用了JEPs，Java SE仍然会继续有JSRs的，但是只有当一个版本被发布时他们才会去手机所有的变化，而不是在刚开始开发时就定义他们。这样很好，因为它确保了Java SE的知识产权跟以前一样在同样的条款下是可用的。但是对于那些想要对JDK做一些商业清理性质的实现的人，这样会有些不太令人满意，因为在 Java SE 的JSR被最终发布之前，OpenJDK项目依然是唯一的参考规范.
Java EE已经有很多涉及到各个方面的JSR提交，比如EJBs、Servlets、Web Services、MVC等等。一切新的都想成为Java EE 8的一部分。但是最近在Java社区里大家都非常担心这些JSR中大多数都与他们无关，并且Oracle也不再积极的发展Java EE了。在今年的javaOne会议上的最近一次声明是要承诺让Java EE 8 和 9 重回正轨，因此在不远的将来，我们可以希望能够看到不少进展。