由於Java中的所有東西都是句柄，而且由於每個對象都是在內存堆中創建的——只有不再需要的時候，才會當作垃圾收集掉，所以對象的操作方式發生了變化，特別是在傳遞和返回對象的時候。舉個例子來說，在C和C++中，如果想在一個方法裡初始化一些存儲空間，可能需要請求用戶將那片存儲區域的地址傳遞進入方法。否則就必須考慮由誰負責清除那片區域。因此，這些方法的接口和對它們的理解就顯得要復雜一些。但在Java中，根本不必關心由誰負責清除，也不必關心在需要一個對象的時候它是否仍然存在。因為系統會為我們照料一切。我們的程序可在需要的時候創建一個對象。而且更進一步地，根本不必擔心那個對象的傳輸機制的細節：只需簡單地傳遞句柄即可。有些時候，這種簡化非常有價值，但另一些時候卻顯得有些多余。
可從兩個方面認識這一機制的缺點：
(1) 肯定要為額外的內存管理付出效率上的損失（盡管損失不大），而且對於運行所需的時間，總是存在一絲不確定的因素（因為在內存不夠時，垃圾收集器可能會被強制采取行動）。對大多數應用來說，優點顯得比缺點重要，而且部分對時間要求非常苛刻的段落可以用native方法寫成（參見附錄A）。
(2) 別名處理：有時會不慎獲得指向同一個對象的兩個句柄。只有在這兩個句柄都假定指向一個“明確”的對象時，才有可能產生問題。對這個問題，必須加以足夠的重視。而且應該盡可能地“克隆”一個對象，以防止另一個句柄被不希望的改動影響。除此以外，可考慮創建“不可變”對象，使它的操作能返回同種類型或不同種類型的一個新對象，從而提高程序的執行效率。但千萬不要改變原始對象，使對那個對象別名的其他任何方面都感覺不出變化。
有些人認為Java的克隆是一個笨拙的家伙，所以他們實現了自己的克隆方案（注釋⑤），永遠杜絕調用Object.clone()方法，從而消除了實現Cloneable和捕獲CloneNotSupportException違例的需要。這一做法是合理的，而且由於clone()在Java標准庫中很少得以支持，所以這顯然也是一種“安全”的方法。只要不調用Object.clone()，就不必實現Cloneable或者捕獲違例，所以那看起來也是能夠接受的。
⑤：Doug Lea特別重視這個問題，並把這個方法推薦給了我，他說只需為每個類都創建一個名為duplicate()的函數即可。
Java中一個有趣的關鍵字是byvalue（按值），它屬於那些“保留但未實現”的關鍵字之一。在理解了別名和克隆問題以後，大家可以想象byvalue最終有一天會在Java中用於實現一種自動化的本地副本。這樣做可以解決更多復雜的克隆問題，並使這種情況下的編寫的代碼變得更加簡單和健壯。
