Sean Chou | 2 Jun 11:31 2011
Picon

Re: DnD fails with JTextArea and JTextField

Hi,


I reported, but the system doesn't reply me a bug number. It says "will give me email", 
but I haven't got one yet. Is this the right process, or I might make a problem when 
reporting?

2011/5/27 Pavel Porvatov <pavel.porvatov-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Hi Sean,
Hi all,

    I have a testcase related to DnD failure with JTextArea and JTextField on linux. The 
testcase is as follows:

/*
 * DnDTest.java
 */
import java.awt.Color;
import java.awt.Component;
import java.awt.Dimension;
import java.awt.FlowLayout;
import java.awt.Frame;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;

import javax.swing.JTextArea;
import javax.swing.JTextField;


public class DnDTest extends Frame {
Component c;
public DnDTest() {
super("Single Frame --- AWT Frame");
super.setBackground(Color.gray);
// set layout here.
setLayout(new FlowLayout());
c = new JTextArea("JTextArea component");
c.setPreferredSize(new Dimension(400, 100));
add(c);
c = new JTextField("JTextField component(No IM)");
c.setPreferredSize(new Dimension(400, 20));
add(c);
addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent event) {
System.exit(0);
}
});
setSize(850, 360);
setVisible(true);
}
public static void main(String[] args) {
new DnDTest();
}
}


Reproduce steps:
1. Run the testcase with b143 
2. Open a new file with gedit and input some words like "abcde"
3. Drag "abcde" into JTextField and drop it there.
4. Once more, drag "abcde" into JTextField and then move out of the Frame (keep draging) and drag into JTextField again and drop it.

Expectation:
The second DnD inputs another "abcde" into JTextField.

Result:
The second DnD inputs nothing into JTextField.
Yes, looks like a bug. The test case works on Windows as expected.


Investigation:
The JTextArea as well has this problem, and in step 4, if we drag "abcde" over JTextField and then drop into JTextArea, nothing
is input into JTextArea either. However, if "abcde" is drag into JTextField or JTextArea directly or when JTextArea/Field are
empty as in step 2, it works.


Are there any comments? And can anyone file a bug for it please ?
Anybody can file a bug, http://bugreport.sun.com/bugreport/

Regards, Pavel



--
Best Regards,
Sean Chou

ximalaya | 2 Jun 17:24 2011

Re: How to resolve image tearing

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" <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 >> >> >

Alexander Potochkin | 2 Jun 19:35 2011
Picon

Re: How to resolve image tearing

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.Potochkin@...> 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@...> wrote: >>
>> >On 
> 5/27/2011 7:33 PM, tom.hawtin@... 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 >> >> >
>

Alexander Potochkin | 3 Jun 16:13 2011
Picon

Re: Painting a JComponent without clipping children

Hello Herve

I don't really get it why you need to avoid setting the clip,
but anyway the following may be interesting to you

http://www.pbjar.org/blogs/jxlayer/jxlayer40/

Piet is transforming Swing components using JXLayer component

Thanks
alexp
> (reposted from awt-dev list, I picked up the wrong list before)
>
> Hello,
>
> I'm new to this mailing list and I'm not *really* asking how to do it 
> because I know how it's possible to do it by using a hack (mainly 
> getting and setting the BUFFER and TILE parts of the "flags" field for 
> the JComponent by reflection, and "rewriting" the paintChildren method 
> without the clipping part). I'm using it in the 
> http://sourceforge.net/projects/j661/  project to be able to use 
> custom Swing containers which only offset the position or transform 
> their children graphic context, without clipping them (allowing to use 
> negative positions for the children widgets, for example).
>
> I'm asking if there is a way to do this without playing with the 
> private "flags" field, because I need to be able to do the same thing 
> in a restricted JNLP environment. I know a "regular"' way to do this, 
> but it would be a little cumbersome (offsetting the positions of all 
> children widgets in the parent container, to be sure that the 
> positions of the children are never negative, for example). But it's 
> not very good for performance when something change in the parent 
> container....
>
> There are many projects which either play with this private field, or 
> use transforms, but in this later case they still apply a clipping. Is 
> it possible to play with the Graphics2D clippings for example before 
> using the JComponent paintChildren method - or would this approach 
> work ?  Or would the only way to do it without compromising Security 
> be to have a way to get / set the TILE and BUFFER value of the "flags" 
> field without reflection ?
>
> Thanks by advance if you have ideas about this, and sorry if this 
> prose is not crystal clear ;)
>
> Regards,
>
> Herve
>

