<Swing Dev> JSplitPane / heavyweight vs. lightweight components
Alexander.Potochkin at oracle.com
Thu Jan 19 07:00:33 PST 2012
>> 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
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
and backward compatibility at the same time, alas it doesn't seem to be
More information about the swing-dev