JDK-8167306 : Side effects of using url schema handler.
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 8u101,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-10-06
  • Updated: 2017-11-29
  • Resolved: 2016-10-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u152Fixed 9 b143Fixed
Related Reports
Relates :  
JDK-8139389 - Register a protocol handler for Java Webstart
Description
when using any of the url scheme handler launch methods, there are two side effects that should be fixed:
1.) The application supplied splash screen will not be shown (default splash screen will always be shown.)
2.) If shortcuts are created they will be recreated with each launch.
Comments
Crucible review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-2498
09-10-2016
it all seems to work - though if you launch an app with no codebase or href in multiple ways, each type will show default splash the first time and custom splash the second time. see: http://oklahoma.us.oracle.com/www/tests/jnlp/test5.html same goes for shortcut. an app with no codebase or href that creates a shortcut will only show the custom splash the second time it is launched from shortcut.
07-10-2016
the final problem I see is a combination of the two: The test app (any of those at: http://oklahoma.us.oracle.com/www/tests/jnlp/test5.html), then relaunching from the shortcut created, the custom splash will not show. This applies to any jnlp file without a href or (codebase and/or fully qualified jar resource). The native code when launched from a shortcut, gets passed only the jnlp file, and since it has no codebase or href, the native code will not even check if there is a custom splash for it. The answer is to: 1.) always create a second key in splash index file using the original arg (even if not jnlp: or jnlps: protocol.) 2.) fix native code to use original filename if no href or canonical href is available for splash file lookup. 3.) fix the lookup code to not assume it is a url (it currently only escapes ':' and '=' chars, needs to also escape escape chars '\\', which can be found in paths on windows though not in urls. This seems to fix all related problems.
07-10-2016
to fix first problem we will add keys into splash index for both normal key (canonical home) and original url when the original url is one using the new schema. Then whichever way it is launched will see proper splash image. The second problem is due to re-parsing the cached jnlp file, without using the implied codebase from updateFinalLaunchDesc(). When we get exceptions parsing the jnlp, we return the original ld which implies the jnlp was updated in the cache, so we re-generate the shortcut. If we pass in the original codebase, there will be no errors parsing the cached jnlp file, and we can the see it is identical and avoid re-generating the shortcut or re-downloading it.
07-10-2016