icedtea-web compatible with OpenJDK11

Jiri Vanek jvanek at redhat.com
Mon Sep 10 11:51:08 UTC 2018 

On 9/7/18 9:55 PM, Jim Douglas wrote:
> Hi Laurent!
> 
> We’re probably in the same position on Windows; I keep a system here for customer support, but spend 
> 95% of my development time on my Mac. My javaws.bat hacks were minimal; I hard-coded JAVA_HOME to 
> point to JDK 11, and added the jigsaw args that appeared to be required based on the reported error 
> messages (some of which might be specific to my use case):
> 
> set JAVA_HOME=C:\Program Files\Java\jdk-11
> 
> "%JAVA%" --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.net 
> <http://java.net>=ALL-UNNAMED --add-exports=java.base/jdk.internal.util.jar=ALL-UNNAMED 
> --illegal-access=warn "-splash:%SPLASH_LOCATION%" "%LAUNCHER_BOOTCLASSPATH%" %LAUNCHER_FLAGS% 
> %JAVAWS_J_OPTIONS% "-classpath" "%CP%" "-Dicedtea-web.bin.name=%PROGRAM_NAME%" 
> "-Dicedtea-web.bin.location=%BINARY_LOCATION%" "%CLASSNAME%" %ITW_WIN_SPECIALS% -verbose %*
> 
> That was enough to successfully test both signed and unsigned jnlp files with javaws.bat. It didn’t 
> eliminate all of the reported error and warning messages, but it did eliminate fatal errors.
> 
> I’m still trying to understand this:
> 
> net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Unknown Main-Class. Could not determine the main class for this application.

In 99% it is caused by application not on classpath.  Reasons for it may wary - not even downloaded, 
not cached properly. With jdk9+ in addition - not accessible correctly.

> 	at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:704)
> 	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:285)
> 	at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:357)
> 	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:429)
> 	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:480)
> 	at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeExtensions(JNLPClassLoader.java:513)
> 	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:283)
> 	at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:357)
> 	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:429)
> 	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:403)
> 	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:809)
> 	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:529)
> 	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:940)
> 
> 
> And dozens of “failed” messages like this:
> 
> Removing execute permissions on file C:\Users\Jim\.cache\icedtea-web\cache\673\http\10.0.1.5\8888\basis\JnlpExtIndex.jar.pack.gz.pack.gz.info.temp failed
> 
> Removing read permission on file C:\Users\Jim\.cache\icedtea-web\cache\673\http\10.0.1.5\8888\basis\JnlpExtIndex.jar.pack.gz.pack.gz.info.temp failed
> 
> 
> But I can ignore all of that; it doesn’t stop anything from loading.
> 
> The Mac client is where I’m really stuck; it only seems to be available if you can build it from 
> sources, and that process has been a complete failure for me. So I was very excited to see this 
> passing comment:
> 
> “Hmmm... So rust launchers, when compiled on generic linux, and provided with JAVA_HOME should work 
> for your mac friends?
> I would liek to understand this a bit more, to not kill the mac usecase."


This is what i was asking. As I'm not sure how to deal with desire for Mac builds in combination 
with rust launchers, and absence of Mac in my closer neighbourhood.

J.
> 
> 
> 
>> On Sep 7, 2018, at 12:13 PM, Laurent Bourgès <bourges.laurent at gmail.com 
>> <mailto:bourges.laurent at gmail.com>> wrote:
>>
>> Hi Jim,
>>
>> As I am not a windows bat file expert and I proposed to rewrite IcedTea-Web batch files to include 
>> jigsaw args, I am really eager to see your modified files.
>>
>> It will help me in that effort to better support windows.
>>
>> For mac, I made tests, but packaging ITW as a native installer/launcher or doing desktop 
>> integration is too much for me. Somebody else should step up.
>>
>> PS: AdoptOpenJDK could provide binary packages (win/mac/linux...) WITH ITW included and that would 
>> be enough for early OpenJDK11 release.
>>
>> Cheers,
>> Laurent
>>
>>
>> Le ven. 7 sept. 2018 à 20:52, Jim Douglas <jimdouglas at mac.com <mailto:jimdouglas at mac.com>> a écrit :
>>
>>     A Mac-compatible packaged version of IcedTea-Web would be extremely welcome, Jiri. Your
>>     Windows installer for 1.7.1
>>     <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2017-December/039064.html> made it easy
>>     for me to do initial testing for transitioning customers from Oracle’s javaws to IcedTea-Web.
>>     With minor javaws.bat hacks to force JAVA_HOME and add several project jigsaw command-line
>>     flags, I’ve been able to successfully test some representative jnlp files on Windows with JDK
>>     11. I’ve had no luck building
>>     <https://icedtea.classpath.org/wiki/IcedTea-Web#Building_IcedTea-Web> IcedTea-Web on my main
>>     development system, a Mac; the process has been an endless cycle of obscure build errors.
>>
>>     If you’re taking a shot at packaging a Mac-compatible distribution (for an upcoming
>>     IcedTea-Web 1.8?), I’d be very interested in stress-testing it here; we’re eager to give our
>>     customers a web start migration path when Oracle kills javaws.
>>
>>     (Reposted from the email address I used to subscribe to the list.)
>>
>>>     On Sep 7, 2018, at 6:39 AM, Jiri Vanek <jvanek at redhat.com <mailto:jvanek at redhat.com>> wrote:
>>>
>>>
>>>>      > My scientific users are mainly linux/mac addicts.
>>>>        Argh. Mac again.  That is area someone else will have to investigate.  I have never
>>>>     touched that,
>>>>        nor do have any experience in support.
>>>>        Mac can not live with untared binary?
>>>>     I mainly installed openjdk-11.tar.gz & my built itw as zip and just fixed few paths in
>>>>     javaws shell (JAVA_HOME). It rocks !
>>>>     Somebody else in the community could work on an openjdk installer + ITW desktop integration
>>>>     (icons as xdg-create-icons does not work and JNLP mime-type association) = out of scope.
>>>>        Once those few fixes are in, I think you will wish 1.7.2 release. I can definitely do it,
>>>>     and there
>>>>        landed few more good patches in past, and 1.8 is still far from release.
>>>
>>>     Hmmm... So rust launchers, when compiled on generic linux, and provided with JAVA_HOME should
>>>     work for your mac friends?
>>>     I would liek to understand this a bit more, to not kill the mac usecase.
>>>
>>>
>>>     Current waterfall in rus lunchers (pushed yesterday) is like this:
>>>
>>>     liunx
>>>     * jvm
>>>       - jvm set by properties
>>>       - jvm from java_home
>>>       - paths form  registry (no op)
>>>       - jvm from hardcoded path
>>>       - jvm from PATH //todo
>>>
>>>     win
>>>     * jvm
>>>       - jvm set by properties
>>>       - jvm from java_home
>>>       - paths form  registry //todo
>>>       - jvm from hardcoded path (cygwin only)
>>>       - jvm from PATH //todo
>>>
>>>     And depndencies similarly (jsut fully todo):
>>>
>>>       - deps frmo itw_home? (later)
>>>       - deps from hardcoded paths
>>>       - deps from local directory
>>>       - jvm from LIB_DIR/CLASSPATH
>>>
>>>     J.
>>
> 


-- 
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek at redhat.com    M: +420775390109

More information about the distro-pkg-dev mailing list