Backports
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8135418 | emb-9 | Andy Herrick | P4 | Resolved | Fixed | team |
Description
A DESCRIPTION OF THE PROBLEM :
The version ordering described in Appendix A of the JNLP specification is non-transitive. It states that two elements are compared numerically if they can both be parsed as Java ints. Otherwise they are compared lexographically by ASCII value.
For example, this definition implies that 4 > 2A, 2A > 12, and 12 > 4, which forms a cycle.
This non-transitivity causes other parts of the spec to not be well defined. For example, the last sentence in section A.4 states the client should choose the resource with the highest version-id matching a given range. For a non-transitive relationship, "highest" is not well defined (what would be the highest in the above example?)
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Either the ordering should be made transitive, or behavior that refers to the "highest" or "lowest" version should be redefined or at least clarified.
Two sections that refer to the "highest" version are 6.3.1 (fourth paragraph) and A.4 (first paragraph).
ACTUAL -
Section A (second-to-last paragraph):
Each element in a tuple is treated as either a numeric or alphanumeric. Two elements are compared numerically if they can both be parsed as Java ints, otherwise they are compared lexicographically according to the ASCII value15 of the individual characters.
Section 6.3.1 (fourth paragraph)
The current-version-id must always be exact. If several versions of a given resource are in the cache, then the highest version-id that is lower than the requested version should be used. The Web server is not required to return an incremental update, but could just return the requested JAR file.
Section A.4 (first paragraph)
If two or more available resources match the given version-string, the JNLP Client should use the one matching the earlier version-range in the version-string. If two or more available resources match a given version-range, the JNLP Client should use the one with the highest version-id.
URL OF FAULTY DOCUMENTATION :
http://java.sun.com/products/javawebstart/download-spec.html
The version ordering described in Appendix A of the JNLP specification is non-transitive. It states that two elements are compared numerically if they can both be parsed as Java ints. Otherwise they are compared lexographically by ASCII value.
For example, this definition implies that 4 > 2A, 2A > 12, and 12 > 4, which forms a cycle.
This non-transitivity causes other parts of the spec to not be well defined. For example, the last sentence in section A.4 states the client should choose the resource with the highest version-id matching a given range. For a non-transitive relationship, "highest" is not well defined (what would be the highest in the above example?)
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Either the ordering should be made transitive, or behavior that refers to the "highest" or "lowest" version should be redefined or at least clarified.
Two sections that refer to the "highest" version are 6.3.1 (fourth paragraph) and A.4 (first paragraph).
ACTUAL -
Section A (second-to-last paragraph):
Each element in a tuple is treated as either a numeric or alphanumeric. Two elements are compared numerically if they can both be parsed as Java ints, otherwise they are compared lexicographically according to the ASCII value15 of the individual characters.
Section 6.3.1 (fourth paragraph)
The current-version-id must always be exact. If several versions of a given resource are in the cache, then the highest version-id that is lower than the requested version should be used. The Web server is not required to return an incremental update, but could just return the requested JAR file.
Section A.4 (first paragraph)
If two or more available resources match the given version-string, the JNLP Client should use the one matching the earlier version-range in the version-string. If two or more available resources match a given version-range, the JNLP Client should use the one with the highest version-id.
URL OF FAULTY DOCUMENTATION :
http://java.sun.com/products/javawebstart/download-spec.html
Attachments
Issue Links
- backported by
-
JDK-8135418 JNLP Specification: Version Selection Not Well Defined
-
- Resolved
-
- relates to
-
JDK-8134515 [tck] JNLP version specification is not consistent with JEP 223 and semver.org
-
- Resolved
-
-
JDK-8075605 JNLP Specification update for JDK9
-
- Resolved
-