This is a pretty unoriginal question! Where do you stand on the Closures Proposal? What else would you want to see?

For me it has to be a new decimal type which is really a BigDecimal but allows for standard math operations using +, -, x, / etc.

+6  A: 

The list of possible items being discussed for Java SE 7 is here:


And predictions for what will actually make it are here:


Alex Miller
+5  A: 

I'd like the switch statement to support Strings, like in C#. Very useful feature in my opinion!

I just saw that that's in the list above, nice!

I made a list previously.

I too would like operators for BigDecimals. I'd also like option types (the ability to have the compiler enforce what is allowed to be null and what isn't, eliminating most NPEs).

I'm not convinced on the full closures proposal. The CICE proposal is OK, except for how it overloads the "public" keyword.

Dan Dyer
I think the motivation of CICE is to propose a goal. The syntax is incidental and up for grabs, but irrelevant until we know where we want to go.
Tom Hawtin - tackline
+3  A: 

A bit more conciseness in the syntax, with a bit of target type inference and (library defined) defaults for very common cases.

For instance:

Map<String,String> map = new java.util.HashMap<String,String>();

should become something like:

Map<String,String> map = new;

Similar for simple anonymous inner classes.

Tom Hawtin - tackline
What happens then when you want to instantiate a subclass, just define it as before, or could there be some other clever device used?Like the idea :-)
= new what exactly? A Map is an interface class. I see what you mean though...but it would only work for actual classes!
I'd prefer it C++09 way. Someting like "auto map = new std::map<std::String, std::string>();"
Alex B
Richie_W, if I say I want a new Map, way more than 90% of the time HashMap is the appropriate implementation. Therefore it is sensible to default Map construction to HashMap.
Tom Hawtin - tackline
Checker, for me that loses too much information while not narrowing down the type enough. If the value came from a method I would not be able tell *locally* what they type was. Also I want the Map type, without any of the extras of HashMap.
Tom Hawtin - tackline
C# has something like auto to support LINQ. LINQ uses anonmymous types (as in interface not class) in order to concisely use a relational model. A relatively obscure language feature isn't a great reason to upset the rest of the core language.
Tom Hawtin - tackline
how about "var map = new java.util.HashMap<String,String>();" ;)
Anthony, that's what auto does in C++0x (as Checkers comment).
Tom Hawtin - tackline
+1  A: 

Appart from closures, I'd really like some simple type inference to keep the hassle of using generics down, and language support for composite oriented programming.

Christian Vest Hansen

Lots for things. I've just got into C# and there are a lot of features I like. The main one being (automatic) properties

+2  A: 

Better support for embedding DSL's so that HQL, SQL, XML and other commonly used DSL can be statically verified and compiled.

John Nilsson
+3  A: 

Reified generics

John Nilsson

Nested functions


public String myFunc(List<Sometihng>list)

   boolean myUtilFunc(Something s) =
      return s.toString != ""

   for(Something s : list)
       return  s.toString
   return null
John Nilsson

I know this is API and not language, but they really need to redesign javax.crypto

+1  A: 

As little as possible.

Syntax sugar is very nice, but it also makes the language more complicated for new developers, and makes maintenance more difficult as there are more ways to express the same logic.

I strongly prefer a rich ecosystem of third-party API's (think Apache Commons and the like) and a website like this where you can ask what to use.


I'd really like to have friend classes. This would give a way to cut down greatly on mindless getters and setters, while adhering to SRP and not resulting in package explosion.


const methods

Andrew Medico

I'd like to see them quit changing the language/APIs for a while and figure out what's needed after the community has had a bit of time to work it out, develop their own things, then standardise.

+2  A: 

I would like support of closures (with out an ugly syntax if possible)..

I like what is proposed by Tom, that would be great


Updated or new Swing components.

The results from open-source projects like SwingLabs should be rolled into Java - for example, JXTable, JXLoginPane.

Swing is also missing a lot of modern UI idioms, like an Outlook Bar.


True property support in the language (similar to MyClass.class for class support, but MyClass.myProperty.property type support - as well as automatic handling of property change support).

This is critical for properly implementing binding - the current lack of support is a major problem (it's not just syntactic sugar to get rid of having to type out getters and setters).

Groovy's got this one nailed, and I really hope that Java gets it.

Kevin Day

C# style properties.

For those of us who don't know C# - could you expand?
+2  A: 

class import alias - all other languages has got it (event php) and only Java remains without this feature - for big projects its a huge problem. Its quite simple, I don't understand why it was not added in 1.5. It would be really nice to write something like that:

import java.swing.Popup as SwingPopup;
import java.awt.Popup as AWTPopup;

Hope that this will be added some day....

+2  A: 
  1. Rename java process (every processes that implements by java language will show in processes list are java or javaw), It's hard for specify process.
  2. Support Daemon in linux or Windows Service, many times java need to run is backend process.

but I luv it.

Fuangwith S.

A "Money" class, that allows safe monetary calculations, much like one mentioned here.

Nice Library class, but (please) not in the standard API that is engraved in Stone until infinity
+2  A: 

Java performance is now quite good - honestly at this point I'd even trade 10-15% speed for reduced memory if it were needed. This is a huge hurdle for desktop app adoption (Notes 8 regularly consumes 450MB+ memory with casual usage - 'nuf said). Biggest needs:

user defined value types (like C# struct) - to allow 'inline' class memory usage instead of via reference. Reduces references which are really adding up memory-wise with move to 64-bit.

Stack allocation via escape analysis - to reduce heap usage and GC

MVM - to help pool free heap space among all running programs

Other niceties: unsigned primitives tuples reified generics (should have been done right from the beginning) syntactic sugar to reduce redundant typing (java is very verbose)

What is "unsigned primitives tuples reified generics"? I'm guessing there are three separate terms there, but it's hard to tell just by looking.
Michael Myers

I would like the restrictions on calling this and super constructors loosened to allow for the declaration of local variables and the ability to call static methods and methods on objects other than "this".

The current restriction that calls to super or this constructors must be the first statement is often inconvenient and often leads to very torturous code if parameters to the this/super need to be synthesized or manipulated before it can be called.


BGGA closures and reified generics.


Smaller memory footprint.

John Wright
+1  A: 

Mixins, closures and properties.