New language features in Java 7 | Hacker News Reader

New language features in Java 7

code.joejag.com

64 pointsbensummers47 comments

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.

http://puredanger.com/tech/2009/11/18/closures-after-all/

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?

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.

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};

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.

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[].

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

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.

How many OOP languages do you know where type-inference works

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#.

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.

> How many OOP languages do you know where type-inference works?

D, C++0x

Those only work for local declarations where the type of the expression is known.

This thread was talking about type inference in this case ...

var l = [12.4, 13, "a string"];

This would require the array to have generic arguments, and those generics arguments to be inferred from the types given to the constructor (in this case the base class would be Object). I think it works in Scala, but a type unification is really hard ... i.e. to be able to write your own generic functions / classes with the generic type inferred from the base class of the given arguments.

The definition of a generic function that would do this would look like ...

Array<T> createArray<T> (T ... args)

Also, since generic definitions are a PITA to write and read, many people dream of a Hindley-Milner type system where the generic type is discovered. But I don't know of a single OOP language that does that (Ocaml and F# try, but it's ugly) since OOP polymorphism is not compatible.

The difficulty is how you define "most restrictive" in a strongly typed language. If I have classes which implement multiple interfaces which aren't subsets of each other... maybe cloneable and serializable? Which is more restrictive? Does C# solve this?

As viraptor said, it's always safe to just use the most restrictive type. Type inference is quite useless if you just infer everything to be an Object :) And beside, in cases of ambiguity, you can mandate the use of the verbose form.

I was thinking specifically of the example in C# where you can do something like:

  var list = new[] { "hello", null, "world" }

which the runtime casts as a string[].

It just seemed like these collection literals would be good candidates to use the new type-inference capabilities they're rolling out.

Specifically because of Java's wildcarding, there is an important difference between a Map<Object, Object> and a Map<? extends Object, Object>; a Map<String, Object> is not the former and is an example of the latter. This comes up in method definitions quite frequently.

Yes, this is a really stupid feature of the language.

This one is of course a circular debate that will live forever, but you might expect to be able to insert an Integer key into a Map<Object,Object>, which you can't for a Map<String, Object>, so to say the second "is" an instance of the first doesn't really work.

You are, of course, quite right, which is why I said that a Map<String, Object> isn't a Map<Object, Object>. However in Java's typing scheme it is a Map<? extends Object, Object>, which represents a key that extends Object (very specific, that) and among other things won't let you insert anything into it.

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.

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)

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())".

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.

"were deprecated more than twenty years ago by the folks that created Unix in the first place" [citation needed]

Also, could you explain some more. Why do you think that they're "atrocious hacks"? They solve some problems in a quite nice way (simple versioning for example)

lotte% ls -l /bin/^(cp echo) --rwxrwxr-x M 4328 sys sys 63454 Jan 10 2007 /bin/cp --rwxrwxr-x M 4328 sys sys 57592 Jan 10 2007 /bin/echo lotte% bind /bin/echo /bin/cp lotte% cp file1 file2 file1 file2 lotte% ns |grep echo bind /bin/echo /bin/cp lotte% ls -l /bin/^(cp echo) --rwxrwxr-x M 4328 sys sys 57592 Jan 10 2007 /bin/cp --rwxrwxr-x M 4328 sys sys 57592 Jan 10 2007 /bin/echo ns|grep /bin bind /386/bin /bin bind -a /rc/bin /bin bind -a /usr/fgb/bin/rc /bin bind -a /usr/fgb/bin/386 /bin bind -a /usr/inferno/Plan9/386/bin /bin bind /bin/echo /bin/cp

here's bind(2) man page, in case you're interested in learning some 20 year old technology http://plan9.bell-labs.com/magic/man2html?man=bind&sect=...

Not sure which point was this supposed to address. It neither proves that links are "atrocious hacks", nor that links were deprecated in any way. Links may be not used in P9 of course, but that doesn't change anything in the rest of the world. If I create a research project which uses pipes as a substitute for sockets, it doesn't mean that sockets are deprecated anywhere else.

PS. This does not mean that bind is {better/worse/useless/deprecated/teh-win}. `mount -o bind` on linux exists and is not replacing sym/hard-links anytime soon.

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

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.

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)

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.

is this support used by cygwin?

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

In fact I strongly suggest you consider ntfslink (http://elsdoerfer.name/=ntfslink) which provides a nice UI for doing all this in explorer.

As far as I can tell, reparse points for directories will usually work perfectly well for most of the things you'd expect them to. I use them, and a subversion repository to version control pretty much everything config related on my windows machine.

Seems like you managed to piss off Java as well as Unix guys in a single sentence. But a fair question is what you would use instead of links. I suppose you are talking about plan 9.

Deprecated?! When?

Symlinks are actually pretty handy. Have you never seen/used:

  Current -> MyProg_1.8.9
  MyProg_1.8.9
  MyProg_1.8.8
  MyProg_1.8.7

How/why would you do that without symlinks?

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

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?

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

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)

Oh, but you can still do:

  List<String> list = new ArrayList<String>();
  list.add("item");
  String item = list[0];

right?

I guess I was thrown off by the wording- I assumed the line about collections being immutable applied to all collections that use the new syntax.

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?

Is the addition of immutable structures going to push the JVM towards more optimization for immutable structures in any way? I ask because of Clojure, not Java itself.

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

Underscores in numeric literals

This proposal was just rejected in Go, alas.

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

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.

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).

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

Reply on news.ycombinator.com