icedtea-web compatible with OpenJDK11
Laurent Bourgès
bourges.laurent at gmail.com
Wed Sep 5 19:35:05 UTC 2018
Jiri,
One more question:
Do you agree if I publishes my changes on github (under GPL v2) as another
ITW 1.7 mirror (my fork) ?
It helps me keeping history...
Laurent
Le mer. 5 sept. 2018 à 20:45, Laurent Bourgès <bourges.laurent at gmail.com> a
écrit :
> Dear Jiri,
>
> Sorry for my late response, I was working hard on fixing IcedTea-Web 1.7
> hanging problem (EDT) on OpenJDK11.
> I reported this problem to awt-dev list and wrote a simple reproducer:
> http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014264.html
> http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014269.html
>
> Today I managed fixing the AWT deadlock by using a workaround:
> use a specific thread pool within the Main thread group (not JNLP's
> AppContext) to relay the EDT invocations (invokeLater / invokeAndWait) as I
> figured out that SplashScreen & DownloadIndicator dialogs were using the
> JNLP AppContext
> => 2 concurrent AppContexts were used and 2 event dispatcher threads led
> to deadlocks in AWT SequencedEvent processing (Window Gain / Lost focus).
> With that workaround, all EDT actions from ITW are delivered to the Main
> AppContext and it works well !
> Of course, the application is still launched using its own separate
> AppContext, so the bug is still critical if any ITW dialog (permission,
> file check ?) can happen while the application is running.
> My apps use allPermissions so I can not test. Do you have any example app ?
>
> Moreover, I added the well known ThreadCheckingRepaintManager &
> TracingEventQueue to detect and fix any EDT violation: it is OK, so I can
> remove these classes.
>
> Now it is time to clean up the code and submit patches !
>
> Please see my comments in the text:
>
> Le mer. 29 août 2018 à 16:37, Jiri Vanek <jvanek at redhat.com> a écrit :
>
>> On 08/29/2018 03:37 PM, Laurent Bourgès wrote:
>> > Hi,
>> >
>> > I am performing tests with icedtea-web-1.7 (cloned) + OpenJDK 11 EA 28
>> (oracle build) to evaluate if
>> > it can provide a suitable alternative to Oracle JDK on major platforms
>> (win/mac/linux).
>>
>>
>> Thank you *very* much for doing this!
>>
>
> Thank you all for all the good work on ITW. It made huge progresses in 10
> years (fedora 11).
> By the way, the control panel is great and it would be wonderful to open
> it via 'javaws -viewer' (like O... jdk) or any other option.
>
> Another issue I could do: JNLPClassLoader does many useless class/resouce
> download queries if many child loaders are in action... let's see later.
>
>
>> >
>> > FYI I compiled icedtea-web-1.7 without plugin and modified the
>> generated shell scripts (sh / bat) to
>> Have you disabled both native and java parts of plugin, or only native?
>>
>> > successfully run my javaws applications on jdk11 (win/linux).
>> > For example: http://jmmc.fr/~bourgesl/Aspro2/ <
>> http://jmmc.fr/%7Ebourgesl/Aspro2/>
>> Great! I'm really glad to hear this. when I was improving ITW launcher to
>> survive jigsaw, usually
>> ITW itself run well, but nearly all client applications were broken
>> because of illegal access.
>>
>
> Yes our apps work almost on jdk11 (few third-party libs are causing
> issues).
> I am very happy ITW works so well on jdk11 (linux), but jigsaw args are
> missing in windows scripts, so I will rewrite them.
>
> PS: how to set jigsaw CLI args in JNLP ? Did you try ? Does it change the
> java command line ?
>
>
>> Thank you very much for improving and verifying the sh/bats.
>>
>
> I tested linux shell scripts and only windows command line (derived from
> linux CLI). It works also on mac (latest update) with ojdk11-28.
>
>
>> I'm looking forward to see changes you mad!
>>
>> For future (1.8) ITW sh/bat launchers are being rewritten to rust, to
>> avoid duplicated bat/sh code.
>> The rust launchers are based 100% on current sh/bat, with improve in
>> prebuild, downloadable packages
>> for both windows and linux (currently linux is distribution only, but
>> windows is downloadable)
>>
>> >
>> > I had many times security dialogs hanging (XAWT lock issue), so I
>> started diagnosing deadlocks
>> > (jvisualvm) and fixed several EDT violations.
>>
>> This is exceptional. I'm aware of those locks, but never had solid
>> reproducer nor time to debug it
>> properly.
>>
>
> Thanks. It is definitely 'done' for javaws, maybe some issue remains in
> control panel ...
>
>
>> This patch will be heavily appreciated, and will be backported to 1.7 and
>> will make candidate for
>> another 1.7 release.
>>
>
> As I only worked on 1.7 code base, I could use webrev or just patches.
> Do you prefer me to rebase on the bleeding edge repo ?
>
> >
>> > If I use -headless, -Xnofork or -Xtrustall, I have no hanging issue.
>> > - Do you have any idea why separate AppContext are absolutely needed
>> that maybe cause XAWT lock
>> > deadlocks ?
>>
>> ITW and sandboxed application should be as separate as possible. Isnt
>> Aseparate appcontext part of
>> it? Maybe not. When I inherrited ITW, this was already there, so I keel
>> in the habit.
>>
>> > - Running jdeps -jdkinternals (from jdk10) on the netx library reports
>> lots of internal jdk usages,
>> > do you plan fixing them ? I could help
>>
>> This should be fixed for future ITW. Any patch is welcomed. This is
>> currently moreover one (busy)
>> man show. So only small steps forward with development, a bit bigger with
>> bugfixes, but much
>> smaller in cleanups.
>>
>
> As it is not blocking, I agree it can stay as it is. However some future
> class removals in jdk could hurt.
>
>>
>> >
>> > 1. Are you interested by some patch in netx code ?
>>
>> Definitely.
>>
> What form ? As webrev on cr.ojdk... ?
>
>
>> > what is your contribution process (I am an openjdk commiter) ?
>>
>> ITW have different contribution process, as it is not hg.openjdk.net,
>> but classpath.org.
>> Looking to the quality of your research and fact that you are OpenJDK
>> commiter, mean that you will
>> post patch or two, I review them and will commit them on your behalf, and
>> then I will nominate you
>> for "classpath hacker" (poetic name:). Doing so, you will get push access
>> to classpath repos.
>
>
>> >
>> > 2. In latest icedtea-web repo, the shell scripts were removed. So what
>> is your plan for windows /
>> > mac compatibility ?
>>
>> As written above - they are replaced by rust launchers. They are not
>> removed, jsut moved, and marekd
>> as deprecated if you built only them (configure switches). Still I intend
>> to maintain them at least
>> for itw 1.8 and maybe more further, as on Linux they are exceptionally
>> useful. But in some time,
>> they are likely to die, yes:(
>>
>> I have never run ITW on mac, nor have any feedback on its usage. Likely
>> with oracle removing javaws,
>> it can change. I have some machines rented from redhat to test ITW deeply
>> on linux, and well, alsoa
>> biton windows, but I'm far from being expereinced window one. Still some
>> effort is done to
>> stabilise it. (many silently known issues for ITW on windows, but no more
>> show stoppers). Main kudos
>> for win port goes to Jacob, Alex and Michal and few students I had
>> misused for it.
>>
>
> Great. I confirm my tests worked on mac too. Having an openjdk with
> installer on mac would be awesome. My scientific users are mainly linux/mac
> addicts.
>
>>
>> >
>> > Finally IcedTea-Web seems a promising alternative on windows for
>> OpenJDK 11, so I think openjdk
>> > distributions should adopt it when OpenJDK 11 will be released.
>> >
>>
>> Thank you for kind words, and an exceptional work you did on launchers,
>> jdk11 testing and EDT
>> violations. I'm looking forward to see the patches, and I hope I will
>> make theirs upstreaming as
>> simple comfortable as possible to return the value.
>>
>
> Thank you for your very positive feedback, I will propose asap patches on:
> 1. Netx code (EDT)
> 2. shell scripts (linux then win)
>
> Kindly regards from France (Grenoble),
> Laurent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20180905/c9f1a558/attachment.html>
More information about the distro-pkg-dev
mailing list