Bug 60142

nice, we've been waiting for something like this for ages

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').

Created attachment 26067 [details]
demo archive

Created attachment 32060 [details]
patch in the middle of prototyping

Currently we do too many updates and exeisting implementation is slow for such
case - JDK bug 6449440

core-main#09196a780e12

Tomáši, please implement this into nbexec.exe too. Thanks.

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\""

?

You broke JDK 5 compatibility. Restored in core-main #8cb4394a621c.

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):

java.lang.NullPointerException
	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)
java.lang.reflect.InvocationTargetException
	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

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.

Y01 I've just realized that the launcher needs to honor --nosplash option.

windows part + Y01 + quoting in core-main #f3e4bc954373

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.?

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

Following Jesse's instruction here...

http://forums.netbeans.org/viewtopic.php?t=20754

...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
#!/bin/bash

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
cluster.config=basic

permit.jdk6.builds=true
nbjdk.home=/usr/jdk/ 

...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:

http://gaydenko.com/tmp/hang01.png

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

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?

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).

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.

Actually marked as a fixed JDK bug in 6u21. See also my comment in

http://netbeans.org/bugzilla/show_bug.cgi?id=178453#c12

Anyone able to verify with 6u21 or newer so that we could reenable --splash on Linux?

Assigned to new owner.