Java 1.7 - What's new? Release date, code examples and performance
I have been reading quite a lot about Java 1.7. There are articles about what's new, some code examples, some benchmark to compare performance with previous version of Java and discussion on when it will be released. I have decided to regroup all I have discovered in this article so that I and maybe you, won't have to spend hours surfing the web to find all this information. Don't hesitate to leave a comment if I missed something.
What's new in Java 1.7?
First thing first. To determine what set of small language changes should be added to JDK 7, a project has been set up called Project Coin. The final five changes (bit more than 5) are described on the following blog entry of Joseph D. Darcy.
So what made it through is the following:
- Strings in switch
- Automatic Resource Management
- Improved Type Inference for Generic Instance Creation (diamond)
- Simplified Varargs Method Invocation
- An omnibus proposal for better integral literals
- Language support for Collections
- Language support for JSR 292
There is a list of other features available on the OpenJDK 7 features page.
These features are divided in different categories:
VM
- Compressed 64-bit object pointers
- Garbage-First GC (G1)
- JSR 292: VM support for non-Java languages (InvokeDynamic)
lang
- SR 294: Language and VM support for modular programming
- JSR 308: Annotations on Java types
- JSR TBD: Small language enhancements (the Project Coin I was talking about)
- JSR TBD: Project Lambda
core
- Modularization (Project Jigsaw)
- Upgrade class-loader architecture
- Method to close a URLClassLoader
- Unicode 5.1
- Concurrency and collections updates (jsr166y)
- JSR 203: More new I/O APIs for the Java platform (NIO.2)
- SCTP (Stream Control Transmission Protocol)
- SDP (Sockets Direct Protocol)
- Elliptic-curve cryptography (ECC)
client
- XRender pipeline for Java 2D
- Forward-port 6u10 deployment features
- Create new platform APIs for 6u10 graphics features
- Nimbus look-and-feel for Swing
- Swing JLayer component
web
- Update the XML stack
As you can see there is a lot of stuff. I personally tried the new Garbage Collector (G1) a few months back and was really impressed by the performance. Unfortunately the JVM was crashing every few hours so it couldn't be used for production. This GC is available in Java 1.6 as well but same thing, it crashes every so often.
I think that's it for the new features. Maybe it's a good idea to see some code examples now.
Code examples for new features in Java 1.7
Most of what is below come from the excellent article from Joe Wright on his blog about New language features in Java 7
Language support for collections
This is all about writing less code when you create a List, a Set or a Map. You don't have to instantiate the Object and then add the element to the Collection. You can now do it in 1 line.
String item = list[0];
Set<String> set = {"item"};
Map<String, Integer> map = {"key" : 1};
int value = map["key"];
Automatic Resource Management
Annoyed to have verbose code because of try / catch statement. You will love this one.
Indeed, this:
try {
return br.readLine();
} finally {
br.close();
}
Become this:
return br.readLine();
}
Improved Type Inference for Generic Instance Creation (diamond)
Same thing, today you specify the Generic when you declare the interface of your object and then you have to repeat yourself when you instantiate the object. You won't have to now as you can do:
Underscores in numeric literals
Not sure this one will be useful to lot of people. You can do:
Strings in switch
Nothing to explain here, the title says it all.
switch(availability) {
case "available":
//code
break;
case "unavailable":
//code
break;
case "merged":
//code
default:
//code
break;
}
Binary literals
You can create binary literals using the 0b prefix
That's it for the code examples. It would be great if someone can point me on more things. I am sure there are plenty of other cool stuff.
Performance of Java 1.7
I have picked up the tests I ran from an article from Taranfx posted here.
So the tests are the following (my code, not his but I followed the same ideas). I ran all of this on a Macbook Pro running ArchLinux (the one with an Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz. I think 2 years old). I have 2Gb of RAM. I set the Heap Size to 728m (-Xms728m -Xmx728m).
Test 1. Add 1 Million String values to a List (the String is a UUID generated using UUID.randomUUID()).
Test 2. HashMap
Test 3. Printing 1 million items of ArrayList
I am just comparing Java 1.6 (1.6.0_19) vs Java 1.7 (b87). I added Java 1.5 to this benchmark following a request in the comments but not Java 1.4 as it is from an other age to me.
So here is the result
| Java 1.5 | Java 1.6 | Java 1.7 | |
| Test 1 | 10,698 sec | 9,481 sec | 9,328 sec |
| Test 2 | 69,827 sec | 37,935 sec | 36,636 sec |
| Test 3 | 26,931 sec | 30,868 sec | 27,383 sec |
The difference of performance is clearly not as big as it is in the article of Taranfx. It appears that our implementation of his tests are probably quite different as well as my tests are taking a lot more time than his.
Release date of Java 1.7
In November 2009, it was planned to be in September 2010 as there would be 3 more milestones. Milestone 6 was completed with build 84. b85 was scheduled for the 4th of March 2010, first build of Milestone 7. b87 used in this article has been released the 25th of March 2010. So it looks like a release for September 2010 is more than likely. Though I have been reading an interesting subject on the stackoverflow forum here. You can check the blog of Alex Miller as well. He publishes links to all blog and news items referring to the progress of Java7
53 Comment(s)
<a href="http://javarevisited.blogspot.com/2011/09/fork-join-task-java7-tutorial.html">fork-join in java7</a>
<a href="http://javarevisited.blogspot.com/2011/09/fork-join-task-java7-tutorial.html">fork-join in java7</a>
try{
}catch(NoSuchMethodException | SecurityException e){
e.printStackTrace();
}
Over and all we do love JAVA in so many aspects.
It should rather be as concise as
String myString = null;
if ("Steve".equals(myString)) {
// do something
}
;)
int marks;
switch(marks)
{
case > 80: //do something
break;
case > 70: //do something
break;
case > 50: //do something
break;
default: //do something
break;
}
will there be those features? i can't wait to see such things.
they **ONLY** make sense, if you add some validation/checks.
these things compilers cannot do for you.
No checks in setters/getters -> do not even create them.
can u give me the exact release date of java 1.7
With closures the switch could easily be replaced with:
Map<String, Func<Integer>> map = {"a" : it -> { do something}, "b" : it -> { do something} };
Even if/else would be better than switching on a string. But hey performance improved.
If Java will have @property instead of getters() and setters(), I think it will neglect it's original purpose of object orientation.
indeed .net is more like a black box than Java, but what really outrages me is copying features from C# just for the sake of keeping up with Microsoft's hype, rather than address the real needs of the developers.
At least Microsoft learned some good things from Java's history when creating C#, but the Java crowd does not seem to learn anything from Microsoft's mistakes, like the Managed C++ debacle, that screwed up completely a perfectly good language just for the sake of 'enriching' it.
I have yet to hear a good opinion about Managed C++, and I fear the same would happen to the 'improved' Java some guys are peddling down out throats.
You sound exactly like the MSFT propaganda machine: bloated is better.
C# is just a fat bloated java lame atempt to impress the ignorants.
Useless features like delegates ( closures) and syntactical sugar would only slow the language adoption and focus resources outside of framework and library innovation.
Java should stay true to its original strenghts, not try to be a 'me to' copy of C# with no noticeable benefit.
If you need a recent example of taking a good language and making it unusable, look no further than C++ -> Managed C++ blunder.
I would not want the same 'enrich the language' fad to happen to java.
Young people are considering Java the new Cobol – a dying old-fashioned language that is no fun to work in. And they are right. Luckily the Java ecosystem is huge so it’s death will take a long time. But it will come soon enough if this stagnation does not stop.
It’s actually very, very sad. It is very possible to extend your language in new ways as C#’s history shows you. Its versions add possibilities that Java’s designers apparently do not understand- so they see no value. If you leave idiots to design your language you get one only an idiot will use.
Let’s hope Oracle’s takeover of Sun will out Java’s current stewards and bring in new blood- with brains and vision. Although I fear, knowing Oracle’s tracksheet, that this will prove not to be the case.
if("Steve".equals(myString)){
// do something
}
Also, nullifying objects is a good practice and eases the Garbage Collector job. So NULL has its uses.
A good developer always thinks in the worst case scenario, so, instead of complying about NULL forgiveness, shell out a couple of additional lines of codes for validation. For example, by using a short circuit AND, you could avoid errors:
String myString = null;
if(myString != null && myString.equals("Steve")){
// do something
}
Just like that, you get around one of your problems.
For example, in ...
String myString = null;
if (myString.equals("Steve")) {
// do something
}
The myString.equals throws a null pointer -- is it really necessary or helpful? If I really care about the null pointer then I should have the *option* of catching it by wrapping it in a try ... catch. But when the try ... catch isn't there, why can't Java just evaluate it as false?
Similarly ...
List<Strings> myStrings = null;
for (String s : myStrings) {
// do something
}
... I'd prefer this for statement to not throw a null pointer exception (unless I explicitly catch it).
bean.getProperty().getNestedProperty();
Just no need to write those methods anymore...
I'm impressed about the fact that you don't understand a bunch of methods, generated by an IDE, just for simple property read/write. Yeah, my IDE of choice (Eclipse) generates all of those, including default javadoc (which is useless in getters and setters BTW), but the question is WHY? Why have a JavaBean with 10 lines of property declarations and 100 lines of getters and setters? Furthermore, it should be an easy task for the compiler to generate those... don't the DRY concept tells you anything here? Don't repeat yourself VERSUS repeated getters and setters all over the place... hmmmm
Well, I hope you tell me the advantages of having all those getters and setters instead of a "smart" property handling by the compiler...
I'm scared now, I tought every single Java guy was against the 'getters' and 'setters' hell, but even those creep methods have its fans!
Just in time, I want to correct something in my examples:
First, 'getter' and 'setter' ARE... sorry about that, I'm not a native speaker.
Second, in the readOnly example, No 'setter' is created.
@Property // 'getter' and 'setter' is created at compile time
private String name;
@Property(readOnly = true) // No 'getter' is created
private Integer age;
@Property(getter = "provided") // a default 'String getNotes()' is provided, not generated
private String notes;
and so on...
We use JavaBeans heavily, and all those generated getters and setters make me sick... we should implement them only when needed, some encapsulated data handling.
try {
doWork(file);
} catch (final IOException | SQLException ex) {
logger.log(ex);
throw ex;
}
why not catch (Exception1, Exception2 e) ?
minor change but that would be more natural.
i dont know what to think about the string-switch, it makes stuff easier but it also promotes bad coding practices - i think enums are more safe, less likely to brake the code
maybe .. maybe not
http://mail.openjdk.java.net/pipermail/coin-dev/2010-February/002703.html
BufferedReader br = new BufferedReader(new FileReader(path));
try {
return br.readLine();
} finally {
try {
br.close();
} catch(IOException ioe){}
}
...
It's there
List<@NonNull Object>)
try {
doWork(file);
} catch (final IOException | SQLException ex) {
logger.log(ex);
throw ex;
}