-
Enhancement
-
Resolution: Duplicate
-
P4
-
None
-
1.3.0
-
generic
-
generic
Name: krC82822 Date: 04/29/2001
The distinction which Java makes between primitive types and objects is cumbersome, inelegant, and completely unncessary. On a conceptual level, it is inconsistent with the "object oriented" design of the language. Allowing everything (including primitive types) to behave as objects would be much cleaner and more powerful. On a more practical level, it requires programmers to constantly convert back and forth between primitive types and the various wrapper classes. This results in more complex, harder to maintain code. The problems are especially severe when trying to store numbers in generic collection classes. The distinction between primitive types and objects also is confusing to many programmers when they are first learning Java, and makes the language more difficult to learn than it needs to be.
Allowing primitive types to be used as objects would solve these problems and turn Java into a true object oriented programming language. This change could be implemented entirely at the compiler level - whenever a primitive type appears where an object is required, the compiler would automatically use an appropriate wrapper class. For example, if a programmer wrote the following code:
Object obj[] = new Object [] {5, 3.8, 10.toString()};
double d = (double) obj[0];
the compiler would automatically translate it to:
Object obj[] = new Object [] {new Integer(5), new Double(3.8), Integer.toString(10)};
double d = ((Number) obj[0]).doubleValue();
This would require no changes at all to the virtual machine. It would have no affect on either efficiency of execution (the compiler would simply be generating the same code which, at present, the programmer would have to write by hand) or backwards compatibility. All existing source code would compile exactly as it always has. The only difference is that source code which previously was invalid and would not compile would become valid.
This behavior is analogous to the way javac currently deals with arrays and String literals - they "look" like primitive types, but they can also be used as objects. This behavior would simply be extended to include all numeric types as well.
(Review ID: 123440)
======================================================================
The distinction which Java makes between primitive types and objects is cumbersome, inelegant, and completely unncessary. On a conceptual level, it is inconsistent with the "object oriented" design of the language. Allowing everything (including primitive types) to behave as objects would be much cleaner and more powerful. On a more practical level, it requires programmers to constantly convert back and forth between primitive types and the various wrapper classes. This results in more complex, harder to maintain code. The problems are especially severe when trying to store numbers in generic collection classes. The distinction between primitive types and objects also is confusing to many programmers when they are first learning Java, and makes the language more difficult to learn than it needs to be.
Allowing primitive types to be used as objects would solve these problems and turn Java into a true object oriented programming language. This change could be implemented entirely at the compiler level - whenever a primitive type appears where an object is required, the compiler would automatically use an appropriate wrapper class. For example, if a programmer wrote the following code:
Object obj[] = new Object [] {5, 3.8, 10.toString()};
double d = (double) obj[0];
the compiler would automatically translate it to:
Object obj[] = new Object [] {new Integer(5), new Double(3.8), Integer.toString(10)};
double d = ((Number) obj[0]).doubleValue();
This would require no changes at all to the virtual machine. It would have no affect on either efficiency of execution (the compiler would simply be generating the same code which, at present, the programmer would have to write by hand) or backwards compatibility. All existing source code would compile exactly as it always has. The only difference is that source code which previously was invalid and would not compile would become valid.
This behavior is analogous to the way javac currently deals with arrays and String literals - they "look" like primitive types, but they can also be used as objects. This behavior would simply be extended to include all numeric types as well.
(Review ID: 123440)
======================================================================
- duplicates
-
JDK-4609038 Request auto boxing of primitives in Java
- Resolved