/Peter Haggar

About Peter Haggar

This author has not yet filled in any details.
So far Peter Haggar has created 7 blog entries.

Pass-by-value Semantics in Java Applications

2010-05-26T17:11:04+00:00 November 24th, 2003|Java|

A few months ago, developerWorks posted some excerpts from my book, Practical Java, published by Addison-Wesley. I will initially use this column on developerWorks to answer some questions asked by readers and to respond to various comments about the excerpts.

Use the Finally Keyword to Avoid Resource Leaks

2010-05-26T17:15:36+00:00 September 16th, 2003|Java|

The finally keyword is the best addition to the Java exception handling model over other language's models. The finally construct enables code to execute whether or not an exception occurred. Using finally is good to maintain the internal state of an object and to clean up non-memory resources. Without finally, your code is more convoluted. For example, the following is how you must write code to free non-memory resources without the benefit of finally:

Use Stack Variables Whenever Possible

2010-05-26T17:15:53+00:00 July 24th, 2003|Java|

When frequently accessing variables, you need to consider from where they are accessed. Is the variable static , on the stack, or an instance variable of a class? Where you store a variable has a significant impact on the performance of code that accesses it.

Use Synchronized or Volatile when Accessing Shared Variables

2010-05-26T17:17:35+00:00 March 9th, 2003|Java|

When variables are shared between threads, they must always be accessed properly in order to ensure that correct and valid values are manipulated. The JVM is guaranteed to treat reads and writes of data of 32 bits or less as atomic. This might lead some programmers to believe that access to shared variables does not need to be synchronized or the variables declared volatile.

Do Not Reassign the Object Reference of a Locked Object

2010-05-26T17:18:23+00:00 March 2nd, 2003|Java|

The synchronized keyword locks objects. Because the object is locked inside of synchronized code, what does that mean to the object and to changes you make to its object reference? Synchronizing on an object locks only the object. You must be careful, however, not to reassign an object reference of a locked object. What happens if you do?