Skip to main content

Which of these excluded-from-Java-7 features were you most interested in?

Closures
47% (856 votes)
Reified generics
18% (321 votes)
First-class properties
10% (187 votes)
Operator overloading
5% (84 votes)
BigDecimal syntax
4% (75 votes)
JSR-295 Beans Binding
7% (137 votes)
I wasn't interested in any of these
9% (174 votes)
Total votes: 1834

Comments

Be Careful with Closures!

Although there appears to be a majority in favour, the number in the opposed and not yet camps is significantly higher than for many other proposed changes.

Be Careful with Closures!

that, and it's a given that activist people in favour of something are more likely to "vote" for it that those who're in doubt or opposed. And of course there's the silent majority who wouldn't even know what we're talking about, doesn't know what "closures" are, couldn't care less about them, and don't even know there is a poll out at all. The vast majority of people who do like closures know about this site, having been driven here to promote "their" candidate by various battling combatants who mostly only care about closures because they want their name on a JSR rather than because it makes sense for the language or is in any way useful (it doesn't make sense nor is it useful).

Properties

Everybody wants watchable Properties to get binding à la JavaFX. I think the argument against Properties in Java 7 is "we need more time for a deeper reflection (pun intended) on JavaBeans in general". Olivier Allouch

Properties

not everybody :)

Personally, I couldn't care less. But I can see how for people writing Swing components and maybe some other things that can be plugged together using graphical editors they might be "nice to have".

Properties

I like that idea. Also while I used to be very for first class props, my initial thought was just "copy" C#. I think I was being reactionary about it like most. Even C# properties are more complicated than they need to me. In MOST cases I would say you need a simple getter and setter with possible "thread-safe or not" lazy initialization. Another option would obviously be a new event system. These couldn't be done by just copying C#. I think Java really has an advantage because it wasn't done wrong.

Properties

C# copied most of its system from Delphi :) Of course they did change the syntax and some capabilities, but the general idea remained the same (unsurprising, as the language designer of Delphi now works on the C# team).

Properties are important

Interesting to note that if you combine votes for first class properties and JSR-295 (Beans binding) it exceeds the second place choice. I think it is fair to combine the votes there because presumable first class properties would not be done in isolation with out a mechanism for binding, and the beans binding JSR was excluded precisely because it only made sense to include in the JRE when the property issue was resolved.

Please make proposals how to fix the generic mess

Especially how to get rid of those wildcards. They are a shining example how not to solve a problem in a mainstream language. For very little effect very complicated rules that no programmer completely knows. Maybe using reified generics and covariance of the generic parameters would be a solution. Container without type information (legacy code) should be seen as ContainerClass. Wildcards are such an impractical solution that you see them seldom really used today. If they are already used, a compiler switch should be introduced to compile such code. And stop this "meta annotation" bullshit going on, which is the same intellectual aberration. Language design with bookkeeper mentality without any spirit for elegance, this is the best way to ruin the language, that served many of us so well. The most important Java feature was and is: Java should be easy to remember in order to be an efficient tool! OK, some keystrokes more to formulate something, but there are editors to solve this. Most of the time you have to read other peoples code anyway and then its the best feature of Java to be easy to read and almost self-documenting. If someone likes a more challenging language or believes in the trend of the season "functional programing" than there is Scala. Like for the last seasons trend "Aspect orientation" there is AspectJ. And if the functional concept really has many advantages in the wild, Scala will slowly overtake the status as main language on the JVM. And for the scripting fans there is Groovy. So everyone already has what he needs. So please only make proposals how to simplify Java and gain elegance, not how to further complicate it, (extremely) as in the case of BGGA closures.

Be Careful with Closures!

I agree with the decision to postpone closures at this point in time. I support the basic idea of closures, or at least some form of function types, and I always thought that anonymous classes were a kludge (albeit a useful one), but it is important that the Java community get this concept right with respect to integration with existing language features. While there appears to be a lot of interest in adding closures to Java, there does not appear to be anything close to a consensus as to the best way to do it.

Be Careful with Closures!

I think it's very clear what version of closures we want and when we want them.

Be Careful with Closures!

Really, which one do we want ?

Be Careful with Closures!

it is indeed clear: none and never

No closures?!

What the heck are they waiting for?!?!

No closures?!

I don't know. I think not a lot of Java fans have coded enough with other languages that have closures, like JavaScript or ActionScript (specially the 3rd version with the "this" autobinding). When you get used to it, there's not coming back. Those languages don't have the "return" trick that the BGGA proposal has, that's why it scares me a bit (even if I see its power). Olivier Allouch

java7

if these features didn't made into java7, what the hell did? maybe they should release j6 u x+1 how many times did you need this: T object = new T();

java7

if I were bad at making up classnames, maybe a lot of times.

If you have a class named 'T' with a no-argument constructor, it's the way to create an instance :)