Java gotchas - Revision history

Thomas Herlea: Added navigation to facilitate sequential reading online

2010-09-09T16:43:51Z

Added navigation to facilitate sequential reading online

KirstenS: /* Equality */

2009-01-28T15:45:59Z

‎Equality

KirstenS: /* Equality */

2009-01-28T15:45:31Z

‎Equality

KirstenS: /* Conditions */

2009-01-13T19:30:05Z

‎Conditions

KirstenS: /* Boolean Assignment */

2009-01-13T19:29:17Z

‎Boolean Assignment

KirstenS: /* Garbage Collection */

2009-01-13T19:28:18Z

‎Garbage Collection

KirstenS: /* Incrementing values */

2009-01-13T19:27:24Z

‎Incrementing values

KirstenS: /* Immutable Objects / Wrapper Class Caching */

2009-01-13T19:26:43Z

‎Immutable Objects / Wrapper Class Caching

KirstenS: /* Equality */

2009-01-13T19:23:13Z

‎Equality

Rahimjina at 21:34, 26 August 2008

2008-08-26T21:34:01Z

@@ Line 1: / Line 1: @@
-[[OWASP Code Review Guide Table of Contents]]__TOC__
+{{LinkBar
 == Equality ==
@@ Line 205: / Line 210: @@
 So even though the second "else if" would equate to "true" it is never reached. This is because once an "else if" succeeds the remaining conditions will be not be processed.
 [[Category:OWASP Code Review Project]]

@@ Line 40: / Line 40: @@
   String data = new String("123");
   String moreData = new String("123");
   System.out.println(data==moreData);

@@ Line 30: / Line 30: @@
   String letters = "abc";
   String moreLetters = "abc";
   System.out.println(letters==moreLetters);

@@ Line 206: / Line 206: @@
   x is less then 9
-So even though the second else if would equate to "true" it is never reached. This is because once an "else if" succeeds the remaining conditions will be not be processed.
+So even though the second "else if" would equate to "true" it is never reached. This is because once an "else if" succeeds the remaining conditions will be not be processed.
 [[Category:OWASP Code Review Project]]

@@ Line 164: / Line 164: @@
 == Boolean Assignment ==
-Everyone appreciates the difference between "==" and "=" in Java. However, typos and mistakes are made, often the compiler will catch them. However, consider the following:
+Everyone appreciates the difference between "==" and "=" in Java. However, typos and mistakes are made, and often the compiler will catch them. However, consider the following:
   boolean theTruth = false;
@@ Line 176: / Line 176: @@
+  }
 The result of any assignment expression is the value of the variable following the assignment. Therefore, the above will always result in "theTruth is true". This only applies to booleans, so for example the following will not compile and would therefore be caught by the compiler:
   int i = 1;

@@ Line 155: / Line 155: @@
 == Garbage Collection ==
+Overriding "finalize()" will allow you to define you own code for what is potentially the same concept as a destructor. There are a couple of important points to remember:
 * "finalize()" will only ever by called once (at most) by the Garbage Collector.

@@ Line 133: / Line 133: @@
 As per Java Language Specification(JLS) the values discussed above are stored as immutable wrapper objects. This caching has been created because it is assumed these values / objects are used more frequently.
-== Incrementing values ==
+== Incrementing Values ==
 Be careful of the post-increment operator:
@@ Line 144: / Line 144: @@
-Remember that the assignment completes before the increment, hence post-increment. Using the pre-increment will update the value
+Remember that the assignment completes before the increment, hence post-increment. Using the pre-increment will update the value before the assignment. For example:
   int x = 5;

@@ Line 51: / Line 51: @@
 == Immutable Objects / Wrapper Class Caching ==
-Since Java 5, wrapper class caching was introduced.  The following is an examination of the cache created by an inner class, IntegerCache, located in the Integer cache. For example, the following code will create a cache:
+Since Java 5, wrapper class caching was introduced. The following is an examination of the cache created by an inner class, IntegerCache, located in the Integer cache. For example, the following code will create a cache:
   Integer myNumber = 10
@@ Line 57: / Line 57: @@
   Integer myNumber = Integer.valueOf(10);
-Integer objects are created in the range of -128 to 127 which are all stored in an Integer array.  This caching functionality can be seen by looking at the inner class, IntegerCache, which is found in Integer:
+Integer objects are created in the range of -128 to 127 which are all stored in an Integer array. This caching functionality can be seen by looking at the inner class, IntegerCache, which is found in Integer:
 <pre>
@@ Line 84: / Line 84: @@
 </pre>
 So when creating an object using Integer.valueOf or directly assigning a value to an Integer within the range of -128 to 127 the same object will be returned. Therefore, consider the following example:
   Integer i = 100;
@@ Line 96: / Line 96: @@
   i and p contain the same value.
 It is important to note that object i and p only equate to true because they are the same object, the comparison is not based on the value, it is based on object equality. If Integer i and p are outside the range of -128 or 127 the cache is not used, therefore new objects are created. When doing a comparison for value always use the “.equals” method. It is also important to note that instantiating an Integer does not create this caching. So consider the following example:
   Integer i = new Integer (100);
@@ Line 112: / Line 112: @@
 :If the value ''p'' being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let ''r1'' and ''r2'' be the results of any two boxing conversions of ''p''. It is always the case that ''r1'' == ''r2''.
 The other wrapper classes (Byte, Short, Long, Character) also contain this caching mechanism. The Byte, Short and Long all contain the same caching principle to the Integer object. The Character class caches from 0 to 127. The negative cache is not created for the Character wrapper as these values do not represent a corresponding character. There is no caching for the Float object.
 BigDecimal also uses caching but uses a different mechanism. While the other objects contain a inner class to deal with caching this is not true for BigDecimal, the caching is pre-defined in a static array and only covers 11 numbers, 0 to 10:
   // Cache of common small BigDecimal values.

@@ Line 2: / Line 2: @@
 == Equality ==
-Object equality is tested using the == operator, while value equality is tested using the .equals(Object) method.  For example:
+Object equality is tested using the == operator, while value equality is tested using the .equals(Object) method.
   String one = new String("abc");
   String two = new String("abc");
@@ Line 34: / Line 37: @@
   true
 This is due to the compiler and runtime efficiency. In the compiled class file only one set of data "abc" is stored, not two. In this situation only one object is created, therefore the equality is true between these object. However, consider this:
   String data = new String("123");
@@ Line 45: / Line 48: @@
   false
-Even though one set of data "123" is stored in the class this is still treated differently at runtime. An explicit instantiation is used to create the String objects. Therefore, in this case, two objects have been created, so the equality is false. It is important to note that "==" is always used for object equality and does not ever refer to the values in an object. Always use .equals when checking looking for a "meaningful" comparison.
+Even though one set of data "123" is stored in the class, this is still treated differently at runtime. An explicit instantiation is used to create the String objects. Therefore, in this case, two objects have been created, so the equality is false. It is important to note that "==" is always used for object equality and does not ever refer to the values in an object. Always use .equals when checking looking for a "meaningful" comparison.
 == Immutable Objects / Wrapper Class Caching ==

@@ Line 158: / Line 158: @@
 * "finalize()" will only ever by called once (at most) by the Garbage Collector.
-* It is never a guarantee that "finalize()" will be called i.e that an object will be garbage collected.
+* It is never a guarantee that "finalize()" will be called i.e. that an object will be garbage collected.
 * By overriding "finalize()" you can prevent an object from ever being deleted. For example, the object passes a reference of itself to another object.
 * Garbage collection behaviour differs between JVMs.