JSR 201: Extending the Java Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import now has a Proposed Final Draft (PFD). It was interesting to read about the rationale behind auto-boxing, and the expert group's thoughts on "Pure Object Orientation".

The proposal extends the Java programming language in four specific ways:

1. A syntax for defining enumerated types. This syntax provides linguistic support for the Typesafe Enumeration pattern.
2. 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.
3. 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.
4. Static import. A mechanism to allow the use of unqualified constants.

Pure Object Orientation

Ultimately, some of us might wish to eliminate the primitive-vs-reference distinction entirely, and adopt the Smalltalk philosophy that everything is an object.

This view is not without difficulties, however, and somewhat controversial.

Identity

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.

Subtyping

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.

Arrays

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.

Summary

We believe these issues deserve and require further study and research by the programming languages community.

JSR 201 Proposed Final Draft

JSR 201: Extending the Java Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import Details Page

Static imports are a terrible idea.

Static imports are a terrible idea.

I'm inclined to agree. I actually like the fact that statics are easily identifiable by the mandatory class prefix - I think it aids readability.

At least it's optional , so I guess if you don't like it, then don't use it.

Static imports don't seem any worse than other imports. What I find difficult when reading code is when imports are done like:

import java.lang.management.*;

Because now, if I'm not familiar with all the classes in that package, the code will be filled with references to classes and I won't be able to see where they came from. Just like a static import of some static methods - one will see it and think it comes from the same class, but you won't see it.

But, if all imports are explicit, then there is a simple place to look to see where the method comes from. If you follow that guideline, I think static imports can improve readibility simply by removing a lot of text from the code.

Static imports don't seem any worse than other imports. What I find difficult when reading code is when imports are done like:import java.lang.management.*;Because now, if I'm not familiar with all the classes in that package, the code will be filled with references to classes and I won't be able to see where they came from. Just like a static import of some static methods - one will see it and think it comes from the same class, but you won't see it.But, if all imports are explicit, then there is a simple place to look to see where the method comes from. If you follow that guideline, I think static imports can improve readibility simply by removing a lot of text from the code.

I don't agree. I prefer * imports for readability. The package is usually enough for me to find a class and I don't like seeing a huge list of 20-30 imports.

I personally don't care for static imports however.

Static imports are a terrible idea.

I'm inclined to agree. I actually like the fact that statics are easily identifiable by the mandatory class prefix - I think it aids readability.At least it's optional , so I guess if you don't like it, then don't use it.

If used sanely static imports could unclutter code, allowing you to extract constants to an external class and use them in a package without the prefix "penalty".

I could see a lot of bad code where a developer decides to static import everything under the sun - just in case they need it. Would this be the "Overpacking for vacation" anti-pattern?

Since it doesn't really buy you anything practical and adds complexity to understanding Java sources I'd have to say it wasn't the greatest idea. It was probably added because it was an easy thing to implement in the compiler.

Static imports are a terrible idea.

I'm inclined to agree. I actually like the fact that statics are easily identifiable by the mandatory class prefix

If it was so! If a class has static methods they can be accessed via…instance variable!
But to get really confusing type of called method is defined by declared type of variable, and not real type of the variable. Try to compile and run the following:
public class TestT{

  static class T1{
    static void t1Static(){
       System.out.println( "TestT$T1.t1Static" );
    }
  }

  static class T2 extends T1{
    static void t1Static(){
       System.out.println( "TestT$T2.t1Static" );
    }
  }

  public static void main( String[] args ){
    T1 t2 = new T2();
    t2.t1Static();
  }

}

the output is: TestT$T1.t1Static

Basically I agree, but this is one issue where a good IDE really helps out; CRTL-LMB in Eclipse.

There are times when one needs to read someone else's code, say off the internet, without setting up the source as a project in an IDE. I guess those are some of the times when 'import com.foo.*' really causes reading difficulty.

import * or static import will not create reading difficulty, as long as the symbol names are self explanary. I don't think it is really critical to know which package or which class the symbol is located when you browse a piece of code. if they are badly named, you are screwed anyway. it's not the fault of 'import'.

import * or static import will not create reading difficulty, as long as the symbol names are self explanary. I don't think it is really critical to know which package or which class the symbol is located when you browse a piece of code. if they are badly named, you are screwed anyway. it's not the fault of 'import'.

I agree. May be it is time to say: hey, it is just good old C++ namespaces and “import” actually equal to “use namespace”

I am kind of disappointed that in the time spent going to the final draft, the expert committee did not do more "further study and research" that could have made pre OO Java a reality. While the experience of generics shows to me that it's very easy to have huge differences of opinion and it is necessary for some steward to take decisions in the face of differing opinions, the most difference of opinion that I have seen with the JSR 201 features have been of the "static imports are evil" variety. Only now are we having a peek at what the expert committe considered in giving us autoboxing the way it is.