Hello Ximalaya
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?
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.
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?
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
alexp
Thanks and Best Regards,
xmly
At 2011-05-31 21:39:09??"Alexander Potochkin"
<alexander.potoch...@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.pet...@oracle.com> wrote: >> >> >On
5/27/2011 7:33 PM, tom.haw...@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 >> >> >
