Can you really argue that creating a closure is more complicated than creating an anonymous inner classes? Try to explain to a garden variety Java developer why variables outside an inner class have to be declared final and watch his eyes glaze over. Inner classes are far more esoteric than closures. You are correct. I would have also prefered closures. The specification of inner classes should have been thought about much more careful. They are beside many apects of Generics a good example that one should think very careful on language additions. But now things are like they are and I think it is even more confusing to have several dissimilar ways of formulating the same thing after addition of closures. In my private optinion a version of the language should be defined that is slightly incompatible with the current but that fixes the accumulated problems with inner classes, Generics, the way properties are written and so on (just like Python is going to manage it). Then Java could improve and stay a consistent and hand tool.

I'm not arguing that people are too stupid to understand closures In that case why did you state so? So because Java has been "a handy and effective language", there is no room for improvement? No, you're putting words in peoples' mouths. Stating that there's no room for closures or operator overloading doesn't mean stating that there can't be changes that ARE appropriate... Who's forcing you to use closures? Is someone forcing you to use annotations? What about generics? Is your manager threatening to fire you if you don't use the new for loop syntax? The person who wrote the code you have to maintain. And yes, my manager would fire me if I didn't maintain the projects I have under my responsibility that use annotations (which I don't care for), generics, new loops, and autoboxing. And he'd have every right to as refusing to do my job is grounds for being fired. There are a lot of things that closures can do that can't currently be done. For example, if you have an inner class in a for loop, can you break out of the for loop from inside the inner class? No you can't. Can this be done with closures? Yes it can. Which makes for harder to comprehend code, added obfuscation, in other words, isn't beneficial in the least. Closures are function pointers in disguise, which is NOT something that's suitable for Java or any other language not designed from the ground up to have them.

Thanks for the link, I'll read it. But Java is today's programming lingua-franca; practically anyone can read Java code, and adding closures would make it less readable for less skilled programmers. Closures will probably make you more productive for the initial release, but take its toll at maintenance time. We should be after lowering maintenance costs, not decreasing time-to-market.

+1, sounds good.

+1

