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 http://hg.openjdk.java.net/jdk7/swing/jdk/rev/493a9eeb9bca Does it mean openJDK7 and JDK7 are sharing same code base now? or when you mention JDK7, you mean openJDK7 actually? 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. http://openjdk.java.net/projects/jdk6/ 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? 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.) Thanks and Best Regards, xmly At 2011-05-31 21:39:09，"Alexander Potochkin" <[email protected]> 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"<[email protected]> wrote: >> >> >On 5/27/2011 7:33 PM, [email protected] 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 >> >> >
