Summary

Bruce Eckel's Thinking in Java Contents | Prev | Next

Because everything is a handle in Java, and because every object is created on the heap and garbage collected only when it is no longer used, the flavor of object manipulation changes, especially when passing and returning objects. For example, in C or C++, if you wanted to initialize some piece of storage in a method, you’d probably request that the user pass the address of that piece of storage into the method. Otherwise you’d have to worry about who was responsible for destroying that storage. Thus, the interface and understanding of such methods is more complicated. But in Java, you never have to worry about responsibility or whether an object will still exist when it is needed, since that is always taken care of for you. Your programs can create an object at the point that it is needed, and no sooner, and never worry about the mechanics of passing around responsibility for that object: you simply pass the handle. Sometimes the simplification that this provides is unnoticed, other times it is staggering.

The downside to all this underlying magic is twofold:

  1. You always take the efficiency hit for the extra memory management (although this can be quite small), and there’s always a slight amount of uncertainty about the time something can take to run (since the garbage collector can be forced into action whenever you get low on memory). For most applications, the benefits outweigh the drawbacks, and particularly time-critical sections can be written using native methods (see Appendix A).
  2. Aliasing: sometimes you can accidentally end up with two handles to the same object, which is a problem only if both handles are assumed to point to a distinct object. This is where you need to pay a little closer attention and, when necessary, clone( ) an object to prevent the other handle from being surprised by an unexpected change. Alternatively, you can support aliasing for efficiency by creating immutable objects whose operations can return a new object of the same type or some different type, but never change the original object so that anyone aliased to that object sees no change.
Some people say that cloning in Java is a botched design, and to heck with it, so they implement their own version of cloning [53] and never call the Object.clone( ) method, thus eliminating the need to implement Cloneable and catch the CloneNotSupportedException. This is certainly a reasonable approach and since clone( ) is supported so rarely within the standard Java library, it is apparently a safe one as well. But as long as you don’t call Object.clone( ) you don’t need to implement Cloneable or catch the exception, so that would seem acceptable as well.

It’s interesting to notice that one of the “reserved but not implemented” keywords in Java is byvalue. After seeing the issues of aliasing and cloning, you can imagine that byvalue might someday be used to implement an automatic local copy in Java. This could eliminate the more complex issues of cloning and make coding in these situations simpler and more robust.


[53] Doug Lea, who was helpful in resolving this issue, suggested this to me, saying that he simply creates a function called duplicate( ) for each class.



Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Complex hybrid environments can make it difficult to track interdependencies, increasing the risk of disrupting critical business services. In this white paper by EMA, you'll learn how application discovery and dependency mapping can help you: Meet granular targets for availability, cost, and time-to-revenue for cloud services. Accelerate mean time to repair (MTTR) while communicating better with stakeholders. Manage even the most complex hybrid environments more efficiently and effectively Understand the …

  • Rocket Mobile® for IBM i is an enterprise mobile application development and deployment platform for customers who rely on the IBM i system. Rocket Mobile for IBM i enables customers to leave proven applications in-place and rapidly repurpose them into new managed and secure mobile applications. Fast, easy creation of mobile, web, and hybrid mobile applications that deploy to any iOS, Android, or Windows mobile phone or tablet Built-in integration for seamless repurposing of existing IBM i applications …

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date