<Swing Dev> How to resolve image tearing
Alexander.Potochkin at oracle.com
Thu Jun 2 10:35:08 PDT 2011
> Hello Alexander,
> Thanks for your information! Then users who are using JDK7 prior to
> b132 need to take care of it.
> BTW, some questions on JDK/OpenJDK releases.
> 1. from the bug URL
> Does it mean openJDK7 and JDK7 are sharing same code base now? or when
> you mention JDK7, you mean openJDK7 actually?
this is the fix I mentioned, if you have it there should be no problem
openJDK7 does share the code base with JDK7
> 2. There is a genealogy diagram here, from the diagram, we can see
> three trains, JDK6 update, OpenJDK 7(JDK7 published as OpenJDK7, this
> might answer the question above), and OpenJDK 6, evolve continuously.
> Can I say, there is actually no relationship between JDK/OpenJDK
> update/build numbers, since they evolve in different trains? For
> example, JDK6 1.6.0_18 has nothing to do with OpenJDK 1.6.0_18?
openJDK6 is a different story, it doesn't automatically share the code
base with JDK 6,
so OpenJDK 1.6.0_18 may lack some fixes from JDK6 1.6.0_18
but the OpenJDK6 team is certainly working on them
> 3. Any feature level differences between Oracle JDK and OpenJDK? Which
> one is recommended for commercial deployment? Must I release my
> component under GPL if we use some JNI codes under OpenJDK?
> (Please help to forward to appropriate mailing list if necessary,
> thank you.)
I am not an official JDK consultant so I can't say what JDK you should use,
please make your mind yourself
> Thanks and Best Regards,
> At 2011-05-31 21:39:09£¬"Alexander Potochkin"
> <Alexander.Potochkin at oracle.com> wrote: >Hello Ximalaya >> Thank you
> all, good conclusion to JDK users, :) > >A small follow-up from me: >
> >JComponent.repaint() indeed called getLocationOnScreen() for a short
> >period of time in JDK 7 >but it was fixed in b132, the bug's number
> is 6993171 > >JDK 6 has never have it > >Let me know if there are any
> problem with that > >Thanks >alexp > >> At 2011-05-28
> 01:40:28£¬"Anthony Petrov"<anthony.petrov at oracle.com> wrote: >> >> >On
> 5/27/2011 7:33 PM, tom.hawtin at oracle.com wrote: >> >> On 27/05/2011
> 15:37, Walter Laan wrote: >> >>>> We didn't change
> JComponent.repaint() to make it "no longer thread >> >>> safe" >> >>>>
> and I don't see why someone may think about it >> >>> >> >>> The bug
> report https://netbeans.org/bugzilla/show_bug.cgi?id=192548 >> >>>
> shows the stack: >> >>> - >> >>> With the latest changes to jdk7 and
> jdk6 update 22 it's no longer true >> >>> due to >> >>> repaint()'s
> call to getLocationOnScreen() which acquires AWT tree lock: >> >> >>
> >> Whilst not ideal, it doesn't seem unreasonable that repaint should
> >> >> acquire a lock (that's usually how thread-safety is done). >> >>
> >> >> The stack trace in that bug doesn't appear to show a deadlock as
> such. >> >> What it does show is Netbean waiting on one of its own
> locks on the AWT >> >> EDT. >> >> >> >> "AWT-EventQueue-0" prio=6
> tid=0x04713c00 nid=0x7d8 in Object.wait() >> >> [0x0599e000] >> >> >>
> >> java.lang.Thread.State: WAITING (on object monitor) >> >> at
> java.lang.Object.wait(Native Method) >> >> - waiting on<0x1c24efb0> (a
> >> >> org.netbeans.lib.editor.util.PriorityMutex) >> > >> >Thanks Tom.
> That's a nice find. >> > >> >I'm not sure if this is documented
> somewhere (if not, it should be), but >> >while being multi-threaded,
> AWT doesn't tolerate blocking of the EDT >> >under any circumstances.
> It's a general understanding/agreement that >> >events must be
> processed as fast as possible. Moreover, this is >> >especially
> relevant to Swing since most of Swing operations should take >> >place
> on the EDT *only*, and as such keeping the thread unblocked is >>
> >vital for Swing to operate correctly. The library even provides the
> >> >SwingWorker utility class that helps process long operations while
> >> >allowing the EDT to handle other events. >> > >> >The only allowed
> case when the EDT can be blocked is displaying a modal >> >(J)Dialog
> by means of calling its setVisible(true) from an event >> >handler. In
> this case AWT/Swing are responsible for keeping the wheel >> >rolling.
> In all other cases a blocked EDT may cause problems that >> >AWT/Swing
> simply can't resolve. >> > >> >So, if the deadlock (or whatever it is)
> is caused by blocking the EDT, >> >this suggests that it is NetBeans
> that's causing the problem, not JDK. >> > >> >-- >> >best regards, >>
> >Anthony >> >> >
More information about the swing-dev