Bug 60142 - Use java.awt.SplashScreen as of Mustang b40
Use java.awt.SplashScreen as of Mustang b40
Status: NEW
Product: platform
Classification: Unclassified
Component: Launchers&CLI
All All
: P1 (vote)
: 7.0
Assigned To: Libor Fischmeistr
Depends on: 178453
  Show dependency treegraph
Reported: 2005-06-16 13:24 UTC by Jesse Glick
Modified: 2014-02-10 14:16 UTC (History)
4 users (show)

See Also:

demo archive (131.50 KB, application/x-gzip)
2005-10-18 10:29 UTC, _ rkubacki
patch in the middle of prototyping (11.05 KB, patch)
2006-07-20 16:52 UTC, _ rkubacki
Details | Diff
test application to reproduce JDK bug 6578570 (17.82 KB, application/x-java-archive)
2009-12-11 13:59 UTC, Marian Petras

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2005-06-16 13:24:49 UTC
There is a new API letting you display a splash screen very early in app
startup, which could lead to improved perceived response time for users
launching the IDE. We should use it. See




Seems to still be buggy. If I try adding e.g.


the splash screen appears but seems to conflict with other windows (on Linux /
Gnome) in a weird way (better seen than described).

Anyway, we would really want to use a jar: URL, but this does not appear to
work. Also there would be other problems:

1. How should launcher know whether JDK is a suitable version, so as to add the
parameter? (Earlier JDKs will not accept it.)

2. How should launcher find the right splash, given that it is sensitive to
current branding? May not be a problem, if -splash is added by the branded
launcher (e.g. "netbeans", not "nbexec").
Comment 1 Marian Mirilovic 2005-06-16 15:50:38 UTC
nice, we've been waiting for something like this for ages
Comment 2 _ rkubacki 2005-07-08 13:10:37 UTC
I have probably different troubles than Jesse. Using mustang b42 and -J-splash:
the image is displayed but not closed when the main window is shown. Also the
attribute in jar file does not work for me on Linux.

Using jar: is probably not feasible for JVM. The goal is to show the image
before JVM is initialized so it would require duplicating of a lot of code.

The attribute in manifest.mf and starting the IDE with 'java -jar boot.jar' does
not help us much as it cannot support branding (and we do not set classpath in
the manifest too). 

adding additional logic to launcher is not nice but probably the only way. We
can limit it to certain cases when it might be easy to find the resource like nb
branding and default locale ('C'?). And we have to check for mustang.
Comment 3 Jesse Glick 2005-07-13 22:29:45 UTC
Re. a hypothetical syntax using a jar: URL: well java -jar foo.jar works with
the splash screen if the manifest specifies one, so clearly the infrastructure
to look in a JAR while loading the image is there.
Comment 4 _ rkubacki 2005-07-14 08:41:01 UTC
If I get it right it uses the same infrastructure as for reading of manifest. It
means there is one known JAR file specified by -jar from which it can read (will
not work if the resource is in a different JAR even if it would be refernced
with Classpath:). And there is no parsing of jar: URLs so decoding
jar:file:/my/foo/bar.jar!/some/resource.png is not implemented in this launcher.
Comment 5 _ rkubacki 2005-10-18 10:24:27 UTC
I tried again and found that I can use one image as an initial splah content and
later replace it with branded/localized one. The initial can be empty
transparent image but needs to have the same size.

-splash does not work for JDK1.5 and older so it is not feasible.

Manifest attribute requires to start JVM with java -jar so we would need to
specify Classpath: in boot.jar. I think Yarda wanted to make this change for any
other reason in the past. I am not sure if xtest can adopt such a change simply.

A lot of relfection would be required :-( 

Also it is not clear to me whether we could set title to be displayed in
application taskbar (currently there is no icon and label 'Java').

Comment 6 _ rkubacki 2005-10-18 10:29:42 UTC
Created attachment 26067 [details]
demo archive
Comment 7 _ rkubacki 2006-07-20 16:52:16 UTC
Created attachment 32060 [details]
patch in the middle of prototyping
Comment 8 _ rkubacki 2006-07-20 16:54:25 UTC
Currently we do too many updates and exeisting implementation is slow for such
case - JDK bug 6449440
Comment 9 Jaroslav Tulach 2009-12-04 11:27:57 UTC

Tomáši, please implement this into nbexec.exe too. Thanks.
Comment 10 Jesse Glick 2009-12-04 11:50:11 UTC
I think

  jargs="$jargs -splash:${userdir}/var/cache/splash.png"

is missing a level of quoting. Did you mean

  jargs="$jargs -splash:\"${userdir}/var/cache/splash.png\""

Comment 11 Jesse Glick 2009-12-04 12:01:21 UTC
You broke JDK 5 compatibility. Restored in core-main #8cb4394a621c.
Comment 12 Jesse Glick 2009-12-04 12:03:16 UTC
BTW two issues I have noticed so far:

1. If you have changed some module since the last startup, even if the splash screen would not have been affected, the initial splash is hidden and replaced by a new copy, creating a flicker effect. This would happen to anyone who simply got some updates from Plugin Manager - not very desirable.

2. Once I got (cannot reproduce):

	at org.netbeans.core.startup.Splash$SplashPainter.repaint(Splash.java:468)
	at org.netbeans.core.startup.Splash$SplashPainter.increment(Splash.java:576)
	at org.netbeans.core.startup.Splash.increment(Splash.java:261)
	at org.netbeans.core.NonGui.run(NonGui.java:119)
	at org.netbeans.core.startup.Main.start(Main.java:319)
	at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:111)