Yeah, the right way to do it is: if (boolean.class == x) {

Personally I am against any more changes to core Java language at least for quite some time; but one feature that I really like to be part of Java is ADA like subtyping. A subtype is a type whose values are a subset of the values of some type. So a subtype is characterized by: • A base type • A set of values which is a subset of the set of values of the base type • The same operations as the base type It is a very elegant and clean way of checking the values of types at compile typing with out throwing lot of exception. E.g. instead of throwing an ArithmeticException inside your method because in parameter is less than 0; you can create a subtype of Integer with Range from 1..1000.

In Javaland, we should sometimes look over the rim of our coffee cup. It's not only Ruby or Groovy going for closures: class Program { static void Main(string[] args) { List names = new List(); names.Add("Dave"); names.Add("John"); names.Add("Abe"); names.Add("Barney"); string abe = names.Find(name => name.Equals("Abe")); Console.WriteLine(abe); } } (hope the formatting works, no preview...) Looks a lot like Java, but in fact it's C# 3.0, where they call it Lambda Expressions. And they aggressively go even further (have a look at the LINQ stuff)

A lot of these discussions are too focused on language syntax as if the compiler will solve all my problems. If only the language could check this, or prevent me from doing that, and so on. I don't think that anyone is stepping back and seeing the big picture here. It doesn't matter what the language checks or doesn't check, nobody would ever forget about engineering discipline, right? So, you implement walkthrus, reviews, and feedback between marketing, product management, design, construction, QA, support, documentation, and other groups to make sure that you have 1) solved the right problems, 2) have a quality and supportable implementation, and 3) that everyone is working from the same understanding. That said, the development team unit tests their code, and the QA team performs verification to the design materials. Even in an informal setting, nobody in their right mind would not test to verify behavior. So, my worry is that a lot of these features, while syntactically interesting, do not really amount to a hill of beans. Are we making the language overly complex and essoteric for any net gain in the big picture? Combine that with the overwhelming use of modern IDE's and tools to check, cross-check, fill-in boiler-plate code, suggest alternatives, enforce stylistic standards, and to test the code, do we NEED the compiler to do any more? We have never needed these things in the past and have built major systems, with high levels of complexity and quality. Why now are these "problems" raising their heads? Just because it is possible to do something does not mean that it is a good idea to do it. The compiler can't possibly save a programmer from doing something wrong. So, if the justification for these additions is to "protect the programmer" from making silly mistakes, then I suggest that this is a bad reason. There is a very old saying in software, "you can't make software foolproof because fools are so @&$% ingenious". That goes for languages too. If you want to solve problems in the language, then lets try some of these: 1. Allow us to use an object reference in a switch, not just a primitive. Allow the case to be an expression instead of a constant. 2. Add serial I/O support that is portable across platforms and supports USB as well as traditional serial devices. 3. Add cross-language capabilities so that we don't always have to build our own bridges in JNI 4. Adopt SWT as another GUI standard. It can coexist with Swing! It's just another tool in the toolbox. 5. Add labeled breaks and continues. That would allow me to jump out of nested loops to any level in one statement rather than adding bizarre logic to detect when to break out. I'm not posting this message to suggest any specific changes, although I could. There are other features and capabilities that could be of value to a developer. However, of these, only a very small amount would be language changes. Almost all are added support, additional packages and implementations, etc. The java language (at 1.4 level) is a great language. As it stands, the language itself is very mature, and needs very little tweeking. The problem that I see is one of it being a mature product. As a product develops, it is basically a clean slate. Allmost all of the input is from every level of user of the product. As the product matures, the users that are getting their needs met stop being vocal, and the "majority" of the comments are being generated by the "minority" of the users. So, as a product matures, it is extremely important to make sure that you are not getting driven by a vocal minority, that will cause you to loose your silent majority. Also, the silent majority had better not remain silent, or else this is exactly the outcome that will happen!

Provide hooks into the compiler so that you can extend java with a sub languages. Useful small sub languages could be

• multi line strings
• embedded sql statements
• reflection based dynamic method invocations
• embedded xml

in the top you would write import language sql org.bla.sql.EmbeddedSql; java would then be extended with some syntax to separate java and the extension languge so you could write something like int zip=12345; @xml.stream(System.out){ @java{ for (String name : @sql.query{select name from people where zip = @java.zip}) { @xml{ @java.name } } } } @.{ text until '}' } @{ text until '}' } @.{{ text until '}}' }} @.{{{ text until '}}}' }}} this syntax should be enough to separate other languages and java. Maybe the languages can provide some information to tools so that eclipse can syntax hilight the embedded language.

Granted some of the proposed additions seam to have little value. Language level XML support? Do we even want this? Language level SQL has been done a number of times and every time it has resulted in a mess. Do we want to repeat these mistakes with XML? In my opinion, closures are long overdue. We don't need closures because Ruby has them. We need closures because they solve real world problems. They provide a clean mechanism for eliminating redundant error prone boilerplate code. They simplify creating event handlers and callbacks. I have yet to hear an argument for not including closures from someone who actually understands what closures are. Strings in switch statements are another feature that are long overdue. Language level property support might be nice but I think it's too little too late. We already have plenty of tools for working with the getter/setter pattern. I'm not convinced this is needed or wanted. Lightweight method references (ie. delegates), I'm all for this and honestly I'm surprised Java hasn't included this sooner. We can already do this with reflection so let's add compile time support for it. Operator overloading only makes sense for numeric types. If we could add support for operator overloading to instances of java.lang.Number, that might be acceptable. Using + for things like adding something to a collection reduces readability in my opinion. That just my $0.02.

So far many of the applications we develop require an observable data. Wouldn't it be nice if JDBC 5.0 would offer an observable interface on the connection? This would eliminate much of the code we develop. Here is what the code would look like (maybe on java.sql.Connection): public interface Connection { enum DbEvent{ DbEventInsert, DbEventUpdate, DbEventDelete); // Listen to a particular insert, update and or delete on a particular query public void addDbListener( String query, EventEnum[] eventEnum, DbListener DbListener ); // Remove the same listener as above to stop receiving updates public void removeDbListener( DbListener dbListener ); } public interface DbListener { public void recordsInserted( ResultSet resultSet ); public void recordsUpdated( ResultSet oldResultSet, ResultSet newResultSet ); public void recordsDeleted( ResultSet recordsDeleted ); } I think this would be a major improvement to make the JDBC connection a 2 way pipe between the client and database. Not all JDBC drivers would be force to implement it, since you could have JDBC 4.0 (like what is available now) and JDBC 4.0observable which adds the observable capability.

As a proponent of language change, reading the arguments against change is always interesting. For me, its all about finding the right language changes. Group one is "minor fixes to existing language features". This includes tweaks to the annotation system and reified generics. Group two is "features that increase compile-time safety". This includes method references and better null handling. Aspects of closures and properties also increase compile-time safety. Group three is "major new features that complement the existing language". This is the most controversial group. It includes possibilities such as limited operator overloading, properties, variable substituted strings, array notation to access collections and closures. Personally, I believe that the Java language can quite happily absorb many items in group one. I also strongly believe that group two is vital, as compile-time safety is really the biggest gain for a statically typed language. The real debate should be over group three. My own view is that Sun should create an JavaNextGeneration language which is 95% compatible with Java (for easy migration). But as they don't seem to want to do there has to be a choice whether to add group three features to Java. IMHO, I think the benefit is there - of course not everyone will agree.

when we develope a program under a mobile phone，the only choice is j2me cldc or cdc. if you try to use swing ,you will find no vendor will provide AGUI recently. Under windows mobile,we can use Mysaifu JVM. Sybian,oh, nothing. I pay attention to a developing jalimo(a project provide jvm support nokia maemo and openmoko) because I really need a pure JVM. so we hope we can pay more attention to create a jvm to let "Write once,run anywhere" come true. you all works is wonderful, GPL licence is great to improve java.

when we develope a program under a mobile phone，the only choice is j2me cldc or cdc. if you try to use swing ,you will find no vendor will provide AGUI recently. Under windows mobile,we can use Mysaifu JVM. Sybian,oh, nothing. I pay attention to a developing jalimo(a project provide jvm support nokia maemo and openmoko) because I really need a pure JVM. so we hope we can pay more attention to create a jvm to let "Write once,run anywhere" come true. you all works is wonderful, GPL licence is great to improve java.

I think people aren't so excited about it. Why would that be? One of the things I would like to see is a better support for dynamic language. Actually I would to see the JVM to become synonym to "a VM to many languages" the same way .Net was marketed since day 0. What's the point of having tens of implementations floating around if only a fraction of them are production ready, and many suffer from performance problems because the VM doesn't have the features those languages need? About keeping up Java competitive, perhaps a new languages with all the features you could dream of and without the tons of deprecated stuff from Java would be nice. Not "Java 2" because the version numbers from Sun are unbelievably idiotic, but some other name to show exactly what it is: a departure from Java.

I am a self-proclaimed Java bigot, I love the language. It is eligant, easy, but yet deceptively powerful. Exactly what a language should be. It is easy to teach, easy to learn, and produces applications that are rock solid. This addresses real-world concerns, quality and cost of development and maintenance. Languages are not the only culprits here to be sure, but java goes a long way to improve these aspects. I coded for over 20 years in C and then C++, and they are much more expensive to develop applications. The time to develop code is longer because of more complexity, the testing is longer, and so on. These languages make it too easy to make obscure, difficult to detect, problems that can raise their ugly heads in the field. So, when it all is said and done, I would agree with any suggestion to change the language to solve REAL problems that we are having in the field. If you look at java 5, the additions to the language do little or nothing to solve the real problems we are having. For example, generics are so unusable that they are a distraction and do not add any value. They are not available to reflection, so I cant use them to discover types at run time. They add clunky syntax, make the language harder to read, etc. What was the problem they were trying to solve, type-safe collections? Ok, thats a good idea, but really anybody that uses a heterogeneous collection should re-think their design anyway. I have NEVER found a reason to have mixed class types in the same collection, ever! So, if I have to cast, so be it. I'ld rather cast than use generics. We are using 1.5 on out current project, but have disabled the use of everything except annotations (which the jury is still out on). Guys, solve real problems and forget the syntactic wars. Listen to the people really building applications in the field and temper the language syntax and capabilities with that. We want 1.4 back!!!

Give the generics, XML and closure fanboyz the boot. No, wait. Before you kick them out force them to clean up the mess they created during the last decade. And don't forget the hundreds of thousands of open bug reports in the dreaded bugparade. In the future hire programmers who have created real-world applications before, not graduates and egg-heads who never wrote more than obscure demos and concept studies. And then keep them busy. I have the feeling that a lot of the stupid ideas that come up are because Sun's Java developers are bored. Next time someone comes up with a stupid idea force him or her to fix (not just close, really fix) ten bugs from the bugparade. When they complain give them ten more.

- Reified generics

Reified generics get my vote.

There's no way to extend an annotation right now. This would be handy, IMO.

inclusion of Java Fx scripts (compiled) in place of Java 2D code would be a nice feature !

I think 'named parameters' should be easy to do and is a nice feature to have!

I'm tired of using arrays of 1 object (and other types of holders), to return more than 1 result from java methods. Aren't you?

Make it so much easier to embed regular expression, SQL and other scripting languages into java. This would improve readability allot.