

New language features in Java 7 - bensummers
http://code.joejag.com/2009/new-language-features-in-java-7/

======
jimbokun
These changes will make a concrete improvement to my daily productivity as a
Java developer. Definitely removes some of the pain points relative to other
languages.

If they can also do something about closures, I'll be much happier as a Java
developer when this comes out than I am today.

~~~
madair
The Closed By mechanism seems so obvious in retrospect. What a great
improvement to stability of applications overall by embedding that simple and
error retardant pattern into the language.

I'm trying to understand why the collections syntax would create only
immutable collections? Anyone know why so?

~~~
gchpaco
It theoretically permits optimizations where multiple parts of the code using
the same, say, string literal can refer to the same literal. I don't believe
for a moment that this is actually happening in Java, but immutable literals
are not uncommon in this class of language.

------
dschobel
Nice to see the language maintainers finally taking the weed-whacker to the
syntax.

The collection literals are nice too, but why couldn't they infer the type
from the following?

    
    
      Map<String, Integer> map = {"key" : 1};
    

to make the syntax:

    
    
      Map<> map = {"key" : 1};

~~~
smanek
How do you know it isn't a Map<Object, Object>? ;-)

It's kind of trivial in your example, but with complex objects that implement
a lot of interfaces it isn't as obvious what the programmer means.

~~~
viraptor
You can always assume that it's the most restrictive type that you want. How
many times did you really need Map<Object, Object>, when you initialised the
map with {"abc":1, "def":2, "ghi":3} ?

Since you can always make it specific what you want, you can assume that the
most common case is the "default". That's what c#'s `var` does anyways - if
you have a `var a=1;`, 'a' an int, not an object. If you use `var a=new
[]{1,2,3};`, it's int[], not object[].

~~~
ajross
Or go one better and extend the language to do true type unification. It's not
like this isn't well-travelled territory.

~~~
bad_user
It's not. How many OOP languages do you know where type-inference works?

I know of none ... Ocaml uses a special syntax for reconciling the type-
inference with the inclusion polymorphism that it supports ... (name :
sub_type :> super_type). And IMHO it gets ugly.

I'm not really clear about what "type unification" you're referring to, but
the actual types in Java aren't known until runtime (you usually only know a
parent). To change this behavior an overhaul of the entire architecture is
needed.

~~~
StrawberryFrog
_How many OOP languages do you know where type-inference works_

C#

Not "type-inference" in the very general sense, just "type-inference" in the
"when you see 'var someVar = 3;' you can infer that someVar is of integer
type" sense. Which is what java is doing again. Playing catch-up to c#.

~~~
bad_user
Java is not adding local type inference as in C#. It only adds the diamond
construct for inferring the generic types from the variable's type being
assigned ...

Map<String, Integer> m = new HashMap<>();

Which is ugly, but many Java developers are taking "programming to an
interface" rule quite literally.

------
bensummers
I'm beginning to wonder more and more whether Duby might be a bright future
for writing code for the JVM.

<http://kenai.com/projects/duby>

It uses Java types, doesn't need a runtime, and most interestingly, has a
pluggable compiler. The Ruby-like syntax may not be to everyone's taste, but
it's nicely compact.

~~~
10ren
I found that site hard to navigate. Here's some sample code:
<http://kenai.com/projects/duby/pages/Examples>

(note to self for own project: make samples very accessible)

------
jmount
Looks like Java 7 Path class will finally let you link files (yea, made it up
to mid nineties Posix level). Java was always very inconsistent about what was
not in the language "because some platforms may not have it (ME)" and "well we
put a method there and we will throw if we don't wan't to do it
(Iterator.remove())".

~~~
uriel
I hate Java with passion, but symlinks (and hardlinks) are really atrocious
hacks that should never have happened, and for good reasons were deprecated
more than twenty years ago by the folks that created Unix in the first place.

~~~
DannoHung
You can't just say something like that unqualified. My life is made better
_daily_ by the presence of symlinks.

~~~
rbanffy
My life under Windows is made worse daily by its lack of, among other niceties
of civilization, symlinks.

Hard-links would also be a nice addition. I am sure NTFS supports them deep
inside it.

~~~
halo
NTFS does indeed support both symbolic links and hard links in recent versions
of Windows, and they can be created with the "mklink" command-line utility.
(see: <http://en.wikipedia.org/wiki/NTFS_symbolic_link>)

~~~
gaius
NTFS _always_ supported links, but there was no interface to actually using
them from the Win32 subsystem. However the POSIX subsystem could use them
since NT 3.5 at least.

~~~
coliveira
is this support used by cygwin?

~~~
imd
From memory, yes. Also, GNUS uses hardlinks, and it worked for me under
Windows XP.

------
cabalamat
Nice features, shame they didn't do them 10 years ago.

------
paulbaumgart
When he says the new collections syntax creates immutable collections, does
that mean modifying them creates a copy, or that objects in the collection
can't be added/changed at all?

~~~
hello_moto
I think he meant adding a new item would create a new list. Which makes
working with operation expensive but a bit safer.

~~~
akronim
You can't add items to immutable collections - if you call add() etc you'll
get an UnsupportedOperationException. If you want a mutable version then you
need to create a new collection, and can use the immutable collection to
provide the starting values, like this:

    
    
      Set<String> mutable = new HashSet<String>(immutable)

~~~
JulianMorrison
Which is madness that completely misses the point of proper immutable
collections (Clojure style) - that you _can_ "modify" them, by creating a new
copy with the thing added, and it shares storage with the original and the
copying isn't as slow as a copy-by-clone.

The first thing people are going to do with these half assed immutable
collections is pour the contents out into a mutable container. Which
completely obviates all the thread safety and whatnot.

I slap my forehead. Do these people have _no_ sense?

------
MikeMacMan
I'm pleasantly surprised by this. Now if we can only get properties...

------
jeremyw
_Underscores in numeric literals_

This proposal was just rejected in Go, alas.

What a readability difference it makes in Ruby, Eiffel and (originally) Ada.

~~~
ams6110
Heh. I was going to post that I thought this was a fairly useless feature,
certainly not on par with the impact of the other new stuff. But, I can't
really say that it is a bad thing... I guess.

------
_giu
nice new features. the diamond operator looks good. closures will be fun, too!
starts to feel like C# (automatic resource management (C#'s IDisposable),
language support for collections, strings in switch).

------
wicknicks
Nice features... Code will now look a lot cleaner and concise.

