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.
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.
The list of possible items being discussed for Java SE 7 is here:
http://tech.puredanger.com/java7
And predictions for what will actually make it are here:
http://tech.puredanger.com/2008/08/02/java7-prediction-update/
I'd like the switch statement to support Strings, like in C#. Very useful feature in my opinion!
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.
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.
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.
Lots for things. I've just got into C# and there are a lot of features I like. The main one being (automatic) properties
Better support for embedding DSL's so that HQL, SQL, XML and other commonly used DSL can be statically verified and compiled.
Nested functions
Example:
public String myFunc(List<Sometihng>list)
{
boolean myUtilFunc(Something s) =
{
return s.toString != ""
}
for(Something s : list)
{
if(!myUtilFunc(s)
return s.toString
}
return null
}
I know this is API and not language, but they really need to redesign javax.crypto
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.
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.
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.
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....
but I luv it.
A "Money" class, that allows safe monetary calculations, much like one mentioned here.
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)
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.