The Former Weblog of Peter Ahé

Posted by Stefan Schulz on January 18, 2007 at 03:10 AM PST #

HashMap<String,String> hmap = new(10, 0.75);
Map<String,String> map = new HashMap(10, 0.75);

Other point, about concerns about existing #new(...) methods. How could this be an issue ? 'new' is a keyword, and thus cannot appear as an identifier anywhere in the code. Thus 'new' methods would be purely synthetics, and no user code could ever refer to them without using the proposed syntax. The only problematic point, is that you couldn't let a user write custom ones, and purely rely on synthetic ones. If so, then why even need a generated method ? The compiler could simply macroexpand the call into a constructor call for free. Also if instantiating the lhs type, then no explicit type would be required.

HashMap<String,String> hmap = new(10, 0.75);
Map<String,String> map = HashMap.new(10, 0.75);

Posted by Philippe Mulet on January 18, 2007 at 04:48 AM PST #

MyClass.new({somearguments});

new MyClass<{inferredtypes}>({somearguments});

Posted by Stefan Schulz on January 18, 2007 at 05:29 AM PST #

Posted by Peter von der Ahé on January 18, 2007 at 06:33 AM PST #

As you've shown, we already have type inference on method calls, just not on constructor calls (why?). It's possible to write a generic method 'hashMap()' that returns the right kind of Map, used like so:

Map<String,Integer> aMap=hashMap();

Rather than a language change, this could be a simple API change to add hashMap(), hashSet(), etc., to the APIs. If ArrayList et al had been designed from the start to be instantiated via a static method, then I doubt we'd even be discussing this.

Ok, discounting my uninteresting solution, onto your idea:

If the compiler had to generate code to do this, then the language feature would be incompatible with existing bytecode, unless it could generate it at call-sites.

A problem with allowing programmers to write methods called 'new' is that they might not actually generate a 'new' object, whereas as far as I know, in Java 'new' always creates a new object.

Is there a reason why HashMap.new() could not use the existing constructor and apply type inference?

Further, is there a reason why 'new HashMap()' could not have type inference applied, then there's no new syntax?

Currently, assigning a raw type to a parameterised type is a compile warning. I don't see how allowing inference on this will adversely affect any existing code; other than removing the warning. Is there a test case that shows this problem?

The older idea, using 'final' to mean 'infer local variable type', has an interesting repercussion. The type could actually be an anonymous type, e.g.:

final o=new Object(){int a=5,b=6;}; o.a=6; o.b=5;

If that looks odd, note that this already works.

System.out.println(new Object(){int a=5;}.a);

If I had to choose between your proposal and the 'final' proposal, I'd go with yours for readability and security (I treat variables defined in anonymous classes as private, regardless of their actual visibility).

Another idea is, when you have a concrete type, simply HashMap<whatever> map=new(); without having to statically import 'new' from somewhere. Getting closer to C++'s stack-allocation syntax there..

Posted by Ricky Clarkson on January 18, 2007 at 07:45 AM PST #

HashMap<String, List<Integer>> map = new({parameters});

HashMap<String, List<Integer>> map = new HashMap<String, List<Integer>>({parameters});

Posted by Stefan Schulz on January 18, 2007 at 08:26 AM PST #

Posted by Ricky Clarkson on January 18, 2007 at 08:53 AM PST #

I will apologize in advance for putting 4 things into one post, but I wanted to make 4 separate points! If you get bored reading such a long post :) stick to item 1 - its the most important!

1. You could add new keywords without pain. If you added the keyword source that accepted the Java version number. The source declaration would go before the package declaration. No code broken because no statement could go before package previously. Then if a package or import statement included something that was a keyword in the language version, e.g. source 7, then this keyword could be name mangled. So for example in the proposal C3S the keyword declare is proposed, as in declare map = HashMap.new( collection ), but if the name declare was included from elsewhere it could be mangled to _declare_ say. Note this suggestion will work well now that other languages are on the JVM. These languages don't have the same keywords as Java and might well have a method called final, say, in one of their libraries.

2. Removing the type declaration in a local/field declaration from the left hand side of = has more use cases than removing it from the right. There are a lot of examples of a method returning a value that you assign to a local/field. EG final x = someMethod( ... ) as opposed to final SomeType = someMethod( ... ).

3. None of the ideas you are presenting for Java 7 are that new, you will find very similar proposals from many people on the web, some going back years, e.g. from myself: RFE 6389769, SSCO, and C3S.

4. The later of the proposal referenced above, C3S, includes an alternative treatment for new defining a constructor instead of defining a static factory but retaining the type inference that the static factory has. This addresses the issue raised by others in this forum of why generate a static factory - just call the constructor.

Just to re-iterate the most important point raised above, item 1, is a suggestion as to how new keywords can be added painlessly that is compatible with other languages.

Posted by Howard Lovatt on January 18, 2007 at 05:56 PM PST #

Following on from Brian Slesinsky post and his comment re. keywords. I started off trying to think of syntax without new keywords in RFE 6389769 and SSCO, but I kept hetting feedback that keywords are the essence of Java and hence version 3 of my proposal, C3S, I put in keywords and this has recieved largely positive comments.

Posted by Howard Lovatt on January 18, 2007 at 09:01 PM PST #

Looking at this proposal, I can't help but think it's a special case for something more general - being able to define 'static interfaces' which is to say being able to require a class implement certain static methods. Doing that would move Java towards SmallTalk and other languages where classes are extendable. Sketching it out would look something like this:

