Java 7 – Small language changes

Posted March 3, 2009
Filed under: Java development | Tags: , , |

Hi everyone,
Apart from the great proposals made by Neal Gafter that can be found everywhere on the web, I have some too… But I don’t know how to make them “official” because of my lack of knowledge about deeper changes in the specs or compiler. Anyway, I’ll like to post them, maybe someone can give me a hint how to get them in…

@Home I’ve writen a small closures framework w/ double brace initialization, but I stumbled upon two issues that made me (almost) surrender:
- Java should allow access to non final variables from inside anonymous classes
- And I need to finish the construction of an object in its super constructor to prevent direct execution of a double braced anonymous class, as the instructions inside the double brace is been “copied” to the anonymous constructor

Something I come over just today:

Java should ease the usage of static final fields/constants when declared inside the class you call a method. Instead of doing like

TableWrapData tdGrabName = new TableWrapData(TableWrapData.FILL_GRAB);

it should be possible to write

TableWrapData tdGrabName = new TableWrapData(FILL_GRAB);

The same accounts for enumerations. As the method definition states the type, why do I need to write it again? E.g. having a class

class SomeClass { public SomeClass(SomeEnum enum) {} }

instead of

new SomeClass(SomeEnum.Value);

I want to do

new SomeClass(Value);

of course with full IDE support ;-)

Another one is to allow Interfaces for Annotation fields. That would ease the use of Enums that implement this interface, thus making customizable/extendable enums possible.

If you have questions or suggestions, feel free to post some comments, I’ll get back to you…

Greetz, GHad

2 comments so far

  1. Neal Gafter on March 3, 2009

    The reason arguments aren’t looked up differently depending on the type of the parameter is that one needs the types of the parameters to be decided in order to do overload resolution (i.e. in order to figure out which constructor or method will be called).

    Reply
    • ghads on March 5, 2009

      Yes and no. I didn’t thought about overloading when I posted this “proposal”, so you’re basicly right. But the IDE could figure out all possibilities and AutoCompletion could show up all possible values like they were staticly imported on top of the popup list. Think of a virtual static import just for choosing the parameters value. Finaly when the developer choosed the one he/she wants, a static import for this value could be added to the import section of the class. So this is more suited to fit into a plugin than for a language change after thinking about an usable solution. Thanks for your comment and keep up your good work for Java. Greetz, GHad

      Reply

Leave a reply