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
