• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Milling Project Coin

 
Saloon Keeper
Posts: 15617
366
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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:


  • 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.
  •  
    Sheriff
    Posts: 22785
    131
    Eclipse IDE Spring VI Editor Chrome Java Windows
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Saloon Keeper
    Posts: 15617
    366
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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.
     
    Java Cowboy
    Posts: 16084
    88
    Android Scala IntelliJ IDE Spring Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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 _.
     
    Marshal
    Posts: 79409
    377
    • Likes 2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Anybody who does use _ alone deserves to have their code break.
     
    Master Rancher
    Posts: 4908
    74
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:

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

  • 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.
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic