United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4884956 : REGRESSION:datatransfer.Clipboard.setContent deals with the queue now

Details
Type:
Bug
Submit Date:
2003-06-27
Status:
Closed
Updated Date:
2004-04-23
Project Name:
JDK
Resolved Date:
2003-08-08
Component:
client-libs
OS:
solaris_2.6
Sub-Component:
java.awt
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0
Fixed Versions:
5.0 (tiger)

Related Reports
Duplicate:
Relates:

Sub Tasks

Description

Name: sdR10048			Date: 06/27/2003


Filed By      : SPB JCK team (###@###.###)
JDK           : java full version "1.5.0-beta-b09"
JCK           : 1.5
Platform[s]   : Solaris
switch/Mode   : 
JCK test owner : http://javaweb.eng/jct/sqe/JCK-tck/usr/owners.jto
Failing Test [s] :
    api/java_awt/datatransfer/Clipboard/index.html#simple[Clipboard0006]


Specification excerpt:
======================
--------- J2SE API spec v.1.5 ---------
...
public void setContents(Transferable?contents,
                        ClipboardOwner?owner)

Sets the current contents of the clipboard to
the specified transferable object and registers
the specified clipboard owner as the owner of 
the new contents. 

If there is an existing owner registered, that owner 
is notified that it no longer holds ownership of the 
clipboard contents. The method throws IllegalStateException 
if the clipboard is currently unavailable. 

For example, on some platforms, the system clipboard is 
unavailable while it is accessed by another application.

Parameters:
  contents - the transferable object representing the clipboard content
  owner - the object which owns the clipboard content
Throws:
  IllegalStateException - if the clipboard is currently unavailable

...
---------- end-of-excerpt ---------------

Problem description
===================
Clipboard.setContent puts previous-owner notification in queue.
And as a result old owner can receive notification in some time after 
the setContents method returns.

That has been moved in with CCC 4259272 implementation.

And that contradicts with current specification. 

Asynchronous behavior should be specified explicitly.
See java.awt.Toolkit.prepareImage for example.

    
Minimized test:
===============
------- T.java -------
import java.awt.datatransfer.*;

public class T implements Transferable, ClipboardOwner {

    // Transferable implementation

    public Object getTransferData(DataFlavor flavor) {
        return null;
    }
    public DataFlavor[] getTransferDataFlavors() {
        return null;
    }
    public boolean isDataFlavorSupported(DataFlavor flavor) {
        return false;
    }

    // ClipboardOwner implementation

    public boolean lostOwnershipCaught = false;

    public void lostOwnership(Clipboard cb, Transferable t) {
        lostOwnershipCaught = true;
    }

    // main

    public static void main(String args[]) {

        T transferable = new T();
        T transferable2 = new T();

        T cbOwner = new T();
        T cbOwner2 = new T();

        Clipboard cb = new Clipboard("Test");

        cb.setContents(transferable,cbOwner);
        cb.setContents(transferable2,cbOwner2);

        /* COMMENTS TO REMOVE
        try {
           Thread.sleep(3000);
        } catch (InterruptedException e) {
            System.out.println(e);
            System.exit(0);
        }
        */

        if (cbOwner.lostOwnershipCaught) {
            System.out.println("OK.");
        } else {
            System.out.println("setContents() does not invoke lostOwnership.");
        }
    }
}

------- end-of-T.java -------

Minimized test output (with commented Thread.sleep piece of code):
======================
] ~/tmp
] java T
setContents() does not invoke lostOwnership.
Output with uncommented Thread.sleep piece of code:

Minimized test output (with un-commented Thread.sleep piece of code):
======================
] ~/tmp
] java T
OK.

JCK test source location:
==========================
/java/re/jck/1.5/promoted/latest/JCK-runtime-15/tests

Test output (excerpt):
======================
...
Clipboard0006: Failed. setContents() does not invoke lostOwnership.
...


======================================================================

                                    

Comments
EVALUATION



Name: agR10216			Date: 06/27/2003


Prior to the fix for 4259272 (Support Notifications of Clipboard
Contents Changes) ClipboardOwner.lostOwnership() was called
directly in the Clipboard.setContents(), but with the fix for
4259272 a request for lostOwnership() invocation is posted to the
event dispatch thread.

Because the current asynchronous notification may seem
unconformable to the specification, the fact that lostOwnership()
may not be called synchronously should be documented.

###@###.###  2003-06-27
======================================================================

Name: agR10216			Date: 07/15/2003


The following CCC request was approved:

 4884956: REGRESSION:datatransfer.Clipboard.setContent deals with the queue now
 Release: Tiger
 Type: bug-fix

 Problem
 
 Prior to the fix 4259272 java.awt.datatransfer.ClipboardOwner's
 lostOwnership() was called directly from
 java.awt.datatransfer.Clipboard.setContents(). With the fix
 4259272 a request for invocation of lostOwnership() is posted to the
 event dispatch thread. This change was necessary to properly fix
 4259272, the change was described in the bug report and the CCC
 request 4259272 was approved.
 
 The spec of Clipboard.setContents() says:
 "If there is an existing owner registered, that owner is notified
 that it no longer holds ownership of the clipboard contents."
 
 There is no anything about whether that notification is
 synchronous or asynchronous, i.e. lostOwnership() is called
 directly from this method or not. Besides, it's typical of AWT to
 notify listeners asynchronously. So no one should have relied on
 the synchronous behavior. But it's worthwhile to clarify this to
 have the failed JCK test properly updated.
 
 Requestors
 Java Drag and Drop team
 
 
 Solution
 
 Clarify the current behavoir with respect to notifying
 ClipboardOwner. Conjointly it's also worthwhile to clarify that
 FlavorListeners may not be notified synchronously. The fix
 4259272 added the possibility of notification of FlavorListeners
 and that notification is asynchronous.
 
 
 Interface summary
 
 exported  external  method  java.awt.Clipboard.setContents
 
 
 Specification
 
 java.awt.datatransfer.Clipboard:
 
       /**
        * Sets the current contents of the clipboard to the specified
        * transferable object and registers the specified clipboard owner
 !      * as the owner of the new contents.
 !      * <p>
 !      * If there is an existing owner different from the argument
 !      * <code>owner</code>, that owner is notified that it no longer
 !      * holds ownership of the clipboard contents via an invocation
 !      * of <code>ClipboardOwner.lostOwnership()</code> on that owner.
 !      * An implementation of <code>setContents()</code> is free not
 !      * to invoke <code>lostOwnership()</code> directly from this method.
 !      * For example, <code>lostOwnership()</code> may be invoked later on
 !      * a different thread. The same applies to <code>FlavorListener</code>s
 !      * registered on this clipboard.
 !      * <p>
 !      * The method throws <code>IllegalStateException</code> if the clipboard
 !      * is currently unavailable. For example, on some platforms, the system
 !      * clipboard is unavailable while it is accessed by another application.
        *
        * @param contents the transferable object representing the
        *                 clipboard content
        * @param owner the object which owns the clipboard content
        * @throws IllegalStateException if the clipboard is currently unavailable
        * @see java.awt.Toolkit#getSystemClipboard
        */
       public synchronized void setContents(Transferable contents, ClipboardOwner owner)


###@###.###  2003-07-15


======================================================================
                                     
2003-07-15
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger
tiger-b15

VERIFIED IN:
tiger-b40


                                     
2004-08-24



Hardware and Software, Engineered to Work Together