IcedTea-Web for AdoptOpenJdk

[k7aravind]

I have been trying to use IcedTea-Web in AdoptOpenJdk. I have not been successful using either latest builds or the nightly builds. I have also tried to use the IcedTea-Web in AdoptOpenJdk website. It looks like AdoptOpenJdk is using 1.8 version IcedTea-Web. Recently I used 1.7.x version of IcedTea-Web available in http://icedtea.wildebeest.org/download/icedtea-web-binaries/. And it worked. I also tried the 1.8 version and it did not work. So it looks like IcedTea-Web version being used in AdoptOpenJdk might be the issue. Can the version be changed and tested.

[karianna]

@k7aravind 1.8.1 is the latest production release (1.7.x should be considered deprecated). Can you tell us what error you are getting?

[judovana]

Hi @k7aravind . Can you please try http://icedtea.wildebeest.org/download/icedtea-web-binaries/1.8/ ? That is last release of ITW build and tested by myself. if that works for you, then the issue is in adopt's release process. If it do not work for you then the issue is in 1.8 (A tried adopt's 1.8.1 only briefly, but looked ok).

[judovana]

@k7aravind ; In all cases, I need a reproducer. Do you mind to share jnlp url?

[k7aravind]

@k7aravind 1.8.1 is the latest production release (1.7.x should be considered deprecated). Can you tell us what error you are getting?

Can you please tell me how can i see the logs. This is what happens, when I try to open the jnlp file through command prompt using 'javaws abc.jnlp', it works. But if I try to open using windows 'Open With' option, it doesn't. It does not even open any command prompt to logs things that are happening. This happens only in 1.8 version. Whereas in 1.7.x, even when I open jnlp with 'Open With' option, it immediately opens command prompt where I can see the logs and icedtea-web looks to be working fine.

[davidfrankson]

Actually I just encountered a similar issue with AdoptOpenJDK 8.0.212.04-hotspot and the bundled IcedTea 1.8.1 version. I can launch my application using javaws in the command prompt but not through double clicking the jnlp file. I used visualvm to find where the application code is hanging and it looks like it is when it is trying to write to System.out:

Assuming I have already approved and saved the security authorization it will get to a state where there are two javaws.exe processes running. One of them seems to be running:

"My application's name" #25 prio=5 os_prio=0 tid=0x000001b1c644f000 nid=0xc88 runnable [0x0000005309bff000]
   java.lang.Thread.State: RUNNABLE
        at java.lang.ProcessImpl.waitForInterruptibly(Native Method)
        at java.lang.ProcessImpl.waitFor(ProcessImpl.java:449)
        at net.sourceforge.jnlp.util.StreamUtils.waitForSafely(StreamUtils.java:124)
        at net.sourceforge.jnlp.Launcher.launchExternal(Launcher.java:440)
        at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:525)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:945)

The other one actually started my app code:

"My application's name" #25 prio=5 os_prio=0 tid=0x000001ea972bb800 nid=0x3adc runnable [0x00000003361fe000]
   java.lang.Thread.State: RUNNABLE
        at java.io.FileOutputStream.writeBytes(Native Method)
        at java.io.FileOutputStream.write(FileOutputStream.java:326)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
        - locked <0x00000000c0c674c8> (a java.io.BufferedOutputStream)
        at java.io.PrintStream.write(PrintStream.java:482)
        - locked <0x00000000c0c674a8> (a java.io.PrintStream)
        at java.io.PrintStream.write(PrintStream.java:480)
        - locked <0x00000000c0953168> (a net.sourceforge.jnlp.util.logging.TeeOutputStream)
        at net.sourceforge.jnlp.util.logging.TeeOutputStream.write(TeeOutputStream.java:87)
        - locked <0x00000000c0953168> (a net.sourceforge.jnlp.util.logging.TeeOutputStream)
        at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
        at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
        at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
        - locked <0x00000000c09531b8> (a java.io.OutputStreamWriter)
        at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
        at java.io.PrintStream.write(PrintStream.java:527)
        - locked <0x00000000c0953168> (a net.sourceforge.jnlp.util.logging.TeeOutputStream)
        at java.io.PrintStream.print(PrintStream.java:669)
        at java.io.PrintStream.println(PrintStream.java:806)
        - locked <0x00000000c0953168> (a net.sourceforge.jnlp.util.logging.TeeOutputStream)
        at java.util.Properties.list(Properties.java:1054)
        at my application's code

And this code is calling: System.getProperties().list(System.out);

If I task kill the first process that is running the Launcher, my application will pop up.

If I run it via the commandline, it still results in 2 javaws.exe processes, but it can just write System.out to the command prompt and it seems to bypass whatever it locks on.

[maru-sama]

Actually I just encountered a similar issue with AdoptOpenJDK 8.0.212.04-hotspot and the bundled IcedTea 1.8.1 version. I can launch my application using javaws in the command prompt but not through double clicking the jnlp file. I used visualvm to find where the application code is hanging and it looks like it is when it is trying to write to System.out: If I run it via the commandline, it still results in 2 javaws.exe processes, but it can just write System.out to the command prompt and it seems to bypass whatever it locks on.

Hi, this should have been fixed in #273 and the related pull request. Inside the issue you should find several test builds you can try. The last one which has now been merged worked for me https://github.com/AdoptOpenJDK/IcedTea-Web/issues/273#issuecomment-503137024

[karianna]

We will release 1.8.2 in conjunction with the next CPU update

[davidfrankson]

I tried the build from that case and it still hangs during startup. My case might be unique as it seems to always hang on the exact same spot during the dump of System properties. It is able to start listing the props out to System.out, it outputs everything through to deployment.headless.ignore=false and then it locks up before outputing java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment which is what is output next when running from the command prompt. But the stack hangs on writing to System.out after reading this value so maybe reading this system property is somehow changing the headless/environment state to something broken?