So, some interesting items have shown up in the Java 7 specs. Equally as interesting to me is that they have more ideas they intend to implement than they have manpower; for some reason, I mentally assumed that the Java language was mature enough that the feature additions/maintenance would match the available manpower by now. Wrong on my part, I suppose.
Anyways, in the article I'm pointing at, they're announcing:
- Switch statements can now be based off of Strings, not just char types.
- Automatic Resource Management - try/catch blocks can now automatically close streams quietly on exit, so you don't need two nested try/catch blocks anymore. I'm wondering how much different than Apache IOUtils.closeQuietly() this will be.
- Generics get a shortcut for creation: List
list = new List<>(); you don't have to type String the second time. - Binary literals (0b01010110), underscores in Strings (ala Ruby, int ONE_MILLION = 1_000_000)
- Lists may be created similar to arrays (List
list = {"One","Two","Three"}) - Binary literals (0b01010110), underscores in Strings (ala Ruby, int ONE_MILLION = 1_000_000)
And the two bigger chunks:
- Support for dynamically typed languages in the JVM (JSR 292). Dynamic typed languages are things like JavaScript; you don't have to declare a variable's type, it figures it out for you. This update sounds like "optimize the JVM so that JavaScript can be more easily made into a Java bytecode."
- Closures. Basically, a closure is a method that can be passed as a parameter to another method. Which is a huge change in the way code is written today in Java
Going on about closures, if you have a class with all static methods that implements an interface, and is only referred to one method at a time, there's circumstances where it might be much cleaner just to pass the method. Being more specific, SortedSet is implemented by TreeSet. TreeSet has a constructor that takes an initialized Comparator, which implements compare(a,b) and equals(a,b). compare(a,b) returns an int, and returns 0 if equals(a,b) would be true. With closures, in theory, it'd be much less verbose to just call TreeSet's constructor with a closure - send it compare(a,b) directly, without spending time implementing the comparator in another class or in an internal class.
Or not. I'm really interested to see how this plays out.
instead of having a class that implements an interface, you could simply pass the f
1 comment:
Having list literals is an improvement, but I hope that they're also planning on allowing you to use array literals for purposes other than initialization. That constraint has never been syntactically necessary and really hampers the usefulness, requiring defining useless variables just to initialize them with an array literal.
The JVM was originally designed for Java itself, but there are now several other languages which compile to JVM bytecode. However, the bytecode is a really strange assembly language in that method calls (with inheritance) and instance_of are assembly language instructions. Changes to the bytecode standard would be necessary to offer real support for dynamic typing. I'm pretty sure that adding closures (which I applaud) will at least require additions to the JVM standard as well.
Post a Comment