GHads mind

developers thoughts & finds

Java 7 – Small language changes

with 2 comments

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


Written by ghads

March 3, 2009 at 12:23 pm

Posted in Java development

Tagged with , ,

2 Responses

Subscribe to comments with RSS.

  1. 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).

    Neal Gafter

    March 3, 2009 at 4:11 pm

    • 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


      March 5, 2009 at 1:26 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: