Do You Really Need Java 7?

Annotations, autoboxing should not be there at all, and generics is just an awful patch.

Closures would be much more useful than any of them.

 [/quote]

Annotations are great, actually.  For injecting behavior into classes, annotations are a great alternative to "XML Hell".

Autoboxing is a nice convenience.

Generics are nice to have in some situations.  But the implementation left a bit to be desired.

Closures could be cool, too. 

But again, let's be careful about feature bloat.

Java already has Closures, since Java6 you can use scripting languages that have Closures in Java.

You think closures in Java7 will help you? how many of you are using Java6 now? I'm not. Use JRuby with Java6 and you dont need to wait 2(or more) years for Java7 to be adopted at your company. Its just a lib, so it wont be as big of a problem as moving to next version of Java.

I like idea of closures and i do use them in Javascript, but they can be very bad for all of us. Look at retarded bugs that you should know in SCJP or Java Puzzles. I think both of those circuses would be easy when compared to misused closures.  Damn, I saw some generic subclasses that take 2 or 3 generic params that I dont even care to understand(they cant be that hard, but it just looks scary).

"Sun wasting time with JavaFX that nobody is interested"

I think JavaFX is like JSF - nobody likes it, but 2 years from now it will be used by many companies. If you do Swing maybe you should move to JavaFX. I hate to do GUI because of Swing, I used to love that in other languages. 

[quote=rickyclarkson]

You seem to have inserted some logic that I didn't write.  Java doesn't have to have closures because C#, PHP, C++, Delphi, JavaScript, Ruby, Python, Haskell, Scala, Groovy, Smalltalk, Lisp, D, VB.NET and Perl do, but because they're useful.  That's why closures are in those languages. 

[/quote]

Well, but it's Java that has probably more developers than any two of those languages together. It's Java that most successful projects are written in. It's Java that has the richest ecosystem of libraries and tools.

And all that without closures.

[quote=rickyclarkson]

Here's an example where closures are useful:

List<Integer> lengths = listOfStrings.map(string =>  string.length());

There are many more, and you can write them all in Java today, at the cost of unreadable code.

[/quote]

Oh yes, and some people are even able to make a hash table full of closures.

It would be more useful to see a non-trivial project rewritten using closures; even if they are really useful (which I believe they are not) it's possible there are other reasons to leave closures out of the language such as readability or maintainablity of the code.

Or Java may be already including macros as well to catch up with Arc.

It is even debatable whether the core language features are a selling point at all.

Java must be kept up to date, but to keep up it needs to support new APIs, standards and pseudostandards, it needs to exploit new operating system capabilities and so on. It's standard libraries and what they call the ecosystem that is the selling point, not the closures or lack thereof.

[/quote]

Bingo.

 And the Java ecosystem trumps language features in other platforms any day, every time.

Great Mikael,

 that's exactly what I was about to say.

In my company, we are using essentially Java, C# or PHP for our various projects.

In the PHP team, nobody is using objects (PHP has them!).

In the C# team, nobody is using delegates, let alone closures.

In the Java team, people are using generics (no choice when you use some Collections!) but nobody (almost) develops genericized classes/methods.

The reason: engineers do not master these language features!

When you have 100 engineers in your company, you cannot expect all of them to be experts in one language. If one is an expert and use his expertise to use complex constructs in that language, then only he will be able to read and maintain the code he has produced. That maybe OK for a guy working on Open Source project but not for a company that develops projects involving teams of 5, 10 or more engineers during months or years.

Jean-Francois

People in real companies won't use your TimingFramework 1.6 without closures.  If 'time' was built into the language, you could write:

time {

    myExpensiveCode();

}

Without it being built into the language, calling such a method from a library looks like:

time(new Runnable() {

    public void run() {

        my expensive code

    }

});

and inside that block, 'this', 'return', 'continue' have a different meaning.  With closures, especially the BGGA proposal, you could write it as:

time() {

    my expensive code

} 

You can still tell it's a method call, which I think is a bad thing, but probably lots of people prefer it that way, because they haven't seen Guy Steele's talk, Growing a Language.

