Unravelling the mysteries of Java (and other products) actual versions for licensing
- Author: Nicolas Rousseau
- Author Email Address: email@example.com
- Solution Type: Custom Report
- Flexera Product & Version: FlexNet Manager 2016-2020R2
- Environment: On Premise Only
- Development Effort (Days): 0.3
- Implementation Effort (Days): 0.1
SOLUTIONS ARE PROVIDED ON AN "AS IS" BASIS. NEITHER FLEXERA NOR ITS SUPPLIERS MAKE ANY WARRANTIES, EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, TITLE, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT. LICENSEE MAY HAVE OTHER STATUTORY RIGHTS. HOWEVER, TO THE FULL EXTENT PERMITTED BY LAW, THE DURATION OF STATUTORILY REQUIRED WARRANTIES, IF ANY, WILL BE LIMITED TO THE SHORTER OF (I) THE STATUTORILY REQUIRED PERIOD OR (II) THIRTY (30) DAYS FROM LICENSEE’S ACCEPTANCE OF THE AGREEMENT.
An example in the Java Standard 8 release notes: https://www.oracle.com/java/technologies/javase/8u-relnotes.html. The list of public and restricted updates and builds are at the bottom of this answer...
To address this need, Flexera ARL had to link evidences based on their build level (available in Windows, the Unix agent will bring this capability in June). This build level management forced Flexera to change from a quite granular “update level recognition” to a “major version level” normalization, to avoid the mess of having tens of recognized builds and versions... The April announcement for the change can be found here: https://community.flexera.com/t5/Technopedia-Blog/Content-Change-Notification-Java-Build-version-cha...
The downside is a loss of visibility on recognized applications. A report mitigates this issue and allows to understand (for all products) the recognized applications... and the raw versions of the evidences that allowed to recognize the applications. the description is below... the code of the report is attached.
Recognized Applications Transparency Report (NR)
The Flexera ARL normalizes the raw evidences to make the data manageable and align with the licensing requirements. The applications are often normalized at major version level.
There is however a need (for Java particularly) to understand what is the underlying exact version of the evidences that have been recognized into the application (major version).
The report shows all installations for the product named entered in the search filter (exact match on Product Name) and looks up all raw evidences that match this title for recognition (files (mandatory, at least one as a recognition rule, not ignored) or installer (not ignored).
If several evidences led to the recognition of one installed application, there will be several rows in the report.
The report contains information on computer OS, location, corporate unit etc.
Public and restricted versions of Java
1.Java SE 5:
1.Java 5 Until (& incl.) update 22 => “PUBLIC”
2.Java 5 update 23 & up => “RESTRICTED”
3.Java 5 (all update) where build >30 => “RESTRICTED”
2.Java SE 6:
1.Java 6 Until (& incl.) update 45 => “PUBLIC”
2.Java 6 update 51 & up => “RESTRICTED”
3.Java 6 (all update) where build >30 => “RESTRICTED”
3.Java SE 7:
1.Java 7 Until (& incl.) update 80 => “PUBLIC”
2.Java 7 update 85 & up => “RESTRICTED”
3.Java 7 (all update) where build >30 => “RESTRICTED”
4.Java SE 8:
1.Java 8 Until (& incl.) update 202 => “PUBLIC”
2.Java 8 update 211 & up=> “Restricted” (License change – 16/04/2019)
3.Java 8 (all update) where build >30 => “RESTRICTED”
5.Java SE 9 / 10
1.Java 9 & 10 => Public
2.Java 9 & 10 (all update) where build >30 => “RESTRICTED”
1.Java 11 Until (&incl.) update 2 => Public
2.Java 11 update 3 => “RESTRICTED”
7.Java 12 and more => “Restricted” (Licensing modification – 16/04/2019)