<Swing Dev> JSplitPane / heavyweight vs. lightweight components
chrriis at gmail.com
Tue Jan 17 12:47:30 PST 2012
>>> Does this means there is going to be some work in JDK 8 so that the
>>> smart invalidation becomes the default?
> 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
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?
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.
More information about the swing-dev