The JVM virtual Machine — Learn how to allocate, layout, and access objects in the Java heap.
1. Its overview
OpenJDK is a free open source implementation of the Java Platform Standard Edition (Java SE). This is the result of an effort that Sun Microsystems (Sun) began in 2006. This implementation is licensed under the GNU General Public License (GNU GPL) version 2. There are exceptions for links. With the exception of GPL special case links, components that link to Java class libraries are subject to the terms of the GPL license.
The OpenJDK Project produces many components: the most important are the virtual machine (HotSpot), the Java class library, and the Java compiler (JavAC).
Since Java SE 7, the OpenJDK Project has become the official reference implementation of Java SE.
Since Java SE 10, the JDK Project (a subsidiary of the OpenJDK Community) has become the official reference implementation of Java SE.
Yes, from Java SE 7 onwards, even the well-known Oracle JDK is based on the Open JDK (with some modifications to the implementation, its own branding and supporting services). Or should I say since Java SE 7, all JDKS are derived from the OpenJDK (OpenJDK has the same relationship to other JDKS as Linux does to many of its distributions).
OpenJDK is led by OpenJDK Community, Oracle, IBM, together with Alibaba, Amazon, Ampere, Azul, BellSoft, Canonical, Fujitsu, Google, Huawei, Intel, Java Community, JetBrains, London Java Community, Microsoft, Red Hat, SAP, SouJava, SUSE, Tencent VMWare and other third-party joint development, maintenance of Java SE open source reference implementation.
The development standard for OpenJDK versions is Java Specification Requests (JSR) published by the Java Community Process (JCP).
The OpenJDK Project, led by the OpenJDK Community, is the official reference implementation of Java SE. It only produces the OpenJDK source code and does not provide a binary file format that can be used directly. The JDK currently available in binary format is a compiled program. The address for downloadable binaries pointed to on the OpenJDK website is where Oracle’s OpenJDK builds will be downloaded. Yes, this is also compiled by Oracle.
OpenJDK uses Git at GitHub and OpenJDK uses Mercurial at OpenJDK
2.OpenJDK history
On March 23, 1995, Sun officially announced Java at the Sun World conference.
On January 23, 1996, Sun released the first development tool for Java *.
In JavaOne 2006, Sun announced that Java would become Open source software and established the Open JDK community.
On November 13, 2006, Sun released the Java HotSpot VIRTUAL machine and compiler as free software under the GNU General Public License, promising to place the rest of the JDK (* including the Java runtime environment) under the GPL by March 2007.
Sun has promised to release a Java development tool * (JDK) based almost entirely on free and open source code in the first half of 2007.
On May 8, 2007, Sun released the complete source code of the Java class library under the GPL.
In 2007, the list of restricted parts includes several essential components of the Java graphical user interface (GUI), in addition to some restricted parts that are licensed to Sun by third parties and that Sun cannot relicense under the GPL. Sun says it plans to replace the remaining proprietary components with alternative implementations and make the class library completely free.
At the time of the original Release in May 2007, 4% of the OpenJDK class library was still private. By the time OpenJDK 6 appeared in May 2008, less than 1% (the SNMP implementation, which is not part of the Java specification) remained private, allowing OpenJDK to be built without any binary plug-ins. Binary plug-in requirements were later removed from OpenJDK 7 in April 2009.
OpenJDK 6 Project, based on JDK 7 but modified to provide an open source version of Java 6.
OpenJDK 7 Project, General Availability (GA) released on July 28, 2011. OpenJDK 7 Update Project, which provides an Update based on the original GA release of OpenJDK 7.
OpenJDK 8 Project, released in GA on March 18, 2014. OpenJDK 8 Update Project, which provides an Update based on the original GA release of OpenJDK 8.
OpenJDK 9 Project, released in GA on September 21, 2017.
JDK Project (OpenJDK Community subproject) :(the goal of this long-running Project is to generate a set of open source reference implementations of the Java SE platform, as specified by the JSR in the Java Community Process. According to a strict, time-based model, the project releases a feature release every six months) OpenJDK 10, the GA release on March 20, 2018. OpenJDK 11, released in GA on September 25, 2018. OpenJDK 12, released in GA on March 19, 2019. OpenJDK 13, released in GA on September 17, 2019. OpenJDK 14, released in GA on March 17, 2020. OpenJDK 15, released in GA on September 15, 2020. OpenJDK 16, GA release on March 16, 2021. OpenJDK 17, currently under development, is expected to be released in GA on September 14, 2021.
JDK Update Project (Affiliated with the OpenJDK Community) : (The goal of the Project is to develop an Update for the JDK Project.) OpenJDK 11 Update Releases, which provide an Update based on the original GA release of OpenJDK 11. OpenJDK 12 Update Releases an Update based on the original GA release of OpenJDK 12. OpenJDK 13 Update Releases an Update based on the original GA release of OpenJDK 13. OpenJDK 14 Update Releases an Update based on the original GA release of OpenJDK 14. OpenJDK 15 Update Releases an Update based on the original GA release of OpenJDK 15. OpenJDK 16 Update Releases, which provide an Update based on the original GA release of OpenJDK 16.
3.OpenJDK Community
The OpenJDK Community is an association of developers who collaborate on open source implementations of current and future versions of the Java Platform Standard Edition (Java SE) as defined by the Java Community Process, as well as closely related projects. The goal of these regulations is to promote the long-term health and development of the community by allowing and encouraging community members to act in an open, transparent and meritocratic manner.
The OpenJDK Community consists of a group of communities and a group of projects that are a collection of individuals having an open dialogue about common interests and that are working together to produce specific artifacts. There are community-wide general roles, as well as group – and project-specific roles.
The council manages the structure and functioning of the community and monitors its health in accordance with the principles laid down in the preamble. It upholds and maintains these charters, resolves procedural disputes, and ensures that adequate infrastructure is available. The council has no direct authority over technology or issuing decisions.
1. Role definition
Participant
Participants are individuals who subscribe to one or more OpenJDK mailing lists. Participants can post messages to the list, submit simple patches, and make other types of small contributions.
Your Contributor is a professional Contributor.
A Contributor is a participant who has signed an Oracle Contributor Agreement (OCA) or works for an organization that has signed that Agreement or an equivalent and contributes under that Agreement within the scope of that work. Contributors can submit larger changes than a simple patch, can propose new projects, and can play different roles in groups and projects.
If a contributor’s employment changes so that the contributor is no longer covered by OCA or its equivalent, the contributor must notify The OpenJDK * management to relinquish this role.
Its members
Any group member or submitter can be nominated as a member of OpenJDK by existing OpenJDK members. Such a nomination must be approved by at least three votes of OpenJDK members.
Any OpenJDK member can make a motion to remove another OpenJDK member. Such a motion must be approved by a two-thirds majority of the OpenJDK members (at least two times the number of votes in favor of the motion), with members abstaining as questions * on the motion.
In exceptional cases, the Board of Governors may remove OpenJDK members by a two-thirds majority vote (at least two times the affirmative vote).
Each OpenJDK membership will automatically expire after one year, but will be renewed upon request. Renewal applications must be received within one year of expiration. OpenJDK members whose membership has expired and has not been renewed cannot exercise membership privileges unless roles requiring OpenJDK membership can be retained.
If an OpenJDK member’s employment changes and such contributions are no longer covered by OCA or its equivalent, the member must relinquish the contributor role by notifying the OpenJDK * administration. At this point, membership will be deemed to have expired.
The OpenJDK Members Group consists of all OpenJDK Members. The OpenJDK leader is the leader of his or her organization. The usual rules for dismissing groups, adding and removing Group Members, and selecting and removing Group leaders do not apply to OpenJDK Members Groups.
Its * tube
OpenJDK This is an OpenJDK member, appointed by Oracle, who directs the community’s work on a new implementation of the Java SE platform called JDK Release Projects. OpenJDK * is responsible for openness and transparency in the development process used in these projects, and can also resolve certain types of program disputes. OpenJDK * is a board member.
2. They have a Governing Board.
The Governing Board (GB) governs the OpenJDK Community structure and operations.
JDK Release Projects is a new version of the Java SE platform implementation project. Such projects can only be proposed by OpenJDK and can only be sponsored by GB. The OpenJDK manager is the project lead for all JDK Release Projects. Each OpenJDK member has the opportunity to propose features to be included in JDK Release Projects, and decisions about which features to include are made in a transparent manner.
GB structure
GB consists of five funders:
**, appointed by Oracle;
Deputy **, appointed by IBM;
OpenJDK * management is appointed by Oracle;
Two ordinary members, nominated and elected by OpenJDK members.
GB Ordinary Member
Ordinary members of GB are voted by OpenJDK members. The term of office of ordinary members is one calendar year, commencing on April 1 of each year.
During the two-week nomination period, any OpenJDK member can nominate an individual who is not currently appointed to a GB board seat to fill an ordinary member seat. The individual need not already be a member of OpenJDK. OpenJDK members can make multiple such nominations.
GB duty
GB is something of a legislative body: it has the power to amend these charters to improve existing processes, define new processes and dispose of processes that are no longer needed. Any amendments to these bylaws must be approved by an absolute two-thirds majority of the Board of Governors (at least two times the number of votes in favour and three votes in total) and then by two-thirds of the OpenJDK members.
The GB is also, to some extent, a judicial body: it has the power to resolve any procedural disputes that may arise within the community. Any procedural decision made by an individual may be appealed to GB as stated in these bylaws. If GB decides to hear the appeal, the proposed judgment must be approved by a simple majority vote.
GB is not an executive: it has no direct authority over technical or release decisions. For any given project, this permission is held by the person in charge of the project (specifically JDK Release Projects led by OpenJDK).
GB is a group, held by ***. This allows GB to sponsor projects. The usual rules for dismissing groups, adding and removing group members, and selecting and removing group leaders do not apply to GB.
GB must not be less than five persons. It should always include **, **, the OpenJDK tube, and at least two ordinary member bits as described above.
GB may be passed by an absolute majority vote, the addition or removal of GB * of appointed and ordinary members.
GB may, by voting, invite specific individuals to attend GB meetings as observers. Such a person need not be an OpenJDK member. Observers are welcome to listen and contribute to the dialogue, but they do not have any voting rights. GB can remove observers by vote.
GB members may appeal if they object in good faith to a technical or release decision made by the OpenJDK * administration.
GB shall conduct an annual review of all community groups and programs to eliminate any such activities that are determined to be ineffective.
4.Java Community Process (JCP)
The Java Community Process (JCP), established in 1998, is a formal mechanism that allows interested parties to develop standard technical specifications for Java. Anyone can become a JCP member by filling out a form on the JCP website. JCP membership for organizations and commercial entities requires an annual fee, but is free for individuals.
JCP is the process by which the international Java community standardizes and approves Java technology specifications. JCP ensures that a consensus-based and compliant approach is used to develop high-quality specifications. A JCP-approved specification must be accompanied by a reference implementation (to prove that the specification can be implemented) and a technical compatibility suite (a set of tests, tools, and documentation used to test whether the implementation conforms to the specification).
Any Java technology enhancements or introduction of new technologies are made through the Java Specification Request (JSR).
1. Role definition
An Observer
Individuals do not need to sign a formal JCP membership agreement to observe and comment on the activities of the panel because they can take advantage of JCP transparency mechanisms, such as public mailing lists and issue tracking tools.
Information on how to provide feedback can be found on the JSR Collaboration project page (Pointers to this page are provided on the JSR page at jCP.org). Observers are not eligible to join panels, run for EC commissioners, or participate in the annual elections of the JCP.
Associate Member
Individuals who are unwilling or unable to sign the JSPA may sign an Associate member agreement to participate in JCP activities. (Organizations do not qualify for such membership.) Associate member protocols are simpler than JSPA and only involve personal IP commitments. No need to hire * to sign.
Associate members cannot serve as special principals, join expert groups or run for EC commissioners. They are eligible to vote for the EC quasi – position, but not eligible to vote for the approval or election position. Associate members may be officially recognized as contributors to the JSR at the discretion of the Spec Leader.
Partner Member
Nonprofits that are unwilling or unable to sign up to JSPA (because they are not legal entities), such as Java user groups, can sign simplified partner membership agreements that focus on working with JCP members and PMOS to promote JCP activities.
Partner members cannot be responsible for the regulation or serve on most panels, but are eligible to run for EC commissioners. If elected, they can serve as EC commissioners on JSR expert groups that focus on redefining the organization and “constitution” of the JCP. Partner members have the same voting rights as full members.
Full Member
Members in this category are open corporations, legal entities of non-profit organizations, self-employed and unemployed individuals, students and some employed individuals. JSPA is a membership agreement for full members. Non-employed individuals and university faculty are eligible to become full members if they can legally license their own intellectual property rights and therefore sign the JSPA on their own behalf. Employees can become full members if they wish to sign an employment contribution agreement (university staff are not required to sign an employment contribution agreement). These individuals should register using their employee email addresses rather than personal email addresses so that the PMO can track changes in employment status. They should also agree to inform the PMO of any change of employment.
Full members can act as specification leaders, join expert groups, and run for positions at any level of the EC. Full members may vote for the approval and election of the EC, but may not vote for the associate election.
Member Representative
Employees and other individuals who have contractual relationships with full members may be authorized by full members to represent their interests in the JCP, as Spec leader, serve on expert groups, or run for EC. These members should register with their employee email addresses rather than personal email addresses so that the PMO can track employee changes. They should also agree to inform the PMO of any change of employment.
2.Executive Committee (EC)
The Executive Committee (EC) is the member group that guides the development of Java technology in the JCP. The EC oversees the development and evolution of Java technology within the JCP on behalf of both key stakeholders and the representative sector of the Java Community.
The EC is responsible for selecting the JSR to be developed in the JCP, approving the draft specification for public review, reconciling differences between the specification and its associated test suite, giving final approval to the completed specification and its associated RI and TCK, reviewing and approving maintenance releases, and deciding on phase I TCK test appeals. Approve transfer of maintenance responsibilities between members and provide guidance to the PMO and JCP Community.
EC commissioners must analyze, comment on, vote on, and decide to approve all JSRS submitted to the program. In addition to being responsible for guiding the evolution of the overall platform, the EC and the entire JCP program are also responsible for the JCP program itself, keeping it consistent with the community’s expectations of the program and its members.
According to the provisions of JCP Process Document 2.11.10 (21 July 2019) in the 2020 annual election, two approved seats and one elected seat will be cancelled, thus reducing the number of EC members * to 18.
* bit structure and tenure of EC
Permanent * bit -1 – owned by Oracle;
Approved * bits –11;
Election * seats –4;
Quasi-* bits –2;
The terms of the committee are staggered for two years, so that half of the 17 members can be elected each year.
Approve the election process
With due regard to balanced community and regional representation, the PMO nominates members to fill vacancies for approval *.
Full and partner members will vote to approve each nominee within a 14-day voting period.
The nominee was approved by a simple majority of the voters (more in favour than against).
If one or more nominees are confirmed without a vote, the PMO shall nominate additional members as required and hold additional approval votes until the vacancies are filled.
Electoral and quasi-electoral processes
Six weeks before the voting, the PMO shall post on the JCP open election polling station a complete description of all materials (candidate statements, position papers, etc.) that the candidate will provide during the election. At the same time, the PMO will announce a minimum period of 14 days for acceptance of nominations.
Full members and partner members may nominate themselves to run for these positions. Nominees must specify whether they are nominating themselves for election or quasi-election.
Employees of JCP members cannot run for office on their own and the PMO will reject such nominations.
After the nomination period, the PMO will release the names of all nominees.
During the voting period, members can vote for as many nominees as the vacant seats. (Full members and partner members can vote for election positions; Associate members may vote for the first place.
The nominee with the most votes shall fill the vacancy *.
Should voters be given the chance to vote if there is only one vacant nominee? Or no? For the candidate. The elected candidate must obtain a simple majority.
If there is no candidate to fill the vacancy, EC may elect to retain the vacancy until the next election.
Current EC commissioners and terms of office
Member of the
End of the term
Alibaba
2022, approval * bit
ARM
In 2021, * bits are approved
BellSoft
2022, approval * bit
Marcus Biel
2021, quasi *
BNY Mellon
2022, approval * bit
Eclipse Foundation
2022, the first election
Ken Fogel
2022, quasi *
Fujitsu Limited
In 2021, * bits are approved
JetBrains
2022, approval * bit
IBM
In 2021, * bits are approved
Intel
In 2021, * bits are approved
London Java Community
2022, the first election
MicroDoc
2022, approval * bit
Oracle
* a permanent
SAP SE
2022, approval * bit
SouJava
In 2021, * bits are approved
Tomitribe
2021, the first election
2021, the first election
5.Java Specification Request (JSR)
The Java Specification Request (JSR) is a formal, open, practical description of a proposal and final Specification for the Java platform, submitted by an individual or organization to the Java Community Process (JCP). It * contains suggested changes, additions, or improvements to the Java technology platform.
1.JSR draft launched
Initiate a Java specification request
One or more full members may submit A JSR proposal through the JCP website to initiate a request for a new specification or major revision of an existing specification.
Each JSR must provide the following information:
The names of the requesting member (submitter), the lead of the proposed specification, the initial members of the expert group and potential contributors;
Description of the proposed specification;
Reasons for developing or modifying it;
* Ask for platform versions and any consideration for other platform versions;
Estimated development schedule;
Any existing documentation, technical description or implementation that can be used as a starting point;
A transparency plan that Outlines the tools and techniques that specification leaders will use during specification development to communicate with JCP members and the public and seek feedback.
Whether the JSR is iterative and, if so, the expected iteration period.
At the discretion of the PMO, the JSR submission may be required * to include a complete JSR review process questionnaire or presentation that provides information about the objectives of the JSR and the process the expert Group plans to use in its development.
Revision of existing specifications
Existing specifications and their associated RI and TCK are maintained by designated maintenance owners using the process described in this document. While complying with JCP members’ wishes for improvement, the maintenance manager shall assume long-term ownership of the specification, RI and TCK. Therefore, the maintenance thread should be the normative thread for all major revisions to their specifications, but they do not have the authority to decide when to make major revisions. This should be determined by the EC in response to any JSR revision that a JCP member can initiate. The author shall make reasonable efforts to recruit members of the former Expert Group to join in any such revision.
Protect installed base and prevent debris
Changes to the Java programming language, the Java Virtual Machine (JVM) in Java Spaces, Java native interface (JNI) modules, and *, or other * delivered only as part of Java SE, can seriously disrupt the installation base if executed inconsistently in cross-platform versions. To protect the installed user base, any such changes can only be accepted and executed in the Java SE umbrella JSR.
To prevent fragmentation, new platform release specifications do not materially copy existing platform releases or profiles.
Profiles and API specifications target the current platform version
All new or revised specifications must be compatible with the latest version of the target platform version specification. To achieve this, all defining a new profile specification or revising an existing profile specification must refer to the latest version of the platform version specification on which it is based, or to an updated version of that specification that is being developed through the active JSR.
Platform contains *
A JSR submission is required to indicate whether the JSR RI and TCK are provided as a profile or part of the platform version, independently or both. The final decision as to whether a particular JSR should be included in the profile or platform version is confirmed by the EC vote of the relevant JSR made by the specification lead of the profile or platform version JSR and the panel of experts. If the profile or platform version’s spec pipe rejects the inclusion request, the JSR must provide separate RI and TCK.
After initial standalone delivery, technology can be incorporated into a profile or platform version. A JSR proposing a new VERSION of an API that is part of a profile or platform release and considering discontinuing standalone availability must explain the reasons for this change, inform the public of its intention to discontinue the standalone RI, and TCK has released a JSR ahead of time.
JSR review
When a JSR is received, the PMO provides it with a tracking number, creates its JSR page, announces the proposed JSR to the public, and begins the JSR review. Comments on the JSR should be provided through JSR’s public feedback exchange mechanism. Comments should be forwarded to the EC for consideration and should be made available on the JSR page (similar comments can be combined).
Members interested in joining the expert group or participating as contributors should identify themselves by informing the specification lead and the PMO. We encourage the specification lead to actively recruit panelists and contributors during this period and update the JSR page with the names of those who wish to help, as demonstrating a wide range of interest and representative diversity in the JSR will greatly increase the chances of the EC approving it.
If the member who was responsible for the specification prior to approving the JSR withdraws from the JCP, the PMO will ask a preliminary panel of experts to select a replacement.
Disclosure of license terms
The specification lead is responsible for developing the reference implementation and technical compatibility tools * and licensing them as described in the JSPA. The specification leader must provide the EC with complete copies of the proposed specification, RI and TCK licenses prior to the commencement of the JSR review. The PMO will publish the license on the JSR page. EC commissioners should provide feedback on the terms to indicate the reaction of the community as a whole. If the EC Commissioner considers that the proposed licensing terms are incompatible with the licensing guidelines used within the JCP, a vote on the proposed JSR shall be deferred until the Oracle Legal Body has given its opinion on the matter.
JSR approval vote and formation of the panel
After the JSR review, EC commissioners should review the JSR and any comments received and vote on whether the JSR should be approved.
If the JSR approval vote fails, the PMO should send all EC comments to the JSR submitter, who can modify the JSR and resubmit it within 14 days. If no revised JSR is received during this period, the original EC decision becomes effective and the JSR should be closed. If a revised JSR is received, the PMO shall post it to the JSR page, publish the revised JSR to the public, and then send it to all EC commissioners for a JSR reconsideration vote. If the vote fails, the JSR is shut down.
Upon approval by the JSR, the PMO directs the specification lead to formally create the expert group and identify members who will serve as contributors. The PMO will update the JSR page accordingly.
An iterative update
For an iterative JSR, the specification lead can notify the PMO at any time prior to the final release of the intent to update the JSR. The specification lead should provide the start date for the next iteration, the schedule for the next iteration, the release number for the next iteration, and the initial members of the panel’s recommendations. A new JSR will be created for the iteration, with the same JSR details and new expert group members, version numbers, and schedules. Iterations may overlap; There is no need for the previous iteration to reach any specific milestone before the next iteration can be created. In addition to changing plans and versions, the specification lead member may nominate another specification lead representative. A JSR approval vote is not required to renew the JSR for the first or subsequent iteration unless the specification lead advises the PMO that the proposed changes to the JSR are material. Iterating JSR may follow a maintenance phase process.
2. Release the JSR draft review
Start developing specifications and reference implementations
The Expert Group should begin its work by considering the requirements set forth in the JSR, any contributed documentation or technical notes, comments received during the JSR review, and, in the case of revisions to existing specifications, a list of issues maintained by the maintenance manager. Additional comments can be obtained from discussions with other members, industry groups, software developers, end users, and academics. Contributions are made under the terms of the JSPA. The goal is to define requirements and then write specifications and prototype reference implementation drafts for community and public review.
We encourage the JSR to provide common drafts of specifications and reference implementations frequently during development, even if they are incomplete. Drafts shall be published in a manner approved by the PMO and the specification leader shall notify the PMO when new drafts become available. Specification leaders should provide a mechanism by which they inform the public of their drafts, and the public can provide feedback on these early drafts.
Public review
When a draft of the specification is ready for public review, the specification leader shall publish the draft and send it, along with any other documents required for review, to the PMO, which will post them online for public download. At this point, community reviews of JCP members are conducted simultaneously. Public review begins when the PMO announces that a draft specification is available for public review and comment, which can be hosted on another site under evaluation license at the discretion of the PMO.
The specification lead is responsible for ensuring that all comments are read and considered. If these comments result in amendments to the draft specification, and the amendments result in significant changes (in the opinion of the Expert Group), then the specification leader must post the updated draft at least 3 days before the voting begins and send the updated draft (together with a summary of the changes) to the PMO. The PMO shall post the new draft and a summary of the changes on the JCP website prior to the commencement of voting and shall notify the public of the new draft being available.
Public review gives final approval to the ballot
Unless the Specification Lead wishes to issue another Public Review prior to the Final Approval vote, the Public Review Final Approval vote will commence at the close of the Public Review. At the conclusion of the voting, the PMO shall distribute all comments submitted by EC members to the Panel together with the voting.
If the public review vote for final approval of the specification fails, the Panel will have 30 days to update the draft in response to the EC’s questions and submit the revised version to the PMO. If the revised draft is not received within 30 days, the original EC decision will take effect and the PMO will declare the JSR closed. If a revision is received, the PMO shall forward it to the EC and initiate a “Review of the Final Approval Specification for Public Review” vote. At the conclusion of the voting, the PMO shall distribute all comments submitted by EC members to the Panel together with the voting. If the vote fails, the JSR will be shut down and the panel will be dismissed. If the JSR is a revision of an existing specification, the specification lead should resume the role of maintenance lead for the current specification.
Multiple open drafts and reviews can be conducted if the Panel finds it helpful.
3. JSR
Complete specifications
If the final approval vote (or reconsideration vote) of the public review is successful, the Panel shall prepare a final draft specification by completing such changes as it deems necessary to the comments.
Complete RI and TCK
The specification lead is responsible for completing the RI and TCK. JSRS for multiple platforms are required to support each environment, which may require separate RI and TCK for each environment. If the RI and TCK find insufficient, incomplete, or ambiguous definitions in the specification, the specification leader should work with the expert group to correct these deficiencies and then send the revised specification along with a summary of the changes to the PMO. Information should be posted on the JCP website. The Group should continue to consider any further comments received during this period.
Establish a primary TCK appeal process
The specification leader is also responsible for establishing a clearly defined tier 1 TCK appeal procedure to address the testing challenges contained in the TCK. This process must be described in the TCK documentation. Implementers who are not satisfied with the primary decision should complain to the EC by sending an email to the PMO documenting their concerns. The PMO will distribute the request to the EC along with any information received from management on the grounds for the primary decision and initiate a 7 day appeal vote.
Update deliverables according to TCK appeal
Depending on the nature of the problem, a successful TCK challenge will require updating one or more of the TCK, specification, and RI. Within 30 days of the successful conclusion of the TCK appeal vote, the maintenance manager must update these deliverables as necessary and report these changes to the PMO when the specification (if changed) and the updated RI or TCK URL are posted on the JCP website.
The final version
When the expert group is satisfied that the TCK provides adequate test coverage, that the RI has implemented the specification correctly, and that the RI has approved the TCK, the specification leader shall send the final draft of the specification to the PMO together with instructions on how the EC committee obtained the RI and TCK for evaluation. The PMO shall distribute the material to the EC and publish the final version. Any comments from the EC shall be forwarded to the Expert Group by the PMO.
To assist the PMO in tracking the number of “active JSRS”, at the time of submission of the final material, the specification leader should inform the PMO whether further development of the JSR is expected through a maintenance release or a new successor JSR. TCK submitted as part of the final release must meet the following requirements:
* includes documentation on the configuration and implementation of TCK, any other information required to use TCK (such as documentation for any tools provided), definition and description of the first-level TCK appeal process, and compatibility requirements that must be met in addition to passing the TCK tests
Compatibility requirements At least all compatible implementations must be specified
Full implementation specification, including all the necessary interfaces and functions, and shall not modify, subset, superset or in other ways to expand the licensor namespace, or in the license namespace contains any module, public or protected *, classes, Java interfaces, field, or method, but the implementation of standard or specification required/authorization.
Unless the specification or TCK explicitly allows exceptions, these requirements must be met.
Comes with test tools, scripts or other means to automate test execution and result recording.
Includes a TCK coverage document, which will help EC commissioners assess the quality of TCK. This document shall include an overview of the documentation contained in the TCK *, a description of the methods used to verify TCK quality, criteria used to measure the TCK test coverage of the specification, test coverage numbers achieved and adequacy based on TCK quality and its test coverage.
Provide 100% signed test coverage. These tests must ensure that all API signatures required by the specification are fully implemented and that only API signatures * required by the specification are hung in the namespace of the JSR.
The TERMS of the TCK license must allow the implementer to freely and openly discuss the testing process and the detailed TCK test results with all parties concerned.
EC members may raise objections within 7 days. Objections must be limited to claims that the specific changes between the public and final reviews are too great to be considered corrections or clarifications. The PMO will evaluate the objection request and, if confirmed, the Specification manager will have 30 days to respond to the EC’s request to modify the specification, RI and TCK and resubmit the modified material to the PMO.
If no response is received within 30 days, the EC’s original decision will take effect, the PMO will close the JSR and the panel will be dismissed. If the JSR is a revision of an existing specification, the specification lead should resume the role of maintenance lead for the current specification.
If replies are received, the PMO shall circulate them to all EC commissioners for a vote of final approval for reconsideration. At the end of the voting, all votes submitted by EC members shall be distributed by the PMO to the Panel. If the reconsideration vote fails, the JSR will be closed and the panel disbanded. If the JSR is a revision of an existing specification, the specification lead reverts to the role of maintenance lead for the current specification.
Within 14 days of receiving the final release materials, the PMO shall post the specifications and links to information on how to obtain the RI and TCK on the JCP website, and shall announce the availability of these materials to members and the public. Published TCK information must include any method by which an interested party may obtain a copy of the TCK document free of charge. The expert group will complete its work after the final version is released. The specification lead will typically become the maintenance lead and expert group members and others can be asked to fill that role.
The maintenance lead must ensure that links to the RI and TCK are still valid. If the link does not work, the maintenance manager will correct it within 30 days of notification from the PMO. If the problem is not corrected, the PMO will initiate a JSR withdrawal vote (if a maintenance release has not been completed) or a maintenance release withdrawal vote (if a maintenance release has been made) to determine whether the maintenance lead should be determined to have abandoned the JSR. If the vote passes, the JSR itself or the associated maintenance version will be marked as withdrawn.
6. * its flow builds
Build
LTS
Loose license
Pass TCK test
Upstream builds are not modified
Provide business support
AdoptOpenJDK
Yes
Yes
No
optional
Optional (IBM)
Alibaba Dragonwell
Yes
Yes
Yes
No
No
Amazon Corretto
Yes
Yes
Yes
No
Optional (on AWS)
Azul Zulu
Yes
Yes
Yes
No
optional
BellSoft Liberica JDK
Yes
Yes
Yes
No
optional
Huawei bisheng JDK
Yes
Yes
Yes
No
No
IBM Java SDK
Yes
No
Yes
No
Yes
Microsoft Build of OpenJDK
Yes
Yes
Yes
No
No (beta)
ojdkbuild
Yes
Yes
No
Yes
No
OpenLogic OpenJDK
Yes
Yes
Yes
No
optional
Oracle GraalVM Community Edition
NO
Yes
Yes
NO
NO
Oracle GraalVM Enterprise Edition
Yes
No
Yes
No
Yes
Oracle Java SE
Yes
No
Yes
No
Yes
Oracle OpenJDK
No
Yes
Yes
Yes
No
Red Hat build of OpenJDK
Yes
Yes
Yes
No
Yes
Tencent Kona
Yes
Yes
Yes
No
No
SAP SapMachine
Yes
Yes
Yes
No
Optional (for SAP Products)
PS:
LTS: Long Term Support provides long-term update Support.
TCK: Technology Compatibility Kit is a suite of tests that, at least nominally, check for compliance with specific Java specification requirements (JSR). It is one of the three parts required for an approved JSR in the Java Community Process. Used to check compatibility with standard Java SE.
The OpenJDK Project, led by the OpenJDK Community, is the official reference implementation of Java SE. It only produces the OpenJDK source code and does not provide a binary file format that can be used directly. The JDK currently available in binary format is a compiled program.
Since Java SE 7, all JDKS have been derived from the OpenJDK (OpenJDK has the same relationship to other JDKS as Linux does to many of its distributions). So the Oracle JDK is technically a release of the Open JDK.
* Stream OpenJDK builds do not currently pass TCK
AdoptOpenJDK
As of May 8, 2021, AdoptOpenJDK website statement:
Java Compatibility Kit (JCK) / TCK ComplianceAt this stage the London Jamocha Community CIC (aka LJC) has not been able to reach an agreement with Oracle to use the Java SE Technology Compatibility Kit (TCK) under the terms of the OpenJDK Community TCK License Agreement (OCTLA).We will continue to work with Oracle on this matter.All AdoptOpenJDK binaries are tested with our suite of functional, integration, stress, and performance tests, including real workloads from popular languages and applications. We are very confident in the quality of our builds.
ojdkbuild
As of May 8, 2021, ojdkBuild GitHub README. Md FAQ notes:
Question 2:Q: Is this project endorsed by upstream OpenJDK project? A: No.Question 3:Q: Will any questions about the TCK be answered (regarding this project)? A: No.
Technology Compatibility Kit (TCK)
Gaining Access to the JCK according to OpenJDK:
Gaining Access to the JCKThe Java Compatibility Kit (a.k.a., the JCK or TCK for Java SE) is available at no charge to developers who are planning to deploy a compatible Java implementation based on code derived from OpenJDK, or are participating in OpenJDK research, bug fixes, code enhancement and/or ports to other hardware/software architectures.The JCK is made available under the terms of the OpenJDK Community TCK License Agreement (OCTLA). The current version of the OCTLA is for Java SE 9 or later (OCTLA JDK 9 V 3). Please contact oracle-ca_us [at] Oracle [dot] com with any questions.The signatories of The laboratory versions of the OCTLA are listed here.ProcessTo obtain access to the JCK, please follow this process:
Review the terms of the OCTLA License.Fill out and submit the JCK access request form.The screening committee will review your form and determine if your application meets the requirements for JCK access.After Oracle reviews your application, you will be notified via e-mail of the decision of the screening committee.If you are granted access, you will need to send a signed copy of the OCTLA License to Oracle. The signed form can be scanned and e-mailed to oracle-ca_us [at] oracle [dot] com.If you have not signed the Oracle Contributor Agreement (OCA), then please do so, scan it and e-mail the result to oracle-ca_us [at] oracle [dot] com.Once Oracle receives your signed faxes, you will receive an e-mail explaining how to download the JCK.
Requirements for JCK access
Your project must be active and meet the terms of the OCTLA.Your project can be inside or outside the OpenJDK community, but you must sign the OCA.
Note: Signing the OCA does not require that you provide any code back to Oracle or OpenJDK, however, it is mutually beneficial to all parties if relevant patches are shared throughout the OpenJDK community. Signing the OCA makes it possible for you to contribute your patches to OpenJDK.SupportSupport for the JCK will be limited and handled primarily through a private mailing list shared by Oracle and all OCTLA licensees. If you are planning to do a wide distribution of compatible implementations and are interested in branding, other services may also be made available through Oracle’s licensee support organization.If you have any questions for Oracle regarding your request for JCK access, please e-mail oracle-ca_us [at] oracle [dot] com.
The Java Compatibility tool * (also known as JCK or TCK for Java SE) is freely available to developers planning to deploy compatible Java implementations based on code derived from OpenJDK, Or developers who are involved in OpenJDK research, bug fixes, code enhancements, and/or ports to other hardware/software architectures.
The OpenJDK Community provides JCK to vendors or organizations that have signed the TCK license (OCTLA).
To find out if a vendor’s OpenJDK build passes the TCK test, in addition to looking at the vendor’s own official statement, look at the list of OCTLA protocol signatories provided by the OpenJDK Community.
In theory, the TCK tested JDK is compatible with the Java SE standard specification functions. Why should the Java SE standard specification functions be compatible with each other?
This is because some organizations will add their own features to the JDK after the implementation of the Java SE standard specification. However, this feature may not be available in every JDK. Therefore, if you use the features of a JDK in your programming, Switching to a different JDK can cause all sorts of unknown problems (or, I guess, not working at all).
The JDK that passed the TCK test may have a few bugs, but it’s better than the one that didn’t pass the TCK test. No one can explain the metaphysical question).
conclusion
Bo * actually also pretty hate this kind of a big article theoretical description, but if you don’t give roughly in all parts of the basic concepts and important details to describe clearly, when writing the conclusion and personal guess is that they will lead to some unnecessary quarrel, because most of these unnecessary arguments and the basic concepts and important details about unequal everywhere. Is also quite helpless…
All of you here are absolute warriors, at least not without urgent and significant questions, and bo * can’t stand an article of this length. Again, with the highest respect, without further ado, let’s conclude.
Since Java SE 7, all JDKS have been derived from the OpenJDK (OpenJDK has the same relationship to other JDKS as Linux does to many of its distributions).
The OpenJDK Project, led by the OpenJDK Community, is the official reference implementation of Java SE. It only produces the OpenJDK source code and does not provide a binary file format that can be used directly. The JDK currently available in binary format is a compiled program. The address for downloadable binaries pointed to on the OpenJDK website is where Oracle’s OpenJDK builds will be downloaded. Yes, this is also compiled by Oracle.
OpenJDK is led by OpenJDK Community, Oracle, IBM, together with Alibaba, Amazon, Ampere, Azul, BellSoft, Canonical, Fujitsu, Google, Huawei, Intel, Java Community, JetBrains, London Java Community, Microsoft, Red Hat, SAP, SouJava, SUSE, Tencent VMWare and other third-party joint development, maintenance of Java SE open source reference implementation.
The development standard for OpenJDK versions is Java Specification Requests (JSR) published by the Java Community Process (JCP).
As the OpenJDK development standard, JSR is the aggregation of many JSR drafts initiated by JCP members after the following steps: JSR draft initiation, JCP public review, JSR final decision, JCP EC review and so on.
Here is a picture to briefly summarize the main points of the article:
As this article is too long, I’ll leave it to the next chapter to write about OpenJDK builds and OracleJDK options (though I think those of you who have read this chapter will already have a clear idea of the differences and which builds to use in what situations).
That’s the OpenJDK.
Also welcome everybody exchange discussion, if this article has incorrect place, hope everybody many forgive.
Your support is my biggest motivation, if you help out, give me a thumbs up