So imagine working with the average corporate development team, and trying to stop them writing the repetitive boilerplate rubbish for timing some code.  Changing their code to use a Runnable makes it too long, breaks the semantics (regarding this, return, break, continue) and is just plain unreadable.  With closures in the language, it's much easier to encourage unrepetitive code. 

"You seem to assume that the most important selling point of a development platform is the number of the core language features. But if it were so, we'd be all switching to Arc right now, away from Ruby."

Ruby has far more core language features than Arc.  Implementing Arc takes a good Lisp programmer a day.  Implementing Ruby is a really big timesink.

The core language features were a selling point back when Java started; now they're more of an embarrassment.  enum is the only feature I can think of without flaws. 

[quote=partyzant]

You seem to assume that the most important selling point of a development platform is the number of the core language features.

[/quote]

Where did I write that?

I wrote "Otherwise decision makers will eventually consider Java as outdated."

You're arguing from a technical point of view. That's ok for a developer, but developers are rarely asked when it comes to the decision whether to go with M$ or the Java platform. Developers come into play when the decision is already met! And this is decided on other criteria. One is the perspective. Will Java be the leading platform in 3 years? For a new project you cannot afford to bet on the wrong horse. 10 years ago I just needed to suggest Java and all was fine. Today I'm asked to elaborate the benefits of either platform. I would never, never, never suggest "compensating" features missing from the Java language by mixing in "modern" languages like Groovy. Guess what the next question would be: "ok, and how many extra Groovy developers do we need then?" Did you notice the word "extra" ? You don't need extra Ruby developers for C#, don't you?

Java, the language and the platform, must be improved permanently and this must be communicated! Falling behind -- whether it is technically relevant or not -- is psychologically bad because it is interpreted as "outdated". Java isn't outdated and I understand the concerns not to bloat the language. But I'm sure the language can be improved in a technical elegant way. Btw., it's not only a matter of the language itself but also the platform as a whole, the tools, the APIs and everything that has an impact on productivity, quality and cost.

So, please don't ask whether we need features x,y or z. Better struggle for the most elegant implementation. We need Java 7, and 8 and 9 and whatever comes next. It's never too late. The second mouse gets the cheese...

Ruby has far more core language features than Arc.  Implementing Arc takes a good Lisp programmer a day.  Implementing Ruby is a really big timesink.

[/quote]

Arc has a s-expression based syntax - if someone implements it in Lisp, they get the parser for free. It also has nearly no standard library so there is very little to implement.

[quote]

The core language features were a selling point back when Java started; now they're more of an embarrassment.  enum is the only feature I can think of without flaws. 

[/quote]

Not really, Java had very little core language features when compared to C++, Perl or even Common Lisp.

The standard library was the strongest selling point, but simplicity (as in lack of core language features) was also significant.

Developers come into play when the decision is already met! And this is decided on other criteria. One is the perspective. Will Java be the leading platform in 3 years? For a new project you cannot afford to bet on the wrong horse.

[/quote]

I don't need to be certain that Java will rule the world in 100 years, it's enough that I'm pretty sure that it will be a strong player 10 years from now.

[quote]

10 years ago I just needed to suggest Java and all was fine. Today I'm asked to elaborate the benefits of either platform. I would never, never, never suggest "compensating" features missing from the Java language by mixing in "modern" languages like Groovy. Guess what the next question would be: "ok, and how many extra Groovy developers do we need then?" Did you notice the word "extra" ? You don't need extra Ruby developers for C#, don't you?

[/quote]

Imagine, I don't need extra Groovy developers for Java either. Surprising, isn't it?

I just don't need those "missing" features. Some of them (not closures though) would be nice to have but I am always happy to trade them for state of the art class library, containers, frameworks and internet standard implementations.

Yes, there was a moment in time where Java had no real competition but of course it could not last forever. Now there is a strong competitor, but closures are not a c#'s strength. It's its growing ecosystem that is a threat for Java, and also better integration with the OS.

[quote]

But I'm sure the language can be improved in a technical elegant way.

[/quote]

I would like to see some things from C#, like the 'internal' keyword, but throwing every feature into Java just because C# has it is no good.

