Forgot to send to the mailinglist... ---------- Forwarded message ---------- From: Holger Brands <[email protected]> Date: 2013/8/20 Subject: Re: JDK-8019274 To: Stephen Fitch <[email protected]>
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 <[email protected]> > 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 > > > >
