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").
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.
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.
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.
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').
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):
[catch] at java.lang.Thread.run(Thread.java:619)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
Caused by: java.lang.IllegalStateException: no splash screen available
... 10 more
Comment 13Quality Engineering
2009-12-05 03:54:08 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 17Quality Engineering
2009-12-10 02:30:26 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
./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
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).