<Swing Dev> JSplitPane / heavyweight vs. lightweight components

[Alexander Potochkin]

Hello Christopher
>> I wish we could have turned it on by default,
>> but it caused regressions in the users' code
>> so we made it optional to preserve the backward compatibility
> User's code is broken whenever it is not on and native components are
> used. It is hard to figure out this property.
>
> When I upgraded our codebase to Java 7  (at work), I had issues at
> certain places (empty arrays were returned instead of nulls for
> example) but I was happy to fix those places and have the newest Java
> and more importantly a more coherent logic of the runtime. Are you
> implying that these new behaviors are regressions and should have had
> corresponding properties to be active
> (-Djava.awt.emptyArraysInsteadOfNull=true)?

I don't think that those problems with arrays are related to Swing/AWT,
we always do our best to preserve backward compatibility

(when we don't, our customers quickly remind us about that)

>
> Are there so many regressions that it outweighs the benefits of having
> smart invalidation by default? Why not have a
> "-Djava.awt.dumbInvalidate=true" for those regressions instead?

There were enough serious regressions that prevented us from enabling 
the new invalidation mechanism.
The existing mode is not "dumb invalidate", it is just the validation 
we've had from the beginning.

>
> Note that this topic is of interest for me because I ship a library
> that contains native components. I am sure that I will occasionaly
> lose time and effort with users before finding out dumb invalidation
> was the culprit.

I pretty understand your feelings and,
by the way, I spent descent amount of time trying to keep the new 
validation
and backward compatibility at the same time, alas it doesn't seem to be 
possible

Thanks
alexp

>
> Cheers,
> -Christopher