Details
-
Bug
-
Resolution: Duplicate
-
P4
-
None
-
8u121
-
x86_64
-
linux
Description
FULL PRODUCT VERSION :
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux c518662 4.6.2+ #5 SMP Mon Sep 26 15:12:10 CEST 2016 x86_64 x86_64 x86_64 GNU/Linux
EXTRA RELEVANT SYSTEM CONFIGURATION :
Java(TM) Web Start 11.121.2.13-fcs
A DESCRIPTION OF THE PROBLEM :
Our webstart application consist of several jar artefacts. One artifact is the client.jar.
The webstart cache contains the following versions of the artifact client.jar (checked via resources view in java cache viewer/ControlPanel):
- 9.9.0.20160803.0
- 9.11.0.20161221.0
- 9.11.0.20161203.1
- 9.11.0.20161214.1
When the newer version 9.11.0.20170123.0 of the application is startet via the webstart client, the client sends the HTTP GET request
GET /clientstarter/jars/client.jar?version-id=9.11.0.20170123.0¤t-version-id=9.9.0.20160803.0 HTTP/1.1" 200.
As you can see the current-version-id is 9.9.0.20160803.0. But 9.9.0.20160803.0 is a result of the alphanumeric comparison of the versions 9.9.0.20160803.0, 9.11.0.20161221.0, 9.11.0.20161203.1 and 9.11.0.20161214.1.
But the webstart client should set the current-version-id to 9.11.0.20161221.0.
Please note the JNLP spec (https://jcp.org/en/jsr/detail?id=56):
"6.3.1 Incremental Updates for JAR files
...
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.
...
A Version IDs and Version Strings
...
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.
.."
REPRODUCIBILITY :
This bug can be reproduced always.
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux c518662 4.6.2+ #5 SMP Mon Sep 26 15:12:10 CEST 2016 x86_64 x86_64 x86_64 GNU/Linux
EXTRA RELEVANT SYSTEM CONFIGURATION :
Java(TM) Web Start 11.121.2.13-fcs
A DESCRIPTION OF THE PROBLEM :
Our webstart application consist of several jar artefacts. One artifact is the client.jar.
The webstart cache contains the following versions of the artifact client.jar (checked via resources view in java cache viewer/ControlPanel):
- 9.9.0.20160803.0
- 9.11.0.20161221.0
- 9.11.0.20161203.1
- 9.11.0.20161214.1
When the newer version 9.11.0.20170123.0 of the application is startet via the webstart client, the client sends the HTTP GET request
GET /clientstarter/jars/client.jar?version-id=9.11.0.20170123.0¤t-version-id=9.9.0.20160803.0 HTTP/1.1" 200.
As you can see the current-version-id is 9.9.0.20160803.0. But 9.9.0.20160803.0 is a result of the alphanumeric comparison of the versions 9.9.0.20160803.0, 9.11.0.20161221.0, 9.11.0.20161203.1 and 9.11.0.20161214.1.
But the webstart client should set the current-version-id to 9.11.0.20161221.0.
Please note the JNLP spec (https://jcp.org/en/jsr/detail?id=56):
"6.3.1 Incremental Updates for JAR files
...
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.
...
A Version IDs and Version Strings
...
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.
.."
REPRODUCIBILITY :
This bug can be reproduced always.
Attachments
Issue Links
- duplicates
-
-
- Resolved
-