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();
        clip.deltaTime(true);
        clip.doIt();
        clip.doIt();
        clip.doIt();
        clip.doIt();

        System.exit(0);
    }

    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");
        set(value);
        now = deltaTime();
        System.out.println("got: " + get() + " at " + now + "ms");
    }

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

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

    public long deltaTime()
    {
        return deltaTime(false);
    }

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

        if(reset)
        {
            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);
        Toolkit.getDefaultToolkit().
            getSystemClipboard().setContents(s,Clip.this);
    }

    public String get()
    {
        String contents = null;

        StringSelection ss
=(StringSelection)Toolkit.getDefaultToolkit().getSystemClipboard().getContents(C
lip.this);
        try
        {
            contents =
                (String)ss.getTransferData(DataFlavor.stringFlavor);
        } catch(Exception e)
        {
            e.printStackTrace();
        }
        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
Solaris.


Payam
(Review ID: 39466)
======================================================================