The proposal extends the Java programming language in four specific ways:Pure Object Orientation
- A syntax for defining enumerated types. This syntax provides linguistic support for the Typesafe Enumeration pattern.
- An automatic conversion from primitive types to their corresponding reference type wrappers. This conversion facilitates the integration of generics into the language, and reduces inessential clutter.
- Enhanced for loops allow convenient iteration over collections, without the need for an explicitly defined iterator. This reduces the need for boilerplate iteration code and the corresponding opportunities for errors.
- Static import. A mechanism to allow the use of unqualified constants.
Ultimately, some of us might wish to eliminate the primitive-vs-reference distinction entirely, and adopt the Smalltalk philosophy that everything is an object.JSR 201 Proposed Final Draft
This view is not without difficulties, however, and somewhat controversial.
A key issue is identity. Many people would argue that primitives represent mathematical values, which are inherently distinct from references. In particular, one might argue that values have no identity whereas references inherently do.
Consider an example of what happens if this semantic principle is ignored. A program inserts an element into an identity hash table, using the integer 3 as a key. Later, an attempt is made to look up a value in the table using the integer 3 as a key. The lookup fails. This is initially surprising. The problem is that two distinct wrapper objects of type Integer, with distinct identities, were generated and used as keys. Current languages that support autoboxing suffer from such problems, as well as performance bugs that stem from excessive allocation of wrapper objects.
One way around this issue is to take the view that mathematical values do have identity, but that this identity is unique. For instance, if one uses an object to represent the integer 3, than this should be the only object representing 3. Put another way, the object representing 3 should be indistinguishable from any other object representing 3.
In general, a variety of implementation techniques could be used to obtain the desired behavior. The most naive of these is to simply cache objects representing values, and ensure that only one such object exists for a given value at a given time. This approach has performance problems, both in terms of footprint and speed. More sophisticated techniques, utilizing VM support, can bring down the cost to a level that would be negligible for most applications. Nevertheless, in some situations the cost would be meaningful.
The design of subtype hierachies for numeric types is a delicate and subtle exercise. Mainstream languages balance pragmatic considerations, such as how to efficiently utilize the primitive datatypes supported by the underlying hardware, with semantic considerations.
Consider the common practice of treating integral types as subtypes of floating point types. Since an n-bit floating point representation cannot accurately represent all n-bit integers, no true subset relation exists between these types. This problem becomes more acute if primitive types are indistinguishable from reference types.
Another difficult issue is the handling of large arrays of primitive values. If one truly eliminates the distinction between primitives and references, it becomes difficult to decide on the desired representation of an array of, say, integers. Should these be stored as an array of references, or as an array of primitive data. Each representation has its advantages depending on program behavior, and the performance differential can be massive.
We believe these issues deserve and require further study and research by the programming languages community.
JSR 201: Extending the Java Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import Details Page