Java 8u121, 8u131 and JNLP | App-v 5.1 RRS feed

  • Question

  • Hello there,

    I'm curious if anyone noticed same behavior with recent Java updates sequenced as appv packages. We have a web app that is launched using JNLP. Everything was working until we updated from JRE 8u91 to 121. Application stopped working. It's not launching, nothing happens after Java loading screen appears. I monitored virtual processes. Under 8u91 2 instances of javaws and one instance of jp2launcher is started. For 8u121 there is only one instance of javaws that gets closed after around 10 seconds without any output, no errors, nothing. I have tried few things :

    - It is working as expected when 8u121 is installed locally, only under appv it's causing problems so it is not directly related to jre or app itself

    - I prepared few appv packages of different x86 jre versions, all sequenced on the same machine following exactly same procedure. For 8u11 u45 and u91 that i have tested application is working fine. For 8u121 and 131 we have that described behavior

    - I have launched that app using link on a website, directly from jnlp file, I have made some changes in the file, launched directly from javaws with -verbose and other parameters, nothing helped and i did not found anything interesting in logs

    - I have tested other apps that are using Java Network Launch Protocol, they are not working as well

    - Intresting thing is, that with 8u121 and 8u121 im not even able to start
    javaws.exe -viewer (but i can do it using Java Control Panel GUI)

    Any ideas what can be causing this ? Nothing helpful that i found i jre changelogs for new versions.

    Friday, June 2, 2017 7:24 AM

All replies

  • just a quick question, have you tried using the x64 as well.  I see that you tried different x86 ones.  I did have a similar issue with another app and it needed to use the x64.
    Friday, June 2, 2017 2:38 PM
  • Yes, i have recently tried with x64 version of 8u91 (working) and 8u131 (not working). So, same behavior for x64 versions.
    Monday, June 5, 2017 7:40 AM
  • Few more things to add. A tried to publish those packages on a few different virtual machines. With older Java locally installed, without java, on win7 and on win 10. Still, jnlp apps won't launch.
    Thursday, June 8, 2017 6:48 AM
  • I've seen the same issue and the problem started with Java 8u102. Last week I opened a case with Premier Support on this and just today they said:

    • Yes, we can reproduce the issue
    • No, we can't help any further because this is an Oracle issue.

    I've contacted my TAM to see if there's any escalation path and will follow up if I hear anything.

    Tuesday, June 13, 2017 6:10 PM
  • Good to know that I'm not alone. I also created a ticket in Oracle Support, got same reply.

    "Please be aware Java SE support is not covered under any OPN contract..."

    Person from oracle that contacted me advised to :

    I would say that it seems like
    there may be a low memory issue at Java startup.  Java requires a
    contiguous block of memory (process space) at start-up.  You may want to
    try reducing the initial Java heap size.  This can be done using the -Xms
    flag.  See https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
    for details.

    I tried that before, did not solved my issue.

    I'm investigating this further.

    Wednesday, June 14, 2017 9:19 AM
  • I also have a thread on Oracle support forum. 


    There are other users reporting this as well. So far there is no working solution for me. 

    Wednesday, August 9, 2017 12:42 PM
  • There where heap size issues in the past. Just when 5.1 came out, java apps with a high heapsize stopped working. MS fixed this with 5.1HF4 (see this topic) . So are you at least running HF4 if you're on 5.1?
    This was my  workaround until HF4 was available:
    1) Decrease the maxheapsize below 730Mb.
    2) use a x64 java client instead of the x86 one.

    Roy Essers

    Thursday, August 10, 2017 9:04 PM
  • Yep, I already tried that with HF8 and HF9. No changes. Heap size thing was a first suggestion (and only one) from oracle support, did not elped. Tried PVAD, tried Integration/Isolation, Even tried on win10 1607 with integrated App-V client. I will try my luck with new win10 1703 update with AutoSequencer feature.
    Friday, August 25, 2017 11:44 AM
  • Ok, I just tested this with latest JRE 9 Early Access build. Works like a charm.

    Tested on win 7 machine with all updates, App-V client HF09. But I'm pretty sure it will work on app-v 5.0. Sequenced to VFS. No additional settings like COM integration. But still, I have no idea what is causing this issue for all 3 digit versions of JRE 8... 

    Thursday, September 21, 2017 7:38 AM
  • Same issue here.  We were unable to use 1.8u141 but our 1.8u91 seemed to fire off the JNLP files successfully.  The packages were created the exact same way. We started to use the following site to do quick tests - 
    Thursday, December 14, 2017 9:01 PM
  • Unfortunately, MS support couldn't help (and I understand that) as this have clearly something to do with java itself, because version 9 is working properly. 
    Since my last post I did not had time to investigate this topic further. We dedided to install latest JRE 8 in the base image and provide only older versions as App-V. It's not likely that some application will require in example - exactly version 8u131.
    The problem is, that Java 9 dropped the web browser plugin and there is still a number of enterprise apps that utilize this feature. So you can't update to JRE 9 on your base system/image and deliver latest JRE 8 as app-v.
    Friday, December 15, 2017 8:42 AM
  • Thanks for the reply.  Just in case anyone wants to see the current bug report on this one:


    Friday, December 15, 2017 8:22 PM
  • Good to know it's been accepted as a bug in Java. Also had the same issue with our old platform based on Windows 7.x64 and swv (symantec virt.), so it's not only affecting appv virt.

    Sunday, December 17, 2017 2:22 PM
  • Just confirming this as I have tested and found the same, and the official bug page still says it came in with Java 8u111 - however Java 8u101 works, 102 does not!

    Dan Gough
    Microsoft MVP (Windows and Devices for IT)

    Blog | Twitter | LinkedIn

    Monday, April 9, 2018 9:49 AM
  • https://bugs.openjdk.java.net/browse/JDK-8194690
    Pardeep Sharma added a comment - <time class="livestamp" datetime="2018-02-22T02:06:29-0800">2018-02-22 02:06</time> - edited

    "Confirming that the adding deployment property - "deployment.security.use.insecure.launcher=true" resolves the issue. Verified with the versions where it has failed prior (JDK 8u102 b14, JDK 8u111 b14 and JDK 162). "

    I'll have to try that.

    • Edited by Alex_Bodin Tuesday, April 10, 2018 1:33 PM
    • Proposed as answer by Arne Johansen Wednesday, April 18, 2018 12:29 PM
    Tuesday, April 10, 2018 1:33 PM
  • Confirmed, workaround is working fine !

    Adding deployment.security.use.insecure.launcher=true to deplyment.properties solved the issue. You can :
    Remove localAppData from Exclusions prior to sequencing and edit the deplyment.properties in AppData\LocalLow\Sun\Java\Deployment during sequencing OR somehow edit the deplyment.properties in AppData\LocalLow\Sun\Java\Deployment for the existing package in local, not virtualized location (if localLow was in excludes) OR edit the global per machine in %windir%\Sun\Java\Deployment

    More on deployment.properties

    Tuesday, April 17, 2018 9:37 AM
  • Thanks for the nice info.

    I also wrote a blogpost about this solution:


    Wednesday, April 18, 2018 12:38 PM