Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4178009

NativeClipboard.setContents causes lostOwnership on second invocation



    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:
    • Verification:



        Name: js5519 Date: 10/01/98

        When setting contents of the native clipboard for
        the second time, a lostOwnership event is received
        even if the contents of the native clipboard is
        owned by the caller. The inappropriate lostOwnership event returns the new,
        instead of the old contents. Furthermore, the second setContents call takes 5
        seconds to complete, severely degrading performance. A similar performance
        problem can be observed when using native drag & drop (a separate bug report is
        being submitted on the dnd issue).
        Included below is java source code demonstrating the native clipboard bug. The
        problem does not occur under JDK 1.1.6

        import java.awt.*;
        import java.awt.datatransfer.*;
        import java.awt.event.*;

        public class Clip implements ClipboardOwner
            protected long time = 0;

            public static void main(String args[])
                Clip clip = new Clip();


            public void doIt()
                long now = 0L;
                String value = null;

                value = Integer.toString((int)(Math.random()* 1000));
                now = deltaTime();
                System.out.println("set: " + value + " at " + now + "ms");
                now = deltaTime();
                System.out.println("got: " + get() + " at " + now + "ms");

            public void lostOwnership(Clipboard clipboard, Transferable contents)
                long now = 0L;

                    String s =
                    now = deltaTime();
                    System.out.println("lost ownership of the " +
                                       clipboard.getName() +
                                       " clipboard with contents:" + s +
                                       " at " + now + "ms");
                    } catch(Exception e)

            public long deltaTime()
                return deltaTime(false);

            public synchronized long deltaTime(boolean reset)
                long result = 0L;

                    time = System.currentTimeMillis();
                    result = time;
                } else
                    long now = System.currentTimeMillis();
                    long newTime = now - time;
                    time = now;
                    result = newTime;

                return result;

            public void set(String string)
                StringSelection s = new StringSelection(string);

            public String get()
                String contents = null;

                StringSelection ss
                    contents =
                } catch(Exception e)
                return contents;

        In the bug I submitted, there were actually two problems. Although I'd
        first like to point out that the bug was reported against jdk1.2beta4 on
        Windows NT 4.0sp3. The first issue is one of performance when a lost
        ownership event happens. The second is the that the lost ownership
        behavior is different from that of jdk1.1.6 on Windows NT. Also, I tried
        out Clip on Solaris and obtained results similar to that you reported:
        the first set is extremely slow but subsequent ones are fast.

        Here are the results I see on various Java and system platforms:

        JDK1.1.6 on windows NT. Notice that no lost ownership events are being
        sent since the owner is the same.

        D:\pvg_psa\vobs\fs\src>d:\apps\jdk1.1.6\bin\java Clip
        set: 359 at 20ms
        got: 359 at 250ms
        set: 428 at 20ms
        got: 428 at 10ms
        set: 722 at 30ms
        got: 722 at 0ms
        set: 551 at 0ms
        got: 551 at 0ms

        jdk1.2beta4 on windows NT. Notice how the second set is followed by a
        lost ownership event with incorrect information. Also notice the severe
        performance hit.

        D:\pvg_psa\vobs\fs\src>java Clip
        set: 619 at 10ms
        got: 619 at 941ms
        set: 236 at 0ms
        lost ownership of the System clipboard with contents:236 at 0ms
        got: 236 at 5008ms
        set: 827 at 0ms
        got: 827 at 0ms
        set: 725 at 0ms
        lost ownership of the System clipboard with contents:725 at 0ms
        got: 725 at 5007ms

        jdk1.2beta4 on Solaris 2.6. Notice that the result is similar to yours.

        set: 120 at 8ms
        got: 120 at 4760ms
        set: 842 at 3ms
        lost ownership of the System clipboard with contents:120 at 2ms
        got: 842 at 1ms
        set: 47 at 1ms
        lost ownership of the System clipboard with contents:842 at 0ms
        got: 47 at 1ms
        set: 20 at 1ms
        lost ownership of the System clipboard with contents:47 at 0ms
        got: 20 at 1ms

        So, aside from the performance problem there are two things are with the
        Windows NT jdk1.2b4 behavior. First, there is an incorrect call back to
        lostOwnership when in fact the clipboard owner has not changed. And
        second, the Transferable sent to lostOwnership is the wrong
        Transferable. Refer to the NT and Solaris logs to see the differences in
        the Transferable returned by lostOwnership.

        In addition, I'd like to point out that the NT performance problem
        happens on every other set and not just at initialization time like on

        (Review ID: 39466)


            Issue Links



                mbronsonsunw Mike Bronson (Inactive)
                duke J. Duke (Inactive)
                0 Vote for this issue
                0 Start watching this issue