J2SE SDK/JRE Version String Naming Convention
J2SE SDK/JRE Version String Naming Convention
Developers may need to know a product's version string for various purposes, depending on whether they are developing and deploying a product or downloading and integrating a product.
The following table explains how to interpret SDK/JRE release version string information.
Note that this convention was not in effect prior to the 1.3.0 feature release. The output of java -version has had the same format since 1.3.1.
System Properties and the java -version Command
The output of the java -version command includes a product version identifier and a build identifier. This output is determined by the values of several system properties, and those system properties can themselves be examined programmatically at runtime.
| System Property Name | System Property Content | Where Displayed in java -version Output |
|---|---|---|
| java.version |
|
|
| java.runtime.version |
|
|
Numbering Format Specifications
Every SDK/JRE release that is shipped has a product version string and a build identifier associated with it. The general rules for setting either a version string or a build number string are as follows. For more specific rules and examples, see the following table:
- The content of the java.version system property must always be unique for each external binary.
- A separator is always used between different parts of the string so that ordering can be determined programmically. (For example, a version string of "1.3.1beta" is not acceptable. A version string of "1.3.1-beta" is acceptable.)
- The format should be numeric and in lower case where applicable with a period "." within the field itself and a dash "-" between fields.
- A period "." separator indicates a major version.
- An underbar "_" separator is used to indicate an update release.
- A dash "-" separator is used to indicate a non-GA (non-FCS) release.
- A GA (FCS) product version or build identifier must not contain a dash (-).
- No asterik "*" or plus sign "+" is allowed, since these are used as wildcards for the matching logic.
- The content of the java.runtime.version system property can be expanded (beyond that of the java.version system property) to include the build id.
- All GA (FCS) versions are ordered based on the standard dot-notation. For example: 1.3.0 < 1.3.0_01 < 1.3.1 < 1.3.1_01.
Syntax Notation
Syntax notation used in the following table is:
- Italics indicate syntax that varies.
-
<-
identifier> indicates syntax that is present only for any non-GA (non-FCS) release.
The identifier is often used to represent a particular milestone, for example:
- early access
- beta
- rc1
J2SE Release and Version String Information
| Release Type | Description | Version Numbering Format | Example java -version Output Strings |
|---|---|---|---|
| Feature | Contains new functionality. |
n.n.0<-
identifier>
|
The following output indicates a GA (FCS) release having a build identifier of b24.
|
| Maintenance | Contains engineering focused bug fixes. |
n.n.n<-
identifier>
|
The following output indicates a beta, maintenance release having a build identifier of 09.
|
| Update | Contains customer focused bug fixes. |
n.n.n_nn<-
identifier>
|
The output indicates an early access, update release having a build identifier of b01.
The output indicates a GA (FCS) update release having a build identifier of b02.
The output indicates an early access, update release having a build identifier of b01.
The output indicates a GA (FCS) update release having a build identifier of b04.
|
Also see: