JDK-8022555 : [macosx] AppleScriptEngine.jar MUST call java.awt.Toolkit.getDefaultToolkit() lazily
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7u6,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: generic
  • Submitted: 2013-08-07
  • Updated: 2013-12-06
  • Resolved: 2013-09-24
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 8
8 b110Fixed
Related Reports
Blocks :  
JDK-7177594 - sun/tools/jrunscript tests should be excluded from javase headless (nightly) execution
Description
This call is preventing headless apps that use ScriptEngine from running.  The way the static init is structured currently, the AWT Toolkit is initialized on registration as a script engine. The  AWT Toolkit init should not take place unless the app uses the AppleScriptEngine.

The following example will cause a menu bar to appear on a headless app (when it should not.)


import javax.script.ScriptEngineManager;

public class EngineTest {
    public static void main(String[] args) throws Exception {
        new ScriptEngineManager();
        Thread.sleep(100000);
    }
}
Comments
Jean-Francois, the fix has been integrated into JDK 8 b110, so you might try this or later build.
08-10-2013
Thanks, if you have a jdk 8 private build for Mac OS that you want me to use, feel free to ask.
19-09-2013
Jean-Francois, it doesn't look like it's the same issue, although I'm not 100% sure. You might want to file a new bug, or wait a bit until the fix for this issue makes it into JDK 8 and see if it helps.
19-09-2013
I'm sorry, but this is a RFE. I understand that it is important to you and, in fact, the fix is already being reviewed, but let's call a spade a spade. Bug, by definition, is when something isn't working according to a spec. Which is not the case for this issue.
19-09-2013
I have a simple Java Main class that instantiates a ScriptManager. As soon as Beehive WebConferencig tool is running, the app never exists. I am wandering if this is not related to this issue. This is very annoying, avatar.js applications are impacted by this behavior and never end. If you think that it is not the same issue, let me know, I will open another bug. The set of running threads. Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.0-b48 mixed mode): "DestroyJavaVM" #10 prio=5 os_prio=31 tid=0x00007fe20c8f1800 nid=0x1007 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "AWT-Shutdown" #9 prio=5 os_prio=31 tid=0x00007fe20b93a000 nid=0x7003 in Object.wait() [0x00000001a1721000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x000000016eb7f4a8> (a java.lang.Object) at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:309) - locked <0x000000016eb7f4a8> (a java.lang.Object) at java.lang.Thread.run(Thread.java:724) "AppKit Thread" #8 daemon prio=5 os_prio=31 tid=0x00007fe20b939000 nid=0x2717 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Service Thread" #7 daemon prio=9 os_prio=31 tid=0x00007fe20b87b000 nid=0x5803 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007fe20b871000 nid=0x5603 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007fe20b86f800 nid=0x5403 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007fe20b87a000 nid=0x5203 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007fe20b85c000 nid=0x3e03 in Object.wait() [0x000000019f8c6000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x000000016e9866f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142) - locked <0x000000016e9866f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189) "Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007fe20b85b800 nid=0x3c03 in Object.wait() [0x000000019f7c3000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x000000016e986138> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) - locked <0x000000016e986138> (a java.lang.ref.Reference$Lock) "VM Thread" os_prio=31 tid=0x00007fe20b859000 nid=0x3a03 runnable "GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007fe20b825800 nid=0x3603 runnable "GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007fe20b826800 nid=0x3803 runnable "VM Periodic Task Thread" os_prio=31 tid=0x00007fe20b883800 nid=0x5a03 waiting on condition JNI global references: 12 Heap PSYoungGen total 38912K, used 3395K [0x000000016e980000, 0x0000000171480000, 0x0000000199480000) eden space 33792K, 10% used [0x000000016e980000,0x000000016ecd0fe0,0x0000000170a80000) from space 5120K, 0% used [0x0000000170f80000,0x0000000170f80000,0x0000000171480000) to space 5120K, 0% used [0x0000000170a80000,0x0000000170a80000,0x0000000170f80000) ParOldGen total 87040K, used 0K [0x0000000119480000, 0x000000011e980000, 0x000000016e980000) object space 87040K, 0% used [0x0000000119480000,0x0000000119480000,0x000000011e980000) Metaspace total 4508K, used 3642K, reserved 132096K data space 4112K, used 3251K, reserved 1024K class space 396K, used 391K, reserved 131072K
19-09-2013
Thank you.
19-09-2013
http://www.mail-archive.com/nashorn-dev@openjdk.java.net/msg00923.html
19-09-2013
please implement it
19-09-2013
Leonid, -Djava.awt.headless=true is a bit of a distraction on this. Where the problem comes into play is when you run a simple jrunscript or use ant with embedded scripting and see a dock entry/menubar when none is expected (or desired.) This influences whether someone (paying customers) uses java (in this case Nashorn) as a solution to a problem. Victor, a fix was provided. Should be a matter of hours to check in and test.
19-09-2013
The fix is easy, so one day.
19-09-2013
how many days you need to impl it?
19-09-2013
You should run the tests with -Djava.awt.headless=true if you want them to be headless. This is what this property is for. Otherwise, we can't guarantee that you won't see any GUI stuff. It would be a bug only if -Djava.awt.headless=true didn't work. Right now, it looks like RFE to me. Personally, I'm OK with implementing it in JDK 8, but this is up to my manager to decide.
19-09-2013
This is a BUG, not a feature. This is is a long standing BUG that has only become visible in JDK8. This is preventing Nashorn from running headless and from being used as it was intended, a server and a scripting tool. I filed as a P2 originally, and provided a fix. There is no reason why this could not have made it into JDK 8 other than neglect.
19-09-2013
re-targeted to jdk9 as Enhancement We passed Feature Complete for jdk8 and so no more sub-features to keep stabilization going well!
19-09-2013
If you aren't running your tests with -Djava.awt.headless=true then, strictly speaking, this is not a bug, but a RFE, because only in the headless mode we can guarantee that an app won't have the global menu. Considering that the proposed change is rather simple, I see no problems taking it into JDK 8 release, assuming that it fixes your problem. Have you verified it?
13-09-2013
"they are kinda headless in a sense that they don't use any UI classes" I didn't use -Djava.awt.headless=true to verify that it was truly headless. I simply moved /System/Library/Java/Extensions/AppleScriptEngine.jar out of the way. If out of the way, then there is no menubar or dock icon. Putting it back in place, there is a menubar and dock icon. Where this affects us most is running test suites, it slows down each launch, because of the awt init. (I recently had a customer inquiry about the same issue.)
13-09-2013
I need more information: I tried running attached test with -Djava.awt.headless=true and it didn't display the global menu bar. Do you run your tests as true headless apps (with -Djava.awt.headless=true ) or they are kinda headless in a sense that they don't use any UI classes?
13-09-2013
Not TCK failure, been here since 7u6, so I'd like to defer it.
03-09-2013
I object to deferment. Not having this fix, significantly affects the first release of Nashorn in JDK8. Not having this fixed, prevents Nashorn from running headless and makes one of Nashorn's major features, shell scripting, irritating and slow. The reason it was not an issue for Rhino in the JDK7 was no one realized what was causing the flashing window/menubar issues (head in sand.) Having AWT inited when it is not needed is a serious deficiency.
03-09-2013
Considering that this issue only affect headless apps that use ScriptEngine, I think that the priority can be lowered to P3.
22-08-2013
The change should be in http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/690161232823/src/macosx/classes/apple/applescript/AppleScriptEngineFactory.java. A suggested patch would be; --- /tmp/tmp1.txt 2013-08-08 14:52:23.000000000 -0300 +++ /tmp/tmp2.txt 2013-08-08 14:51:00.000000000 -0300 @@ -30,14 +30,13 @@ import javax.script.*; public class AppleScriptEngineFactory implements ScriptEngineFactory { private static native void initNative(); + private static volatile initialized = false; + static { - java.awt.Toolkit.getDefaultToolkit(); - System.loadLibrary("AppleScriptEngine"); - initNative(); TRACE("<static-init>"); } static void TRACE(final String str) { // System.out.println(AppleScriptEngineFactory.class.getName() + "." + str); @@ -216,10 +215,18 @@ /** * Returns an instance of the ScriptEngine associated with this ScriptEngineFactory. * * @return new AppleScriptEngine with this factory as it's parent */ - public ScriptEngine getScriptEngine() { + public synchronized ScriptEngine getScriptEngine() { AppleScriptEngine.checkSecurity(); + + if (!initialized) { + initialized = true; + java.awt.Toolkit.getDefaultToolkit(); + System.loadLibrary("AppleScriptEngine"); + initNative(); + } + return new AppleScriptEngine(this); } }
08-08-2013