pavel.porvatov | 3 Jun 23:14 2011
Picon

hg: jdk7/swing/jdk: 6977587: GTK L&F: jnlp: java.io.IOException thrown when choosing more than 1 file in the dialog

Changeset: 03a828e368ca
Author:    rupashka
Date:      2011-06-04 01:13 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/03a828e368ca

6977587: GTK L&F: jnlp: java.io.IOException thrown when choosing more than 1 file in the dialog
Reviewed-by: alexp

! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java

lana.steuck | 4 Jun 08:04 2011
Picon

hg: jdk7/swing: 4 new changesets

Changeset: 7203965666a4
Author:    schien
Date:      2011-05-20 16:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/7203965666a4

Added tag jdk7-b143 for changeset 14b8e7eee105

! .hgtags

Changeset: 4373d87e6f37
Author:    schien
Date:      2011-05-26 20:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/4373d87e6f37

Added tag jdk7-b144 for changeset 7203965666a4

! .hgtags

Changeset: 93d2590fd849
Author:    jeff
Date:      2011-05-27 14:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/93d2590fd849

7045697: JDK7 THIRD PARTY README update
Reviewed-by: lana

! THIRD_PARTY_README

Changeset: 55e9ebf03218
Author:    lana
Date:      2011-06-02 13:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/rev/55e9ebf03218

Merge

lana.steuck | 4 Jun 08:04 2011
Picon

hg: jdk7/swing/corba: 7 new changesets

Changeset: b06dd44a2740
Author:    schien
Date:      2011-05-20 16:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/b06dd44a2740

Added tag jdk7-b143 for changeset 51ed32f6f4de

! .hgtags

Changeset: 7033a5756ad5
Author:    katleman
Date:      2011-05-25 13:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/7033a5756ad5

7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles
Reviewed-by: ohair, trims

! src/share/classes/com/sun/corba/se/impl/transport/CorbaTransportManagerImpl.java

Changeset: 74eb715474f2
Author:    schien
Date:      2011-05-26 20:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/74eb715474f2

Added tag jdk7-b144 for changeset 7033a5756ad5

! .hgtags

Changeset: 93e77c49b3bb
Author:    miroslawzn
Date:      2011-05-26 13:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/93e77c49b3bb

7046882: Regression : JDK 7b123 : Enum exchanged as parameters using CORBA call results in Exception
Reviewed-by: raginip

! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java

Changeset: 643f267ca234
Author:    jeff
Date:      2011-05-27 14:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/643f267ca234

7045697: JDK7 THIRD PARTY README update
Reviewed-by: lana

! THIRD_PARTY_README

Changeset: 7839048ec99e
Author:    jeff
Date:      2011-05-27 15:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/7839048ec99e

Merge

Changeset: 77ec0541aa2a
Author:    lana
Date:      2011-06-02 13:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/corba/rev/77ec0541aa2a

Merge

lana.steuck | 4 Jun 08:04 2011
Picon

hg: jdk7/swing/jaxws: 5 new changesets

Changeset: 6bd683f2d527
Author:    schien
Date:      2011-05-20 16:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/6bd683f2d527

Added tag jdk7-b143 for changeset 569d1e7ea980

! .hgtags

Changeset: 6158298d2b94
Author:    schien
Date:      2011-05-26 20:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/6158298d2b94

Added tag jdk7-b144 for changeset 6bd683f2d527

! .hgtags

Changeset: c902e39c384e
Author:    jeff
Date:      2011-05-27 15:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/c902e39c384e

7045697: JDK7 THIRD PARTY README update
Reviewed-by: lana

! THIRD_PARTY_README

Changeset: bcca8afc019f
Author:    ohair
Date:      2011-06-01 10:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/bcca8afc019f

7049699: Problem with xml/jax-ws
Reviewed-by: ramap

