Fwd: JDK-8019274

[Holger Brands]

Forgot to send to the mailinglist...

---------- Forwarded message ----------
From: Holger Brands <holger.brands at googlemail.com>
Date: 2013/8/20
Subject: Re: JDK-8019274
To: Stephen Fitch <Stephen.Fitch at oracle.com>


Hi Stephen,

thanks for responding.

Our application has a typical client-server-architecture. The client
application is distributed and installed via Java Webstart.
This client application needs to communicate with other applications
installed on the client machine. It does this via RMI communication
currently.
So bugfix JDK-8019274 is essential for our webstart application to work
properly.

The application users are not inside one intranet, but distributed over the
internet. We as webstart application providers have no control over the
client machines,
it's just the jnlp file.
One group of those users is administered centrally, e.g. their software is
deployed via a policy, but it's not directly under our control.
The other group of users are "stand-alone", e.g. their update their
machines individually.

Short-term solutions that come to my mind:
1.) fix bug 8019274 for Java 7u40, so we can upgrade from 7u21 to 7u40
(assuming no other major regression is found)
2.) if bug 8019274 will not be fixed in Java 7u40 we'll have to stay on 7u21
In this case, it would be good to be able to disable all the "Java Update
Needed" dialogs
that might popup (because of expiration date, security baseline or newer
version available, ...)
BTW, these "Java Update Needed" dialogs make only sense for users that have
the required rights to perform a Java update.
In addition, the bug mentioned here
http://www.java.com/en/download/faq/expire_date.xml#redirect
should be fixed as quick as possible in my opinion.

In general, Oracle should rethink the strategy to "enforce" the newest Java
version available.
As we all know, any software contains bugs, so does the JRE and the deploy
stack.
So always using the newest Java version is not the safest thing to do,
because it might break existing apps as demonstrated by 7u25.
I think it's the responsibility of the webstart application provider to
specify the Java versions that are supported and tested.
The application provider knows best what's the recommended JRE for the
application. So the JRE versions specified in the JNLP file play an
important role.

This leads me to some ideas for a mid- to long-term solution:
1.) Specifying JRE versions in the JNLP file should be more flexible, for
example there needs to be a way to blacklist certain versions.
For example, all 1.7* versions are supported, but not 1.7.0u25
2.) application-specific JRE installable with the webstart application
The best solution would be to have the concept of an application-specific
JRE that is only visible and usable for the dedicated webstart application.
This JRE would be either bundled as part of the application or downloaded
and installed from another URL during application installation.
In any case, it would stay private to the application and the application
provider could fully control the JRE version used.
This would also provide an isolation against other java applications that
might need another JRE version.

Just my two cents,
Holger






2013/8/19 Stephen Fitch <Stephen.Fitch at oracle.com>

>  Hi Holger,
>
> I've forwarded your feedback.
>
> Maybe you can send me more details of your Application and Users/Customers
> offline (from the jdk7u-dev alias).
>
> I can't promise any change for 7u40 around this, but I will help make sure
> we have a clear plan.
>
> Regards, Stephen
>
>  Java Platform Group - Sustaining Engineering
>
> -
>
>  On 8/19/13 11:32 AM, Holger Brands wrote:
>
> Hi there,
>
> please reconsider bug
> JDK-8019274 : RMI thread can no longer call out to AWT thread for webstart
> app
> for target version Java 7 Update 40.
> Currently it seems to be scheduled for Java 7 Update 60.
>
> Unfortunately this issue is not fixed by bugfix
> JDK-8017776 Swing Event Thread does not use JNLP class loader
>
>
>
>