whats new?

What is new that java 1.7 has that 1.6 doesn't.
Other then the fact they have add some classes / packages.

I am more getting at the language itself?

For example 1.5 / 1.6 has generics , auto boxing , annotations , enums ,...etc but 1.4 doesn't
Is their any thing to the java language that is different or is it just class/packages for this version.

Also did they add any new tools that can't be found in the bin files that are not in java 1.6 or lower or any tools that at all.

Sam Doder wrote:For example 1.5 / 1.6 has generics , auto boxing , annotations , enums ,...etc but 1.4 doesn't

Except assertions. But Java 7 didn't add any new language features that I know of. Not even the desired overloading of mathematical overloading for BigInteger and BigDecimal...

Here's a list of the language enhancements. Including...

- Resource management ("try-with-resources"). I can see that being very useful - the equivalent of the using statement in C#.

- Multiple exception catching

- Generic type inference on creation

- Switch on Strings

D'oh! I forgot all about those!

What's new? A good blog post here: http://dublintech.blogspot.com/2011/07/java-se-7.html

Number literals in the formats 0b01010101 and 123_456_789 and similar.

Thanks Luke for the link.... really loved some of the new features added in Java 7!!!

Not even the desired overloading of mathematical overloading for BigInteger and BigDecimal...

IMO, overloading is one of the more evil features of C++. I sure hope it never makes it into Java in a general way (meaning, where everyone can define what "+" means for class X).

I agree on not letting just anyone overload operators. However, there is already operator overloading for String (+). I don't see any problems adding it to two other numerical classes in the core API. It's already added to the primitive wrappers through boxing/unboxing, so why not for these two?

. . . and in this case it would be intuitive. The overloaded + isn't intuitive for Strings.

Personally I think I would enjoy operator overloading. It can greatly increase readability of code. Of course it can and will be widely abused; but the same is true for the sub-typing system. Should Java have gone without inheritance?

Inheritance is actually a feature I, for one, rarely use. Interfaces, OTOH, are a great thing.

One feature that was rushed in and caused a lot more problems that it solved (IMO) were the wildcard generics.

Was generics rushed in at all? They took their time writing generics, nice and slowly. 9 years too slowly

If generics had been available from the start, it would have been based on reification, not erasure, and it would have been easy to understand.

I very rarely use inheritance myself, but was it a mistake to add it to the language, because so many new programmers misuse it?

Campbell Ritchie wrote:Was generics rushed in at all?

Not generics - wildcard generics. That was very much a rush job.

What would have been better ways to do them? I've had no problems with wildcards myself.

Arn't closures being supported or something along those lines so we can have anonymous functions work like in other languages that use currying and such? I thought I read that somewhere

Closures not seen yet; they are planned for J8. And that might still not be realised.

Stephan van Hulst wrote:I very rarely use inheritance myself, but was it a mistake to add it to the language, because so many new programmers misuse it?

I'd have to agree with this...I mean I've only been out in the real world for a couple months, and I've never really used inheritance at all. Mostly composition...

You can read it here, all accumulated. http://www.geekyarticles.com/2011/07/whats-new-in-java-7-project-coin.html

Ulf Dittmer wrote:IMO, overloading is one of the more evil features of C++. I sure hope it never makes it into Java in a general way (meaning, where everyone can define what "+" means for class X).

Actually, operator overloading came from ADA before C++, and may have come from something before ADA. But I agree that it is evil. I don't see it having any value except for numeric data types. I spent ages working on a Money class with proper overloading, and it was never perfect.

I think we'd be better off with language-defined abstract numeric data type that has the usual arithmetic overloads, and let us implement the required functions.

Still, its not clear what the proper meaning of when a is Complex and B is Money.

The same is true for every other function.