! jaxws.properties

Changeset: 42bfba80beb7
Author:    lana
Date:      2011-06-02 13:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/42bfba80beb7

Merge

lana.steuck | 4 Jun 08:04 2011
Picon

hg: jdk7/swing/jaxp: 6 new changesets

Changeset: 39bf6dcaab23
Author:    schien
Date:      2011-05-20 16:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/39bf6dcaab23

Added tag jdk7-b143 for changeset 16b847e9bbd7

! .hgtags

Changeset: bee49f47043f
Author:    schien
Date:      2011-05-26 20:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/bee49f47043f

Added tag jdk7-b144 for changeset 39bf6dcaab23

! .hgtags

Changeset: bdf77cbd9958
Author:    ohair
Date:      2011-05-19 08:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/bdf77cbd9958

7044493: Incorrectly formated GPL headers in JDK7 JAXP source drop
Reviewed-by: joehw

! jaxp.properties

Changeset: 775dd77e4730
Author:    lana
Date:      2011-05-20 21:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/775dd77e4730

Merge

Changeset: a70a042c8600
Author:    jeff
Date:      2011-05-27 15:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/a70a042c8600

7045697: JDK7 THIRD PARTY README update
Reviewed-by: lana

! THIRD_PARTY_README

Changeset: 10ca7570f47f
Author:    lana
Date:      2011-06-02 13:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/10ca7570f47f

Merge

lana.steuck | 4 Jun 08:04 2011
Picon

hg: jdk7/swing/langtools: 7 new changesets

Changeset: 8987de9a4ab8
Author:    schien
Date:      2011-05-20 16:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/8987de9a4ab8

Added tag jdk7-b143 for changeset 5faa9eedc44e

! .hgtags

Changeset: 8eb952f43b11
Author:    katleman
Date:      2011-05-25 13:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/8eb952f43b11

7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles
Reviewed-by: ohair, trims

! src/share/classes/com/sun/source/tree/UnionTypeTree.java
! src/share/classes/com/sun/tools/classfile/ClassTranslator.java
! src/share/classes/com/sun/tools/classfile/Dependencies.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java
! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java
! test/tools/javac/4241573/T4241573.java
! test/tools/javac/6508981/TestInferBinaryName.java
! test/tools/javac/TryWithResources/DuplicateResource.java
! test/tools/javac/api/6411310/Test.java
! test/tools/javac/api/T6838467.java
! test/tools/javac/api/T6877206.java
! test/tools/javac/api/TestClientCodeWrapper.java
! test/tools/javac/api/TestJavacTask_Lock.java
! test/tools/javac/api/TestJavacTask_Multiple.java
! test/tools/javac/api/TestJavacTask_ParseAttrGen.java
! test/tools/javac/multicatch/model/ModelChecker.java
! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface1.java
! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface2.java
! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingInterface.java
! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java
! test/tools/javac/tree/T6963934.java

Changeset: 9f25c6a3ac23
Author:    schien
Date:      2011-05-26 20:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/9f25c6a3ac23

Added tag jdk7-b144 for changeset 8eb952f43b11

! .hgtags

Changeset: 6bb526ccf5ff
Author:    mcimadamore
Date:      2011-05-23 11:55 +0100
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/6bb526ccf5ff

7046348: Regression: javac complains of missing classfile for a seemingly unrelated interface
Summary: Types.implementation forces unnecessary symbol completion on superinterfaces of a given type
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/scope/7046348/EagerInterfaceCompletionTest.java

Changeset: 6211df69f7e0
Author:    jeff
Date:      2011-05-27 15:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/6211df69f7e0

7045697: JDK7 THIRD PARTY README update
Reviewed-by: lana

! THIRD_PARTY_README

Changeset: 6762754eb7c0
Author:    jjg
Date:      2011-06-01 11:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/6762754eb7c0

7042623: Regression: javac silently crash when attributing non-existent annotation
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/T7042623.java
+ test/tools/javac/T7042623.out

Changeset: c455e2ae5c93
Author:    lana
Date:      2011-06-02 13:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/swing/langtools/rev/c455e2ae5c93

Merge


Gmane