Question is if this custom dialog size should be persisted between IDE sessions or not and if yes how to reset custom
dialog size to default (based on customizer panel preferred size).

I wouldn't base the size on the customizer preferred size or anything except when the user has not resized it yet. I
would just base it on the size the user has resized the dialog only; at that point the user is telling us...I want this
size, and that should override the preferred size of any customizer. If a given customizer needs/requires scrollbars or
something then the module owners of those things should handle that, and in most cases those won't even be needed. 

Then if the user makes it bigger or smaller it is up to them to set it as needed. Between IDE sessions they may change
monitors or something, so a couple things could be done (on start...new IDE session):

1) Leave it as is and let the user sort it out. Say they had two monitors up and removed one. Maybe they had the dialog
stretched over two of them or more. Now it is too big for their entire display. They can then resize it to fit.

2) On start, if the dialog size is larger than the total visible area obtained by code I'll paste below, then resize it
to at least fit within that area. Set the resized size for persistence to this value:
        GraphicsConfiguration wgf = WindowManager.getDefault().getMainWindow();
        GraphicsConfiguration[] gfs = wgf.getDevice().getConfigurations();
        Rectangle largestX = null;
        Rectangle largestY = null;
        for(GraphicsConfiguration gf: gfs){
            Rectangle lr = gf.getBounds();
            if(largestX==null||lr.x>largestX.x){
                largestX = lr;
            }
            if(largestY==null||lr.y>largestY.y){
                largestY = lr;
            }
        }

        //the below values should be the largest actual
        //viewable areas we have obtained by figuring out
        //which rectangles/viewable areas are further over
        //and further down and their widths and heights and
        //them adding them together respectfully.
        int gwidth = largestX.x + largestX.width;
        int gheight = largestY.y + largestY.height;

I think that code will work with any graphics configuration. I don't know of any it shouldn't. On systems without a
virtual display with multiple video cards where the devices are kept separate and not merged into a virtual one that
should technically still be correct per a specific divide between the individual screens. Those separate devices and
screens really become independent at that point and can not have windows stretched onto them from other devices. But, it
is hard to tell with the different hardware allowing for some really tricky things to be done. I'm pretty confident that
should be a good solution without having many different configurations available for testing.

Technically #2 could be used dynamically every time the dialog is to be shown. That would make it work in the cases
where a monitor is disconnected or the resolution is changed while working. It would keep the users resize relative to
their changes as the dialog size would only be changed without their input when it can't actually fit within their
actual display size.

That said, if the user can always control the size, and the dialog logic doesn't make guesses about the size for them
and resize if too big for the actual display, then issues which might arise where some specific configurations error out
on such logic, such as incorrectly guessing the actual viewable area size, won't matter. #2 could always be an option
under Tools|Options|Miscellaneous|Appearance if that can be made into some kind of a SPI, or if you think that #2 works
well enough it is probably fine. 

I know for me I would rather if I pack up my laptop and go to another location and external monitor that I would like
the IDE to dynamically fit the dialog into my available viewable screen size even if the IDE is already started without
me having to it, but maybe there are cases where the user may need to resize the dialog larger than their display size.
Does anyone else think that is a possibility? I don't see me ever doing it, but who knows.

Notice within this comment the display size I'm referring to is specifically the size of their total visible area and
not just a single monitor. This way if the dialog is stretched to fit on more than one monitor it can remain that size
until the user changes it back.

*** Issue 157441 has been marked as a duplicate of this issue. ***

Unfortunately I am not able to distinguish between user resize and system resize. Even when dialog is opened 2
COMPONENT_RESIZED events are comming. If I add component listener to window using invokeLater 1 COMPONENT_RESIZED EVENT
comes. I need somehow to filter these event out. I cannot say how many events will come (on different JDKs/platforms)
and I do not see reliable/deterministic way how to ignore them.

So result so far is:
1. Leave dialog size purely on user and just to check edge cases like monitor size so that dialog will not become too
big and do not resize dialog automatically. It includes store size of dialog so that user need not resize it on every
opening. IMO it is better.

2. Keep original code with current drawbacks.

Issues before: #153877, #101501.

>1. Leave dialog size purely on user and just to check edge cases 
>like monitor size so that dialog will not become too
>big and do not resize dialog automatically. It includes store 
>size of dialog so that user need not resize it on every
>opening. IMO it is better.

This is the case I have been thinking of, and applies to the code and ideas above. To me this makes most sense. Then,
when opened, if larger than the complete viewable area of the user then resize it to fit within that area, but not 3/4
or 4/5 of the screen size, but as wide as possible, maybe a few pixels free on each size or something, but that at most.
That puts that in the users control, and seems to make most sense other than letting the inner components change the
size on the user as that is confusing and makes it hard to use. If an inner component needs scroll bars then it can do
what it needs to do.

core-main #8001beb426ce

Size of inner customizer panel is now controlled by dialog size. Please test how it works. There is check for display
size to avoid problems when display is resized down.

*** Issue 159448 has been marked as a duplicate of this issue. ***

Also dialog bounds are saved between sessions. Please test if it works as expected.

Note: Now some single line text fields do not display all text eg. Arguments or VM Options on Run tab. If it would be
problem even with default font size we can either add multiline component with vertical scrollbar or use value editor
similar to value editor used in Form designer.

I start testing. Thanks for getting to this again. I have to update my NB sources etc. Which IDE version are you using
for dev these days? I'll use the same as you. Thanks.

Integrated into 'main-golden', will be available in build *200903251400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/8001beb426ce
User: Marek Slama <mslama@netbeans.org>
Log: #156689: Avoid automatic resizing of Project properties dialog.

Integrated into 'main-golden', will be available in build *201004210200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/8978927980e1
User: Jesse Glick <jglick@netbeans.org>
Log: Typo in prefs key for #156689.