JDK-8019274 : RMI thread can no longer call out to AWT thread for webstart app
  • Type: Bug
  • Component: deploy
  • Affected Version: 7u25,8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • Submitted: 2013-06-24
  • Updated: 2020-10-23
  • Resolved: 2014-02-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9
7u65Fixed 8u11 b01Fixed 9Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
Java(TM) SE Runtime Environment (build 1.7.0_40-ea-b29)
Java HotSpot(TM) Client VM (build 24.0-b48, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
We have a client-server app where the client is notified over RMI from the server using SwingUtilities.invokeLater. These calls all fail with a NullPointerException when our application is launched with Java Web Start, but succeed when launched as a local application

REGRESSION.  Last worked in version 7u21


ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.NullPointerException
        at sun.awt.SunToolkit.getSystemEventQueueImplPP(Unknown Source)
        at sun.awt.SunToolkit.getSystemEventQueueImplPP(Unknown Source)
        at sun.awt.SunToolkit.getSystemEventQueueImpl(Unknown Source)
        at java.awt.Toolkit.getEventQueue(Unknown Source)
        at java.awt.EventQueue.invokeLater(Unknown Source)
        at javax.swing.SwingUtilities.invokeLater(Unknown Source)
        at com.nexgenfs.process.processcontroller.ui.MainPanel$PListener.changed(MainPanel.java:242)
        at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
        at sun.rmi.transport.Transport$1.run(Unknown Source)
        at sun.rmi.transport.Transport$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Unknown Source)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
        at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
        at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
        at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:178)
        at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:132)
        at com.sun.proxy.$Proxy15.changed(Unknown Source)
        at com.nexgenfs.process.processcontroller.manager.ManagerImpl$4.fire(ManagerImpl.java:717)
        at com.nexgenfs.process.processcontroller.manager.ManagerImpl$7.run(ManagerImpl.java:768)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
        at java.lang.Thread.run(Thread.java:662)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Was not able to reduce to a simple test case
---------- END SOURCE ----------
Comments
SQE OK to take the fix into CPU14_03
03-03-2014

Release note item created JDK-8029713. Dave to add suggested Known Issue text. Retargeted to 8u20
06-12-2013

Release team: Dos this required a known issue for JDK 8? If so please see http://aseng-wiki.us.oracle.com/asengwiki/display/JavaDocumentation/Release+Notes+Process. Once known issue has been sorted out this is approved for deferral so you can update this and target it to 8u20.
06-12-2013

SQE-OK to defer this issue to 7u60/8u20
27-11-2013

Artem promised to transfer the fix concept to Petr on Tue, Nov 5
03-11-2013

Artem, please update the bug on eng conclusion and move back to developer
28-10-2013

ILW H:H:M Impact: High - blocking deployment, regression Likelihood: High - reported by many Workaround: Medium/High - there is a comment I've seen of an ugly workaround and so take it for medium
17-10-2013

retargeted to 7u60 as RT-approved
12-08-2013

SQE agreed to defer in 08/01 RT Triage meeting - Penni will mark approved for deferral
01-08-2013

Reviewed in the RT - Triage meeting - as long as team has enough bandwidth to look at - lets keep it open and investigate - but we are also very concerned with touching this area this late in the cycle. Ask for daily reports on this issue.
30-07-2013

Is there any workaround we can give developers for this ? This is a popular issue reported by developers and customers.
29-07-2013

we still don't know the right way to fix it, so doubts we'll be able to resolve it in 7u40.
26-07-2013

is it critical or deferral case? At this stage only blocker/stoppers might be submitted as critical, the rest should be 7u40-defer-request
26-07-2013

I confirm: this issue and RT-31486 are different bugs.
26-07-2013

It's not a dup of the JavaFX issue. The resulting stack trace is the same, but the conditions causing the failure are very different.
26-07-2013

If this is a dup - please close this bug and remove the critical-watch label.
26-07-2013

The fx testcase from above comment is duplicate for JDK-8020929
24-07-2013

I came up with a simple (for RMI...) test case to demonstrate this problem and it is indeed broken.
15-07-2013

This issue is much more complicated than the AWT issues. The problem here is that RMI calls are made from the RMI thread pool which is not associated with any AppContext. I'm discussing possible solutions with Artem Ananiev and Stuart Marks. We may have to split this into two issues, one to fix core-libs and the other to fix deploy to accommodate the changes in core-libs.
12-07-2013

I think a bunch of issues on the table are all related. This failure also looks like JDK-8019261.
09-07-2013

is this same root cause of 8017776: Swing Event Thread does not use JNLP class loader ?
09-07-2013

calls all fail with a NullPointerException when our application is launched with Java Web Start, but succeed when launched as a local application
27-06-2013

Update from customer: ==================================== Hi Nelson, Thanks for taking the time to contact me about my bug report. Unfortunately, our application is behind a firewall and connects to a proprietrary database, so you can't access it. However, I have found multiple reports of related bugs: https://forums.oracle.com/thread/2552214 https://forums.oracle.com/thread/2552941 https://forums.oracle.com/thread/2552789 https://forums.oracle.com/thread/2552799 Bug report 9004450 in your system is probably a duplicate. Also, it appears that the same bug was introduced into 6u51 which was pushed out to Apple users, but Apple have since patched it: http://lists.apple.com/archives/java-dev/2013/Jun/msg00055.html I hope this information is useful in resolving the problem. Regards, Robert ====================================
27-06-2013