<code>
package java.lang; 
static interface Creatable<C> { 
  static C create(Object...); 
} 

class Foo implements Bar, static Creatable<Foo> { //how would you enforce creatable<Foo> though? 
  public static Foo create(Object...) { //required by interface 
    return new Foo(); 
  } 
} 

//now use it 
for(Creatable<?> c : listOfFactories) { 
  instances.add(c.create()); //what's the type of 'c' here? some kind of generated subclass of java.lang.Class? 
} 
</code>

Of course, what's above isn't very coherent. Introducing extendable classes into Java might well be impossible, but what you're proposing does make me think there's a more general feature hiding in there somewhere.

Posted by Andrew Thompson on January 20, 2007 at 08:33 AM PST #

import static java.util.HashMap.new;

For the majority of cases, we know which implementation will by required. Defaults are a smart move. If I say I want a new Maplt;K,V>, you know 95% it's a new java.util.HashMap<K, V> I want (even if some PuTTY author calls it a cowboy algorithm). new Listlt;E> will be a new ArrayListlt;E>. new Font will be a new Font (ignoring PL&amp;Fs). So why not just allow interfaces and classes to nominate a default implementation:

interface Map<K,V> default new HashMap<K,V> { ... }
...
        Map<MyKey, MyValue> map = new();

I still haven't worked out what the problem is with inferring types in the currently legal syntax: Map<MyKey, MyValue> map = new HashMap();

Posted by Tom Hawtin on January 21, 2007 at 01:36 PM PST #

one of the examples you've given already compiles in Java 5, albeit with "unchecked warning":

Map<String,List<Integer>> map = new HashMap();

Note, that you don't need any type inference to make it work, you just need some "smart rule" which tells that this assignment of freshly constructed raw type to a concrete instantiation of Map interface is actually _safe_, since pointer to this instance of raw type did not leak anywhere else and could not possibly become polluted with something else. So, unchecked warning should not have been emitted for this code in the first place. I admit, that this linear property of this particular constructor cannot be checked without additional changes in the language, however we could recruit some new annotation to do the trick.

Posted by Roman Elizarov on January 22, 2007 at 01:45 AM PST #

import java.util.Collections;
import java.util.List;

public abstract class NewClass<T> {
    
    public static final NewClass<List<String>> STATIC_INSTANCE
            = new NewClass<List<String>>(Collections.emptyList()) {
    };
    
    private NewClass(final T t) {}
}

Posted by Steven Coco on January 23, 2007 at 07:13 PM PST #

Posted by Stephen Colebourne on January 24, 2007 at 03:17 PM PST #

Hi Peter,

You write: "we need more static factories throughout the JDK". This is very true, but on the other hand, there are very serious problems with static factories in their current form. For example, if class A has a static factory called getInstance(), and we wish to mandate using that method, then the class's constructor must be private. Which means A can't be subclassed! Or, if the constructor isn't private (e.g., package-level access) and some other class B extends it, then --- if you forget to re-define getInstance() for B --- the expression B.getInstance() will return an instance of A!

Another problem is that static factory methods are not "transparent", in the sense that you cannot introduce a new such method and have every existing clients immediately use it. Let's say we have an old class S and we wish to make it a singleton (or manage an instance pool, or whatever). We can add a new factory method getInstance(), but existing clients are now broken, since they still use the old constructor...

The solution is to allow classes to control how instances are generated, by default; i.e., every call to new S() is always a factory call. By default, a factory is generated for each constructor; but developers can choose to specify their own factories (in which case no default factories are generated). The syntax I suggest is:

class S {
  public static S instance = null;

  public static new() {
    if (instance == null) s = this();
    return instance;
  }

  public S() { ... constructor code ... }
}

A few things to note: the keyword new is used as the name of factories. The keyword this is used for invoking the constructor from within the factory; constructors can only be invoked from within factories -- external clients never have direct access to constructors. However, existing code is not broken since the syntax used so far ("new S") now implies a factory invocation. We use "this" rather than "new S" to invoke the constructor in order to prevent a recursive call.

Factories are generated by default only for regular classes, but can be manually added to abstract classes or even to interfaces. Think of adding a factory method to an interface like List:

interface List {
  public static new(boolean synch, boolean randomAccess) { ... }
  ...
}

Which will return an instance of Vector, ArrayList, LinkedList or a synchronized LinkedList, depending on the arguments provided by the user. The user is now completely shielded from explicitly naming any specific implementation of List in his code. And if a future version of the JDK includes a new SuperDuperList class, any code using "new List(...)" with relevant parameters will immediately benefit from this new class.

Factories can be viewed as an overriding of the "new" operator. However this is different than "new" overriding in C++, since there, you only get to control memory allocation; you cannot, for example, return an existing instance (or an instance of a subclass, etc.). In fact, this mechanism cannot be easily introduced into C++, since in C++ objects can be stored on the stack -- but here, we cannot know in advance what specific type will be returned by the factory, so the exact memory requirement is not known in advance.

Additional details and discussion can be found in Better Construction with Factories.

Posted by Tal Cohen on March 02, 2007 at 05:04 AM PST #

If introducing a new keyword is really a problem (breaks existing code), how about using "*" instead of "var"? After all, "*" is the universal "wildcard" symbol. So we'll have:

* map = new HashMap<String,List<Integer>>();

or:

for (* e : someEnum)

Posted by Tal Cohen on March 16, 2007 at 09:44 AM PDT #