J*

This page consists of small extensions to the Java language I'd really like, which could be part of Java 3. Most of these are just syntax sugar to make life easier. Just like C# borrowed many good ideas from Java, these syntax sugar additions to Java borrow some good ideas from C#

Though I've gotta say, all of these are fairly minor. Whats so powerful about the Java platform is backwards compatibility, the platform, JVMs and the sheer amount of reusable code and tools out there. So I don't think any of these changes are in any way important enough to warrant a whole new language - so these seem to fit the idea of a preprocessor sat on top of Java.

So all of these changes could exist in a new pre-processor called J* which could output regular Java code or bytecode directly without breaking any existing Java tools. Whats more, it'd be trivial to add support for J* to Ant and Maven so complete backwards compatibility is assured.

Generics

Since we're talking about a preprocessor that outputs bytecode thats backwards compatible with existing code, J* may as well include the current Generics compiler from JSR 14.

A constant for the current class instance

We have this but why not a thisClass? Its a PITA to have to cut and paste class names when they could easily be a compile time constant. e.g.

public class Foo {

    private Logger log = LogFactory.getLog( thisClass );

instead of

    private Logger log = LogFactory.getLog( Foo.class );

which can lead to cut-and-paste errors. This is a common issue with using static methods in a generic way.

This is a very trivial change.

Support for C# style properties

Writing getters and setters is a PITA. We should have some new syntax sugar for doing this in Java. Particularly with javadoc comments. Something like this would be nice

public class Foo {

    private String name;

    /**

     * This is the description of the property 'name'

     */

    public String Text {

        get {

            return name;

        }

        set {

            name = value;

        }

    }

I don't really mind about the foo.Name syntax of C# - I'm quite happy to call getters - though that could be another optional bit of syntax sugar.

Its mostly to implement them that can save time, particularly with auto-generated javadoc comments based on a single comment. Also common properties, where there is no special code, could be coded even more concisely as...

public class Foo {

    /**

     * This is the description of the property 'name'

     */

    public String Text {}

which could default the getter and setter code along with the javadoc comments.

Similar C# style syntax sugar for listeners

foreach statement

We have support for Collections and Iterators, so why not have a simple support for a foreach keyword

foreach (Customer c in foo.getCustomers()) {

    System.out.println("name: " + c.getName());

}

Which could equate to

for (Iterator iter = foo.getCustomers().iterator(); iter.hasNext(); ) {

    Customer c = (Customer) iter.next();

    System.out.println("name: " + c.getName());

}

using statement

I like this one. When working with multiple resources write code like this...

using (InputStream in = new FileInputStream("foo.xml")) {

   ...

    using (OutputStream out = new FileOutputStream("out.xml")) {

        ...

    }   

}

instead of the rather convoluted way of writing this with finally blocks, ensuring that things are only closed if the in and out variables are defined.

This syntax sugar should only be used if the variable supports a close() method like most IO and resource based classes, like streams, JDBC connections & statements etc.

Switch statement to support any Object

Right now switch only supports ints. That sucks. We should at least be able to switch over Strings at least. I don't see why we can't support any Object. The implementation could just use a lazily-constructed Hashtable under the covers.

switch (foo) {

    case "hello":

        return 1234;

    case new Date(12345):

        doSomething();

        break;

    case new Integer(545):

etc. 

References

Joe also gives some good examples of how useful the foreach and using clauses could be in Java as well as the case for blocks.

There is also a wealth of good ideas on this wiki site for Java Three

Update

If you found the above interesting, you might like to look at Groovy. Its a new language for the JVM which compiles straight to bytecode (either at build time or runtime), works really well with Java code and has all of the above features in it along with closures, static & dynamic typing and various other Ruby-isms.