Wednesday, July 9, 2008

Java 7 "quick wins" some ideas

I while back I was listening to Danny Coward's Java 7.0 interview on Java Posse. He made a comment about the fact that the typical new language features they were looking for are small language changes which don't impact the language too much.

The example he used was a the "foreach" loop which was a relatively small change but had a huge impact with developers, since it actually did make life a little easier as a Java developer.

So I decided to compile a list of some - hopefully - small ideas to reduce genuine sticking points I encounter daily doing meat and potatoes Java programmer.

Now firstly the disclaimer: I'm no language designer nor do I claim originality for these ideas. They are simply ideas that will make my life easier in my Job, they could introduce a whole set of complexities I couldn't even fathom, but anyway here goes...

  • Remove the final requirement for outer scoped variables which are accessed inside anonymous inner classes. This would allow me to do most of the things I want closures for.


  • How about a shorthand notation for getters and setters ala Ruby style, for example you would be able to declare something along the lines of:

    int myProperty {read;write}

    The compiler could simply insert appropriate get and set methods using standard JavaBeans naming conventions. Now generating these haven't been an issue since even the early Java IDEs, but the getter and setter code can still add several hundred lines of clutter to a class and 99% of the time they don't add any real value. If you need to do something specific in the method you can still manually define the getter or setter. Ideally of course, this might be a better option


  • Finish Autoboxing, I want to be able to do 1.toString().


  • Shorthand notation for creating maps and lists, something along the lines of...

    List myList = {"1","2","3"};

    and

    Map = {"key1"="value1","key2"="value2"};


  • While we are at it, what about some basic fixed operator overloading for collections, this has already been suggested and IMHO is a no brainer


  • Is there absolutely nothing that can be done about anonymous inner class syntax, especially since about 80% of the time my anonymous inner class comprises of precisely one method, couldn't we somehow inline single method classes maybe something along the lines of...

    myComponent.addListener(new ActionListener.actionPerformed(ActionEvent e)() {
    ...do stuff here
    });


    Although admittedly this just a manifestation of my desire for closures :-(.


  • Make one of the "buzz" languages a standard part of JSE. By buzz I mean something like JRuby or Groovy. This would make it easier to embrace these languages in a corporate and give some flexibility to platform. A good option might be Groovy since it's the most "Java-ish" language and it is also the only other language which is a Java standard. This has the advantage of requiring no core language changes and could showcase the new invokedynamic bytecode.
  • 6 comments:

    Casper Bang said...

    I have a loooong list as well, but seeing as Sun is busy with the rubber duck that is JavaFX and closures are stealing all the limelight, I will just point out one realistic little humble corner I would like fixed.

    Allow a catch block, even if no exception is thrown. One of the huge annoyances of checked exceptions is that if you comment out a call to something which throws a checked exception, you are also required to comment out each and every catch block. This is ridiculous, it should merely be an unreachable code warning.

    Howard Lovatt said...

    I think if there were short syntax for inner classes and the ability to write to variables, marked @Shared (latest BGGA spec.) or public (CICE), then there would be little point in closures.

    Simon said...

    Python style multiline string literals.

    """Is
    that
    so
    hard?"""

    It would make outputting XML a lot easier at times.

    --
    Simon

    seimour said...

    i'm into Groovy at the moment, i think it has all the features you are requesting. You should give it a try...

    aberrant said...

    @Simon

    `No actually
    it's not
    hard at all`

    In fact I hacked the compiler to allow for multi-line strings. My only difference is that I used the ` symbol. In the end it was less code to allow for multi-line strings then for single line strings. I can't believe that this hasn't been implemented in the JDK.

    Talden said...

    `I wonder which
    line.separator was used?
    runtime I hope.`

    String s = 'of course you
    lose nice indentation
    using these multi-line strings'

    String s =
    'but I suppose
    you can format
    it this way'