In your list and map examples, should you specify the types, as in:

Map map = {”key” : 1};
int value = map["key"];

OK, let’s try this again:

Should it be:

Map<String, Integer> map = {”key” : 1};
int value = map["key"];

wow, that “declare more than one resource” might have been better with this sort of syntax:

try (
InputStream in, OutputStream out = new FileInputStream(src), new FileOutputStream(dest)
){
body
}

that way you could place the tuple inside a function that returned both in, and out.

not that tuple support exists

You show this for creating a set:

Set set = {”item”)

So you start with a curly-brace and close with a parenthesis?

or should it be parenthesis on both sides, as in:

Set set = (”item”)

Interesting stuff.

In the first example (second listing) is there a mistake?

Set set = {”item”)
should be
Set set = {”item”};

Thanks for the nice post, well done.

Best Regards,

Rick

try (BufferedReader br = new BufferedReader(new FileReader(path)) {
return br.readLine();
}

Leak is possible here, if error occurs in BufferedReader constructor (for example, OutOfMemoryError).

where is the clousers???

Hi Joe,

Thanks for your post. Very informative and well composed.

I’ve got a question… in the following:
try (BufferedReader br = new BufferedReader(new FileReader(path)) {
return br.readLine();
}

what is the scope of variable br?
Mainly i would like to know if add a finally to the try will it be visible?

cheers,
Rashmi

Good to know that Java is (slowly) catching up to C#

Hopefully switch on Strings, first switches on hashCode, and then differentiates from there.

Wow finally switch statements support strings. This has been a pet peeve of mine in Java for a while!

They way they did automatic resource management looks a little weird to me. They essentially added special syntax for a very small ‘corner’ of a normally (for better or worse) verbose language. In itself it looks good but looks iffy taken in the context of everything else in Java.

As for language support for collections I wonder if it turns out to be something similar to how they did arrays where you can to do:
f(new int[]{1,2,3});
or:
int[] x = {1,2,3};
f(x);
but not:
f({1,2,3});

I like the improved type inference and strings in switch though.

Why square brackets for list? (given sets and maps also use the curly brackets, which to my understanding, good old arrays also use?

@Joe Wright: hashcode then equals

an interesting issue, then, perhaps… Is the hashcode value calculated at compile time for the “case labels”? If so you might run into a javac/java mismatch for the impl of hashCode().

I guess there can be no jump table implementation then, it truely must be if/else/if/else even with hashcodes… bummer.

@Joe Wright

>>Most other languages use square brackets for list. You can’t create an Array like this:

>> return [1, 2];

you should be able to..(now)

These are without a doubt welcome, but I wonder if the closing of resources could have been made a little less verbose…

Joe:
Quick tip, I’m colorblind and the yellow (?) in the code is almost impossible to read. Try something darker.

The “Automatic Resource Management” syntax is horrible. It should be done more like C#:

using (OutputStream out = new FileInputStream(src)) {
// do stuff here
}

Much more readable, IMO.

Sorry, copy/paste FTW…

Correction:

using (OutputStream out = new FileOutputStream(src)) {
// do stuff here
}

Thanks for your post, a lot of this stuff is kind of available using Google Collections. Automatic Resource Management can be partially achieved using Project Lombok. But still, is good to see the language incorporating those features, so no need for external libs.

I have been using some of these features in C# for a long time… its good to see that Java language will also get these new enhancements.

Why reverse type inference ?

I like pythons with keyword much better

with exp as name {

//name is valid here

}

I don’t really like how the collection initialization also means the collections are immutable, because there’s nothing in the following code that makes me think they are (i.e. if I didn’t see the initialization line, or passed it to some other function).

I also don’t like how you have to do something explicit to get Closable behavior. This seems like a hack for putting RAII into Java because nothing gets called when an object goes out of scope. Why didn’t they just make it so Closable gets used when an object goes out of scope? Java already has a concept of scope.

Joe,
What’s the font that you’re using for your code snippets? It’s excellent.
Regards,
James

Just a note about initializing Maps (and Lists):
you can also do it when instantiating as follows
Map map = new HashMap()
{{
put(”key”, 1);
}};

More verbose, but it’s mutable.

BTW, thanks for the post

The ARM looks weird from a typing point of view. This means that in this statement:

try (BufferedReader br = new BufferedReader(new FileReader(path)) {
return br.readLine();
}

The compiler has to know that “BufferedReader br = new BufferedReader” is an assignment to a Closable object?

So the compiler depends on a specific interface???

Please correct me if I’m wrong but IMHO a much better option would have been to add call-by-name parameter (see Scala) and let people manage their resources with library calls.

Eric.

Can you do stuff like this…

someMethod( {”e1″, “e2″} );

or are they just for initialization?

@Joe Wright

I’ll take using IntelliJ Idea on all platforms over language features constrained to one. We all take tradeoffs

——

That was harsh. He is making a valid point unrelated to an IDE. C# has these features are more. In fact, the way they are being implemented in Java looks forced (hacked even). ie:

Type inference still looks backwards (C-like, first type then variable).
ARM (modifications to try) don’t make it more readable unless the IDE provides a lot of support (color coding, pretty-printing etc).
Numeric literals from PHP are better, these ones dont actually make it faster to write long numbers. A combination of number and international units would be a lot easier (1M for one million, 1B for one billion, etc).
Binary literals and strings in switch statements: about time!

Anyone here know anything about whether LinkedList is supported?

@Joe Wright

Yeah, that’s why I suggested scope. The compiler knows that scope is. So it wouldn’t be difficult for it to generate byte code that closes a Closable when it leaves scope.

I agree that having that special block as part of the try can be confusing, because it could easily look like part of the code to actually try (which it is, since those could throw exceptions too). I really think it would have been better for everyone if it was just based on scope.

Collections.mutable(list) is horrible. Because it means what you thought was immutable can become mutable inside someone else’s function. If you needed a mutable version of the list you’d make a copy like you can today.

Why didn’t they make it so collections initialized this way are mutable? I don’t see the problem with doing so.

Anyway, it’s clear I haven’t been doing Java in a long time because I mistakenly thought there was an “immutable” class type for collections. Since there isn’t, my statement about it not being obvious that a collection is immutable is stupid.

The rest of the things you listed look useful to me. I do think strings in switches can be abused, but has value as a way to handle string-based input of all kinds. In those cases, you’d have to create a big if/else to map them onto an enum to use in your switch anyway.

This is very win.

Thanks for the post.

I really hope that the resource management applies for JDBC connections, statments, and resultsets. That will clear up a LOT of unnecessary boilerplate code. I wonder if a rollback would automatically happen on a close without a commit when setAutoCommit is false.

Thanks for the post.

@Joe Wright, @Joshua

I agree on the strings on switch statements, I use enums myself as well, however I might have missed the part in which you downplayed the importance of this feature due to design reasons which I agree should be more important.

UK 1B versus US 1B: Shouldn’t that depend on the locale? That way you just set the locale in which a program runs (if you want to tighten it that much) and all units/measures are assumed so they make sense.

On ARM, please notice I didn’t say they’re not understandable. The purpose is clear once you get used to the notation and that’s the point I was trying to make. The intention is not obvious, it makes sense once you see the usage in the ‘body’ of the try block.

On type inference what I don’t like is that type inference here didn’t help readability. As in, it doesn’t look like ‘this is a variable of type T’, it is just saving you having to type the type twice. Hopefully that made sense. Still nice to see there’s some help there.

As for the rest, all in due time . It’s a marathon not a race.

Wow, It’s smellin like 1999 in here, thank god we Created .Net instead of copying this crap!

You forgot to mention the new dating/time libraries… one of the most important improvements IMO.

I see: Map&ltString, Integer&gt map = {”key” : 1};
wouldn’t this make more sense :
Map&ltString, Integer&gt map = {”key”, 1};

Since we have ‘,’ between the &lt&gt keep it between the {}.

Ugly source code colours, but interesting article…

AWESOME!!! I’ve been wanting String capabilities for the switch structure in Java since nearly day one… It’s going to be a whole new world!!

> List list = new ArrayList();
> list.add(”item”);
> String item = list.get(0);

You can already (since Java 5) do like this:

List list = Arrays.asList(”item1″, “item2″);

switch with Strings? bleh.
It will only make more people write bad procedural code. Like VB6.

I think an important idiom will be:
Map map = new HashMap({”Foo”: “Bar”, “Hello”: “World”})
and similar for Lists, Sets.

@Josuah
Variables have scope, but instances do not.

InputStream openStream(String path) {
InputStream myInput = new FileInputStream(path);
readHeader(myInput);
return myInput;
}

myInput will go out of scope, but closing is probably not desired at that point.

@Guillaume
It won’t make people do anything, but it will allow them to use it where it would be better to use than an if/elseif ladder.

What do you mean C heritage on the binary bits?
C has had 0b110010010 as literals forever?

nice updates. I can do without underscores in my code, just looks ugly to me.

were there any updates to the concurrent packages for collections?

Can you do:

List<Object> list = ["item"];

or something similar, or will it have to be:

List<? extends Object> list = ["item"];

Just switch to Scala already. Java is imploding anyway

thanks! for the info btw. Very concise and clear

@Johan – harsh statement to make seeing as Scala requires Java VM to run…

ARM is such a fugly syntax and such a fugly idea. I hate it in C#, i hate it in java.
These objects should be closed at GC time, or when going out-of-scope. A new variable qualifier would be much better – variables in any kind of block would be able to use it, and there would be no need to even use a try statement.

The lists and sets syntax looks alot like javascript, and I find it a good addition. The immutable thing seems like a problem at first, but in fact, together with the putAll method it´s really better.

Strings in switch statements is a god send. Parsing text files are such a pain. Of course, you could always create a hashmap associating the incoming text with the enum value and then switch based on it, but that’s a complete waste of time/code/effort. Switching based on string.intern will be just as fast and more readable – forget hashCode for strings.

Of course, switch based on hashCode would be able to switch over any kind of variable… seems tasty.

The diamond… well, why not take it away altogether? A nice addition though.

The other changes are nice. It’s good to see the language evolving. Too bad this ARM thing sounds like a knee-jerk reaction to .Net – which actually grows like a tumor. On the rant side of things, I find extremely annoying that there is no trivial way to plug one InputStream into an OutputStream. The opportunities for JVM optimizations are endless.
Good article, by the way

is this C#?

Is it posible to write:
try (BufferedReader br = new BufferedReader(new FileReader(path)) {
return br.readLine();
}
catch (Exception ex){
// other exception handling…
}

If it does, then this syntax is better than “using…”.

same as C#! use “try (){}” to close resource ?
Is this “try” can catch some exceptions ?
the “try” is a bad keywords!

I am curious if every string used as the target in a switch statement would get interned?

I hope the ARM will handle exceptions properly. Namely, chain exceptions and aggregate exceptions, so I can diagnose what happened when things go wrong.

For example, if “in” fails on read, and “in” fails on close() along with “out” failing on close(), I had better get back all three exceptions.

I am immensely happy with the improved type inference: I have stayed with type-free collections to avoid the verbosity of generics.

Hi, this is about “Underscore in numeric literals”, why don’t the underscore be replaced with comma which makes more sense and more human readable. How does underscore make a difference from that of comma?

Hi Joe,

Thanks for your thoughts. I posted some followup (at http://www.lessonsoffailure.com/software/official-java-jumped-shark ) on why Java Jumped the Shark with release 7.

Thanks for the posting new changes in JAVA .

I wonder when this will change on AP (College Board).

Really interesting.

list and set syntax sugar and I don’t like it. you can always use:

List l = Arrays.asList(…);
Set s = new Set(Arrays.asList(…));
Map m = new Map() {{
put(”key1″, 1);
put(”key2″, 2);
}};

IDE can help if you still think it is too explicit. Just define few live templates.

Don’t like the new “try” statement. Why they couldn’t introduce some new keyword? Looks really weird…

Making such changes is just a waste of time to satisfy noobs and dynamic language evangelists.

If the serialization is a concern in such case then I think such code smells a little. Although it was just an example of how to minimize the efforts in most cases.

As for the making common things easier it would be wise to put efforts on making class properties so it would automatically generate getters and setters. Or to provide build-in hash, equals and to-string builders (or even include all commons-lang). I’m also looking for easier ways to construct decorators and proxies so I could only implement methods I’m interested in and making other methods behave as a decorated/proxied class.

I’m looking for more compatibility with JavaFX technology so I could bind to existing java beans.

Don’t get me wrong, I’m not against these changes, I’m against putting them in favor of much more important things…

There is a good phrase, in my native language, from the old times – “‘better’ is an enemy of ‘good’”. And I think the existing java syntax is good enough.

Great rundown. Strings in switches seems so long in coming.

Collections created with the new language sintax will be inmutable? Why?

I understand those new collections will be useful whenever I can’t use an array, but … the main advantage of lists against arrays, is that lists can be modified and more important: List can grow. Without the possibility of mutating collections, language support for collections is a very uncomplete feature.

I’m not quite sure about “Underscores in numeric literals” will be useful to anybody. What do you think about this?

If the serialization is a concern in such case then I think such code smells a little. Although it was just an example of how to minimize the efforts in most cases.

As for the making common things easier it would be wise to put efforts on making class properties so it would automatically generate getters and setters. Or to provide build-in hash, equals and to-string builders (or even include all commons-lang). I’m also looking for easier ways to construct decorators and proxies so I could only implement methods I’m interested in and making other methods behave as a decorated/proxied class.

I’m looking for more compatibility with JavaFX technology so I could bind to existing java beans.

Don’t get me wrong, I’m not against these changes, I’m against putting them in favor of much more important things…

There is a good phrase, in my native language, from the old times – “‘better’ is an enemy of ‘good’”. And I think the existing java syntax is good enough.