[catch] at java.lang.Thread.run(Thread.java:619)
	at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.netbeans.core.startup.Splash$SplashPainter.repaint(Splash.java:460)
	at org.netbeans.core.startup.Splash$SplashPainter.increment(Splash.java:576)
	at org.netbeans.core.startup.Splash.increment(Splash.java:261)
	at org.netbeans.core.NonGui.run(NonGui.java:119)
	at org.netbeans.core.startup.Main.start(Main.java:319)
	at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:111)
	at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalStateException: no splash screen available
	at java.awt.SplashScreen.checkVisible(SplashScreen.java:164)
	at java.awt.SplashScreen.update(SplashScreen.java:254)
	... 10 more
Comment 13 Quality Engineering 2009-12-05 03:54:08 UTC
Integrated into 'main-golden', will be available in build *200912050227* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/09196a780e12
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #60142: When the IDE starts, it copies its splash screen to var/cache/splash.png (only on JDK6 and newer). The launcher is then supposed to use this splash as an argument to JDK. Implemented only for Unix now.
Comment 14 Jaroslav Tulach 2009-12-05 11:30:01 UTC
Y01 I've just realized that the launcher needs to honor --nosplash option.
Comment 15 t_h 2009-12-08 04:20:30 UTC
windows part + Y01 + quoting in core-main #f3e4bc954373
Comment 16 Jesse Glick 2009-12-08 09:41:22 UTC
Today I restarted the IDE (after killing due to deadlock); the (Mustang) splash screen came up and then my Gnome session immediately died and I had to log in again. JDK 6u17. Probably not reproducible, but something to test for - what happens if splash.png is malformed, etc.?
Comment 17 Quality Engineering 2009-12-10 02:30:26 UTC
Integrated into 'main-golden', will be available in build *200912100200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/f3e4bc954373
User: Tomas Holy <t_h@netbeans.org>
Log: #60142: Use java.awt.SplashScreen
Comment 18 anli 2009-12-11 11:44:27 UTC
Following Jesse's instruction here...


...with this enviroment:

~$ uname -a
Linux anli 2.6.31-16-generic #52-Ubuntu SMP Thu Dec 3 22:07:16 UTC 2009 x86_64 GNU/Linux

~$ java -version
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02, mixed mode)

~$ cat ~/bin/NB

cd /wrk/usr/netbeans/netbeans/bin
./netbeans --userdir /wrk/usr/netbeans/userdir --laf com.sun.java.swing.plaf.gtk.GTKLookAndFeel --jdkhome /usr/jdk -J"-ea" -J"-XX:MaxPermSize=256M" -J"-Xmx1024M"

~$ cat /wrk/cvs/nbsrc/main/nbbuild/user.build.properties


...with NB from trunk (and regardless permit.jdk6.builds flag value) X11 X11 freezes when I try to drag Output or CVS window to make them tabbed - see this screenshot with initial layout:


With added to startup script --nosplash option I get - from time to time - this error console message  - after instant disappearing of the IDE window:

The program '<unknown>' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 145239 error_code 3 request_code 20 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

And this variant seems to be stable for me:

1. --nosplash option is NOT used,
2. userdir/var/cache/splash.png is deleted before IDE start
Comment 19 Jesse Glick 2009-12-11 12:31:52 UTC
The freeze sounds like bug #178453 to me. Are you saying that you can reproduce the freezes if and only --nosplash has not been passed?
Comment 20 Marian Petras 2009-12-11 13:53:41 UTC
Jesse, this is a JDK bug #6578570. It causes that the X server freezes if an application is started with a splash screen and the user tries to drag something.

The bug is currently closed as non-reproducible. I was about to reopen it but found that it is reproducible only on 50% of systems I tried to reproduce it on. It can even be half-100% (see the explanation later) reproducible on one system.

I have a small test application (mostly obtained from a discussion forum at forums.java.sun.com, just further simplified). It works quite well for testing - I will attach it.

For example, on (64-bit) Debian Lenny that I have installed on my system in the office, the bug is not reproducible at all if I run it on X screen 0 (LCD panel attached via DVI) but it is 100% reproducible if I run the same test application on the second X screen (CRT monitor).

At home, I have almost the same configuration; the differences are that I have Ubuntu 8.04 and both the displays are CRTs. Again, I cannot reproduce it on X screen 0 but I can reliably reproduce it on X screen 1.

Both in my office and at home, the two monitors are attached to a single graphics card with an nVidia chip and proprietary nVidia drivers are used.

I tried to reproduce the bug on several other systems running various versions of Ubuntu and was not able to find any exact pattern that would determine whether the bug would be reproducible or not.

I am attaching the test application. Run it with

    java -jar JDK-bug-6578570.jar

To application displays a window with a JTree. Try to drag any of the non-root nodes towards the root node. If the X freezes, go to the console, kill all instances of Java and return back to the X (no need to restart X).
Comment 21 Marian Petras 2009-12-11 13:59:32 UTC
Created attachment 92445 [details]
test application to reproduce JDK bug 6578570

Warning! Running the application (java -jar JDK-bug-6578570.jar) may freeze X until all JVM are killed.
Comment 22 Antonin Nebuzelsky 2010-11-01 17:48:29 UTC
Actually marked as a fixed JDK bug in 6u21. See also my comment in


Anyone able to verify with 6u21 or newer so that we could reenable --splash on Linux?
Comment 23 Jiri Rechtacek 2012-02-16 16:57:15 UTC
Assigned to new owner.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo