Milling Project Coin

[Stephan van Hulst]

The small language changes included in Project Coin / JSR 334 as part of JDK 7 / Java SE 7 have been easy to use and have worked well in practice. However, a few amendments could address the rough edges of those changes. In addition, using underscore ("_") as an identifier, which generates a warning as of Java SE 8, should be turned into an error in Java SE 9. It is also proposed that interfaces be allowed to have private methods.

http://openjdk.java.net/jeps/213

So, in Java 9, these features might be added to improve on Project Coin:

Allow @SafeVarargs on private instance methods.

Allow effectively-final variables to be used as resources in the try-with-resources statement.

Allow diamond with anonymous classes if the argument type of the inferred type is denotable.

Disallow _ as a one-character identifier.

Allow interface methods to be private.

A few comments:

@SafeVarargs should only be allowed on methods that can not be overridden, because the annotation isn't inherited, but clients still expect a call to such a method to be safe. The new language feature allows @SafeVarargs on private instance methods, because those can't be overridden. I think it's a pity that @SafeVarargs can't be used on non-final non-private instance methods of a final class, because those methods can't be overridden either.

You would now be able to do the following with try-with-resources and anonymous generic classes:

final BufferedReader reader = Files.newBufferedReader(path);

try (reader) {
  //
}

Cage<Lion> lionCage = new Cage<>() {
  // implement anonymous class
};

Does anybody know what scenarios prohibited the use of the diamond operator in general for anonymous classes?

The underscore character was already disallowed as an identifier for lambda parameters. I assume this was because in some functional languages, the underscore character is used to indicate that you don't care about this parameter. The plan for Java 9 is to make a single underscore character a reserved keyword. I don't know yet for what purpose they might use it.

Since interfaces can have default implementations for public methods, it makes sense that you might want to break these methods up in smaller pieces. To avoid cluttering your API with helper methods, it's useful to allow private methods in interfaces. I don't know yet if interface methods are going to stay public by default.

[Rob Spoor]

Stephan van Hulst wrote:I don't know yet if interface methods are going to stay public by default.[/list]

Well, they should, otherwise a lot of code will break. CheckStyle and/or Eclipse won't even let me add the public keyword in interface methods or fields, stating it's redundant. As a result, none of my interfaces have explicitly public methods or fields. If those methods would be package-private all of a sudden that would mean a lot of broken code.

[Stephan van Hulst]

I'm assuming public would remain the default because that would make most sense, but wouldn't it be an option to make private the default?

I know binary compatibility is a big thing, you don't want compiled (and distributed) programs to suddenly stop working. I'm not sure if Oracle has the same policy regarding source compatibility. For instance, the underscore character is going to become a keyword, which might make existing source invalid under Java 9.

[Jesper de Jong]

Stephan van Hulst wrote:I'm not sure if Oracle has the same policy regarding source compatibility.

As far as I know they do, they (and Sun before them) has always been extremely careful with keeping things backward compatible, not only with regard to binary but also source compatibility. That's why, for example, they try to avoid introducing new keywords as much as possible and re-use existing keywords instead (for example '@interface' for annotations instead of having an 'annotation' keyword, which might break people's code if they used 'annotation' as a class or variable name).

The fact that _ as an identifier is going to be made illegal deliberately breaks source compatibility, but I doubt that this will be a big real-world problem, practically nobody uses variables named only _.

[Campbell Ritchie]

Anybody who does use _ alone deserves to have their code break.

[Mike Simmons]

Stephan van Hulst wrote:

You would now be able to do the following with try-with-resources and anonymous generic classes:

final BufferedReader reader = Files.newBufferedReader(path);

try (reader) {
  //
}

You can omit the "final" as well in this example. Effectively final is good enough.

I'm thinking that, in the future, they could also allow local and anonymous classes to access effectively final variables, just like lambdas can. It's a much nicer solution than having to introduce a new variable just to make it final. However, I suspect they may not care much about local and anonymous classes anymore, preferring lambdas for most situations that call for them.

Stephan van Hulst wrote:

The underscore character was already disallowed as an identifier for lambda parameters. I assume this was because in some functional languages, the underscore character is used to indicate that you don't care about this parameter. The plan for Java 9 is to make a single underscore character a reserved keyword. I don't know yet for what purpose they might use it.

That's my take as well - they just want to be able to make clearer error messages if someone does a copy-paste from Scala code (for example) and neglects to change the underscore. And since they're breaking backwards compatibility, they did it in two phases: Java 8 gives a warning, and Java 9+ will error. They could issue an error in a lambda in Java 8 because that's a new language construct; no chance of it existing in legacy code.

I think that's their only purpose here. Although, I wouldn't mind if they eventually re-introduced _ as the default lambda parameter name, just like Scala. But even if someone at Oracle wants to do that, they need to stamp out any legacy use of _ first.

Stephan van Hulst wrote:

Since interfaces can have default implementations for public methods, it makes sense that you might want to break these methods up in smaller pieces. To avoid cluttering your API with helper methods, it's useful to allow private methods in interfaces. I don't know yet if interface methods are going to stay public by default.

I agree with everyone else here - they pretty much have to keep that behavior.