This was entered in bugtraq (4648042 see : 

http://developer.java.sun.com/developer/bugParade/bugs/4648042.html )

============================================


Description 
FFJ40EE-EA #020301_1
jdk1.4.0, Solaris 5.8
window configuration MDI
When "some" modules is first installed during the first
start and the ide is started in MDI mode, then there are two types of
corruption:

1. properties window is undocked and has size 0 or
2. the workspace is wrongly repainted e.g. when editor is opened

Why this module doesn't come with his xml in {ide_home}/system/Modules and
therefore is recognized as newly installed during the first start?

Note, if ide is started in SDI first time and the switched into MDI or if the
ide is killed and started again - everything is ok.

Looks like there is some problem in ModuleInstall. We cannot trace it here
because we haven't acces to your source code. Please evaluate this on your
side.


How to reproduce:

1.Install FFJ40EE EA with xxxxx developer modules.
2.Start ide first time (against fresh userdir) in MDI mode
3.Properties will be undocked or main MDI split will be blue and next opened
editor is placed over explorer.


Workaround 
Put proper com-sun-forte-st-ipe.xml into {ide_home}/system/Modules or delete
solaris-native.jar before first start of FFJ40EE EA.

Evaluation 
xxxxx@xxxxx 2002-03-06

Currently, the ifdef module xml file is not generated or installed and the
problems are reproducible. When the ifdef xml file is added to the ide, the
problems observed are no longer there.




xxxxx@xxxxx Fri Mar  8 00:51:05 PST 2002

George and I have been looking at it today. We've reached the
following conclusions so far:
(*) The missing .xml file in system/Modules is not the culprit.
The problem can be observed even with this file in place
(*) We thought perhaps this was an issue of missing Solaris patches
(which is often the case when you have Swing redrawing problems)
but this problem has been observed on fully patched systems.
Unfortunately the problem does not seem to be 100% reproducible,
it happens Now And Then (tm).

Here's my current hypothesis.  Whenever you run into problem in
Swing it's often because you've improperly accessed (or worse,
modified) component state for visible components from any other
thread than the AWT thread (the "event dispatching thread").

So I'm guessing some code is doing this at startup, which leaves
the window system in a corrupted state which in turn results
in the incorrect window bounds etc. which seems to lead to the
various problems described in this bugreport.

So I instrumented my Swing runtime to check that whenever
a Component method is called, and the component is visible,
the current thread had better be the event dispatch thread.

And I found that this condition is violated! However, it doesn't
seem to be violated by ifdef - it's by the Setup Wizard code.

Here's some sample stacktraces that are printed out.  I'm not sure
if this is the bug - but it's certainly plausible (and in any case
the below component access is illegal and needs to be fixed).

***** Swing called from non-AWT-EventQueue thread "Folder Instance Processor"
java.lang.Exception: Stack trace
at java.awt.Component.ensureEventThread(Component.java:5521)
at javax.swing.JComponent.setEnabled(JComponent.java:1885)
at javax.swing.AbstractButton.setEnabled(AbstractButton.java:1532)
at org.openide.WizardDescriptor.updateState(WizardDescriptor.java:457)
at
org.netbeans.core.ui.SetupWizard$InitializedWizardDescriptor.updateState(SetupWizard.java:403)
at org.openide.WizardDescriptor$Listener.stateChanged(WizardDescriptor.java:941)
at
org.netbeans.core.ui.WizardFolder$CompoundIterator.setIterators(WizardFolder.java:171)
at org.netbeans.core.ui.SetupWizard.createInstance(SetupWizard.java:150)
at
org.openide.loaders.FolderInstance.defaultProcessObjects(FolderInstance.java:571)
at org.openide.loaders.FolderInstance.access$100(FolderInstance.java:45)
at org.openide.loaders.FolderInstance$2.run(FolderInstance.java:456)
at org.openide.util.Task.run(Task.java:152)
at
org.openide.util.RequestProcessor$ProcessorThread.run(RequestProcessor.java:622)

***** Swing called from non-AWT-EventQueue thread "Folder Instance Processor"
java.lang.Exception: Stack trace
at java.awt.Component.ensureEventThread(Component.java:5521)
at javax.swing.JComponent.disable(JComponent.java:2587)
at java.awt.Component.enable(Component.java:817)
at java.awt.Component.setEnabled(Component.java:782)
at javax.swing.JComponent.setEnabled(JComponent.java:1890)
at javax.swing.AbstractButton.setEnabled(AbstractButton.java:1532)
at org.openide.WizardDescriptor.updateState(WizardDescriptor.java:458)
at
org.netbeans.core.ui.SetupWizard$InitializedWizardDescriptor.updateState(SetupWizard.java:403)
at org.openide.WizardDescriptor$Listener.stateChanged(WizardDescriptor.java:941)
at
org.netbeans.core.ui.WizardFolder$CompoundIterator.setIterators(WizardFolder.java:171)
at org.netbeans.core.ui.SetupWizard.createInstance(SetupWizard.java:150)
at
org.openide.loaders.FolderInstance.defaultProcessObjects(FolderInstance.java:571)
at org.openide.loaders.FolderInstance.access$100(FolderInstance.java:45)
at org.openide.loaders.FolderInstance$2.run(FolderInstance.java:456)
at org.openide.util.Task.run(Task.java:152)
at
org.openide.util.RequestProcessor$ProcessorThread.run(RequestProcessor.java:622)


What I'm going to do now is see if I can wrap this setup wizard
into a SwingUtilities.invokeAndWait() and see if this fixes this
bug.   Of course, I can't be 100% confident since this bug only shows
up intermittently - but since it usually triggers at least once in
every five startups, if I can bring the IDE up 10 times without triggering
it I'll feel better. Perhaps not justifiably so, since tweaking with
invokeLater can (and will) change timings of things which might just
hide this bug on my machine configuration...

If anyone in Prague is looking at this and have some insights in
what might be going on (not just with the Setup Wizard - with our
module (look at the "ifdef" module in the closed source repository
- in particular the module install class (IpeModule.java), the
manifest.mf file, and the layer file (system.xml)) please let me
know.






One note about the line numbers in the above stack
trace; I've been reproducing this with the -trunk-, not EA, so
if the line numbers don't make sense, be sure to check the
trunk sources.



Eval:

The problem seems to be following.
There is loaded window sys before the Setup wizard comes up. And somtimes
during the time due to some race condition is set mode for the Properties
window (NbNodeOperation.Sheet source) in the intention is SDI mode, and when
then is set in the wizard to MDI, it doesn't reset the default accordingly.

I haven't find the solution up to now. Thought only problem is finding of node
in updateTitle method of NbNodeOperation.Sheet, which was performed sometime
before the Setup Wizard, but wasn't enough to by pass it.

The problem is probably the fact the window sys is due some race condition
somtimes already set when appears the Setup Wizard, probably not deterministic
enough startup sequence. Or there could be a problem when setting the mode
(SDI/MDI first time is not done the switching work) in Setup Wizard for the
first time.

Leaving for Dafe who knows more about it, and be back on Monday.
But is seems the problem is in core.