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 optionFinish 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 brainerIs 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:
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.
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.
Python style multiline string literals.
"""Is
that
so
hard?"""
It would make outputting XML a lot easier at times.
--
Simon
i'm into Groovy at the moment, i think it has all the features you are requesting. You should give it a try...
@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.
`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'
Post a Comment