Well, seeing as the various compilers that add closures to Java are all not actually final products, it would be a bit odd for me to rewrite my Java project in Java-with-closures.  I think I'd only do that if I was comfortable with the idea of fixing the compiler myself if it does strange things.  So you're asking for the impossible.  One can only give analogies really.  Perhaps you can find a C# project that has been altered to use lambdas (what the wider community calls closures) rather than delegate syntax, and compare the difficulties they had before and after.  If any scientific studies have been carried out you'll probably be able to dismiss them as trivial.

For strong evidence, try taking a LINQ tutorial and porting the code to Java.  Or any beginnerish Haskell tutorial.

Regarding macros, I have temptations to use macros in pretty much every language I use.  For example, at work, I'm forced to write documentation saying that a null parameter input will yield a NullPointerException.  I'd really rather not write that again and again, and instead write a macro, methodThatDoesntAcceptNulls, or similar.   Source code manipulation is pretty useful.

[quote]I don't need to be certain that Java will rule the world in 100 years, it's enough that I'm pretty sure that it will be a strong player 10 years from now.[/quote]

Sure? ;)

[quote]Now there is a strong competitor, but closures are not a c#'s strength[/quote]

One more chance to make it even better! ;)

It's as always with new things. When I heard about generics the first time, I didn't see any evidence why I should need that. Later, having played with it, I was so convinced that I "generified" a whole framework. Same will happen with closures. Since I learned Ruby, I'm really missing closures in Java.

[quote]I would like to see some things from C#, like the 'internal' keyword, but throwing every feature into Java just because C# has it is no good.[/quote]

Agreed!

Well, seeing as the various compilers that add closures to Java are all not actually final products, it would be a bit odd for me to rewrite my Java project in Java-with-closures.  I think I'd only do that if I was comfortable with the idea of fixing the compiler myself if it does strange things.  So you're asking for the impossible.

[/quote]

Do I really? Someone has put the effort into building those closure-enabled compilers, so it would not either be impossible to take a medium sized open source project and rewrite it using closures to have real evidence of how they help. Somehow it didn't happen.

[quote]

One can only give analogies really.  Perhaps you can find a C# project that has been altered to use lambdas (what the wider community calls closures) rather than delegate syntax, and compare the difficulties they had before and after.  If any scientific studies have been carried out you'll probably be able to dismiss them as trivial.

[/quote]

Well, I'd very like to see some real life example because so far languages that support closures aren't famous for their readable and maintainable code. My, even Python has only simple lambdas. But maybe let's copy Perl instead, first class regex syntax anyone?

[quote]

For strong evidence, try taking a LINQ tutorial and porting the code to Java.  Or any beginnerish Haskell tutorial

[/quote]

This is exactly why I look for a real life example and not some tutorial. I want to see not only the syntax but also the impact that the change would have on the rest of the code. Would it lead to more or less duplication? Would it make refactoring easier or harder? Would it play well with existing language features or not? Those questions, and many more should be answered before the closures, which, in the BGGA example are quite radical a change and it's not something one will be able to easily avoid if it's included.

[quote]

Regarding macros, I have temptations to use macros in pretty much every language I use.  For example, at work, I'm forced to write documentation saying that a null parameter input will yield a NullPointerException.  I'd really rather not write that again and again, and instead write a macro, methodThatDoesntAcceptNulls, or similar.   Source code manipulation is pretty useful.

[/quote]

If macros could serve only for similar purposes I'd support them but this is not the case. Especially Lisp style macros which are a very powerful gun to shoot oneself in the foot with.

[quote=partyzant]The standard library was the strongest selling point, but simplicity (as in lack of core language features) was also significant.[/quote]

Java was the first reasonable OS-independent development platform & language.[/quote]

Yes, it was also one of its selling points. It may be argued whether its promised WORA was stronger a selling point than the standard library. I believe it was standard library because the real success of Java is the server side and that's where the OS-independence is not so important and the availability of libraries certainly is.

Either way I don't see core language features as an important selling point. OK, maybe leaving out some core language features present in C++ was a selling point. :-)