Channels ▼

Eric Bruno

Dr. Dobb's Bloggers

A Modern Primitive Discussion

February 27, 2012

Mixing primitives with objects gets more confusing when you consider how Java passes parameters in methods. In general, when passing objects to methods, they're always passed by value. (By the way, this tends to be a matter of much debate amongst even seasoned Java developers.) As a result, the code in the invoked method cannot change the parameters themselves. Don't believe me? Try this:

  public class ParamTest {
      public static void main(String[] args) {
          ParamTest obj = new ParamTest();

          String s = "Eric";
      public void addLastName(String p) {
          p = p + " Bruno";

The result is that even after the call to addLastName(), String s is still equal to "Eric". But you do get a reference to the actual object, so even though you cannot change the object itself, you can call methods on it to affect its state. For instance, if the object passed as a parameter has getter and setter methods, you can alter the object's state by calling the setter methods. A common example is passing a collection class object, such as a Vector, List, or Map. To summarize the confusion, many objects act as pass-by-reference, but primitives can never be altered in any way, as they don't accept method calls.

Although I won't go into great detail on these, other issues include the ugliness of putting and getting primitives into collection classes, and the inconsistency of Class objects in respect to Objects and primitives. For instance, the following generates an error on the last line:

  int val = 128;
  Vector vect = new Vector();
  val = (int)vect.elementAt(0); // Compiler error!!

But why no error on the call to add()? The inconsistency here is that while Vector accepts a primitive to add to the collection, it will only return an instance of an Object.

In regards to the Class object, the following will not compile:

  int i = 0;
  i.getClass(); // Error!

However, you can do this and get a Class object for a primitive type int (!):

  Class c = int.class;

and you can do this:

  class SomeClass {
      // ….
      int i = 0;
  SomeClass obj = new SomeClass();
  Class c = obj.getClass();
  Field f = c.getField(i);
  Class ci = f.getType(); 

But don't ever try this:

  Class c1 = Class.forName("java.lang.String"); // Good!
  Class c2 = Class.forName("int");  // Compiler error!

Needless to say, the confusion, ambiguity, and the inconsistencies associated with mixing primitive types and objects in Java has led many to dislike primitives altogether. Never mind all the thread-safety issues associated with primitives not being objects. What is a programmer to do?

JDK 9 (or 10) To the Rescue!

Some proposals to resolve this include either removing primitives altogether, or creating primitives that are really objects but still act like primitives in many ways. To do so, each variable in a Java program would need to have metadata associated with it, perhaps preceding it in memory. The JVM could then check this information to help remove the inconsistencies mentioned above.

Plans for JDK 9, and I've read JDK 10 in some cases, promise to repair the Java disjoint type system and eliminate primitives altogether. At JavaOne this past year, it was mentioned that the solution would be an all-object type system, but time will tell if Oracle sticks with that. You can read more about it in Simon Ritter's slides. Of course, there are issues like performance and backward compatibility that need to be maintained, so it will be interesting to see how the Java language and platform designers at Oracle plan to solve this one. Where do you stand on primitives in the Java language?


Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags


<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags


<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

