JDK-6352381 : Allow primitives to be used as 'first-class' Objects
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-11-18
  • Updated: 2010-05-08
  • Resolved: 2006-10-31
Related Reports
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
The Java language defines two basic categories of types, primitives and Objects. Because the language spec states that primitives are not Objects, nor can they be treated as such, developers are force to 'live in two worlds'.  The only way to bridge this gap is with the primitve wrapper classes.

The problem is that if you have a lot of primitive wrappers (10s of thousands) this not only requires extra memory and time, it can cause serious garbage collection slowdown when these Objects survive outside of the young generation.

JUSTIFICATION :
I see this as not really so much of an enhancement but more of a correction to a mistep in the original language design.  This change would preserve the benefits of primitive types while allowing for more natural code, faster development and more efficient applications.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Fortunaley autoboxing already addresses the syntax problem.  The main difference would be that in code such as the following:

Object o = 5;

instead of creating an Integer wrapper behind the scenes, o would actually be assigned a raw primitive.  The JVM would recognize that this value is a raw primitive.

  To do this, all the Object methods would be defined for the primitive types at the JVM level.  This would be a bit of syntactic sugar that would give the appearance that the primitive was a 'first-class' Object.  Class instances are already defined for the primitive types.  Generics would need a modification to allow primitives parametric types.
ACTUAL -
When a developer writes a line of code like:

Object o = 5;

What is really being written is:

Object o = new Integer(5);

whether the developer is realizes it or not.  This means that a lot of applications are creates many wrapper Objects.  This is less effiiecien in terms of space and time and sometimes large numbers of these Objects persist in memory and survive the young generation to cause serious garbage collection performance issues.

---------- BEGIN SOURCE ----------
There is no source as this is a language design change.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Autoboxing, Object wrappers, primitive collection libraries, hard-coding.

Comments
EVALUATION Furthermore, the JLS only requires that values [in the ranges Joe quoted] which undergo boxing conversion obey reference equality. This is worth watching out for. Integer a = 1000; Integer b = 1000; // No requirement by the JLS for a==b Integer c = 5; Integer d = 5; // JLS requires c==d Integer e = 5; // Value '5' undergoes boxing conversion Integer f = new Integer(5); // No boxing conversion // No requirement by the JLS for e==f
31-10-2006

EVALUATION Additionally, Object o = 5; is *not* equivalent to Object o = new Integer(5); The specification requires cached values be used for integers between -128 and 127 so there will only be one Integer object for the value 5, not millions; see http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7
31-10-2006

EVALUATION This is a major change to the semantics of the Java language and VM, and is not going to happen. Use the Flyweight pattern if you need many objects boxing primitive values.
31-10-2006