For those who haven't been paying attention, there is a new project from Sun to attract proposals for small language changes to JDK7. Even in the first day of open calls for proposals, the entries have been very interesting:
(For those of you following the various Closures proposals: Closures don't count as a small change, and are therefore not in scope for this JSR.)
ETA: The "use Scala instead" and "where is BGGA?" comments have been made, so please read the comments and feedback before reiterating them.
- Strings in Switch, a proposal from Joe Darcy to be able to use Strings in switch statements.
- Automated Resource Blocks, a proposal from Josh Bloch to be able to say things like:
instead of:
try (BufferedReader br = new BufferedReader(new FileReader(path)) {
return br.readLine();
}
based on having BufferedReader implement a Disposable interface.
BufferedReader br = new BufferedReader(new FileReader(path));
try {
return br.readLine();
} finally {
br.close();
} - Block expressions, a proposal from Neal Gafter to be allow things like:
double pi2 = (double pi = Math.PI ; pi*pi)**; // pi squared*
Basically, the principle here is that the (parenthesis-delimited) block would return a value. - Exception handling improvements, another proposal from Neal Gafter to allow things like:
try {
doWork(file);
} catch (final IOException | SQLException ex) {
logger.log(ex);
throw ex;
} - Improved Type Inference, a proposal from me (although I can't claim credit for the idea) to be able to replace things like this:
with things like this:Map<String, List<String>> anagrams = new HashMap<String, List<String>>();
Map<String, List<String>> anagrams = new HashMap<>();
- A new syntax for wildcard variance, again from the prolific Neal Gafter, allowing the user to replace "? extends" with "out" and "? super" with "in". (Can you tell that Neal's been working on C#?)
(For those of you following the various Closures proposals: Closures don't count as a small change, and are therefore not in scope for this JSR.)
ETA: The "use Scala instead" and "where is BGGA?" comments have been made, so please read the comments and feedback before reiterating them.
Comments
Do you have any details/links for the declaration site variance proposal? It's not talked about much (the only reference I found was from last year QCon presentation), yet it would be a "big deal" feature.
Yardena.
@yardea - I don't have information on it, but I suspect that would fall under the heading of "large language changes".
Instead of adding Automated Resource Blocks and new Foreach statements for Maps and things like this, they should simply add BGGA closures! With BGGA you get all this stuff for free!
as far as I understand Neal's proposal is "just" about introducing an improved syntax for wildcards, but it's still all use-site variance. I don't think introducing declaration-site variance as in Scala or C# 4.0 (if I'm not mistaken) is going to happen. I like Scala's approach better, but it sounds like a major change if applied to Java ...
Cheers, Martin
this is what I think about these things:
Exception handling improvements would be great and very helpful for some algorithms, no doubts about this, I love it.
Improved Type Inference would be helpful for reading code, no doubts about this, I love it too.
Strings in Switch, maybe useful in some cases but not much and newbies are in risk of misusing it.
Automated Resource Blocks, it's very useful in order to reduce boilerplate, but again newbies are in risk of forgetting to free resources.
Block expressions, at this moment I don't like it, please not in java7.
A new syntax for wildcard variance, at this moment I prefer the current sintaxis, I can wait until java9 or even more :-)
I hope java will change slow and safe.
>Automated Resource Blocks, it's very useful in order to reduce boilerplate, but again newbies are in risk of forgetting to free resources.
the whole point of the ARM lang. change is to eliminate the "risk of forgetting to free resources". when using the new syntax you won't need to close the resource - that will be done for you automatically (hence the name).
1.) the resource block
2.) multi catch
3.) new syntax for wildcards
My only concern with the resource block is that it could be implemented with closures - if we get them in java 8 that is. Other languages such as C# provide a "using" block and closures. I am not sure if they had their time they would only go with one approach and not both.
var anagrams = new HashMap<String, List<String>>();
Whether Martin wants people to switch to Scala in droves is immaterial--people are switching from Java and Sun appears to have no credible vision for how to keep us around.
JavaFX and Fortress are both pretty nice languages, but neither of them is making any attempt at the general-purpose programming language market.
I realize Sun is in dire straits and can't afford to spread themselves too thin, but their current underinvestment in programming language innovation is not going to help the situation.
http://oreilly.com/catalog/9780596527754/
I'm with others that Scala/C# 4 style definition site variance would be even nicer, but it's a much larger language change than would be in scope for this project. Note, for the record, Scala can also do usage site variance. Scalars just do it a lot less.
I'm pretty sympathetic with the WBJUS crowd. Scala's approach is to unify and generalize things rather than have special cases. For instance, two proposals (strings in switch statements and multiple exception type matching) are unified in the single concept of pattern matching in Scala. And a third thing that is often suggested for Java, multiple value return, is also related to pattern matching in Scala. So one rich concept neatly covers what seems to be 3 very different things, plus a bunch more.
Similarly ARM, as @gruenewa and @sboulay mentioned, doesn't need language syntax if you have lamdbas - which in fact neatly cover things like what Java calls "enhanced for-loop". So again, many special language features can be covered by one general feature.
Finally, Scala is a very expression oriented language. So expressions in blocks aren't a special thing like @franci sees and fears. They're common and ordinary across most of the language.
One quibble with Jeremy's response to the WBJUS comment. Yes, there is a large existing codebase and ecosystem of tools for Java. But the codebase issue is covered just fine with Scala - mixed Scala/Java pretty much Just Works whether it's Java libraries or Java source. The tools side of the equation is more of an issue, true. Still, a great many of the tools work with byte code and so work with Scala. That said, of course there are plenty of tools (e.g. IDEs) that depend on Java syntax that Scala really can't take advantage of. The situation there is improving rapidly but Java is still far in the lead on that front. That and "developer base" are, IMHO, the only two real responses to @Alex's WBJUS. And developer base is surprisingly easy to fix - it's pretty trivial easy to teach Java devs how to "write Java in Scala" and then gradually teach them how to really use Scala.
ARM block: Yes! The example of what we have to write today doesn't even tell the whole story. The fully proper code to write is
BufferedReader = null;
try {
br = new BufferedReader(new FileReader(path));
return br.readLine();
} finally {
if (br != null) {
try { br.close(); }
catch(IOException ignore) {}
}
}
ARMs would hide this mess. The full BGGA approach is too complicated.
Block expressions: Does not meet the power/weight threshold for new features.
Exception handling improvement: Sure, but I'm not crazy about the pipe syntax.
Improved type inference: yes!
New syntax for wildcard variance: does not meet power/weight threshold.
A keyword would be more concise:
transient BufferedReader = null;
Cheers,
Nick.
try (ResourceClass r1 = new ResourceClass();
ResourceClass2 r2 = new ResourceClass2()
// and so on...
) {
// do stuff with r1 and r2...
}
Basically, what I want for xmas is to be able to pretend that I have locals with destructors. I'm not ashamed to admit that. ;-)
There is too much boilerplate try/catching in Java code. Adding a keyword would really collapse things down.
Scoping could be done manually if needed.
Cheers,
Nick.
auto Resource r = new Resource();
The r.dispose() method would get reclaimed at the end of the scope. But he didn't like it very much, and I understand his reasons.
And thanks for the link - an interesting read. Professional as always, Josh was nice enough to mention this alternative in his proposal:
"*Modifier in place of block* - An alterative to a block construct is a new modifier that could be added to any local variable declaration for a variable that extends Disposable. This is more flexible and less verbose, but more dissimilar to existing Java language constructs."
I understand his concern, but don't agree.
Cheers,
Nick.
Function SomeFunName (BufferedReader br) {
return br.readLine();
[ try :
//Error handling code
]
}
- Logically Genius
I see it every day, some neglected programmers do not free resources (and don't care about it) in languages that need it (like delphi).
That's not my case, I'm a pedantic programmer :-)
Do you think Nullable annotations is a enhancement small enough to make i into JDK7?
Sample example could be
public void doFoo(@Nullable Bar bar) {
.....
}
This would mean that bar instance can potentially be null.
Similarly you could configure a method to return non null values by using @NotNull annotations or something like that.
If IntelliJ idea has it, why can't JDK 7? It will reduce repititive code such as
str = str != null && str.length() > 0 : str : "";
Please nuke #$@! \u escape sequences, at least in comments. Comments? Really? Jeebus I hate the fact that comments can be interpreted as anything other than straight up literal characters.
\u is OK in String literals. Anywhere else, it's just a bad idea waiting to trip up the unwary.
I'm seriously doubting whether we'll see a JDK8 with closures, and even if we will in 2012 or so, by then other languages will have moved even further ahead. No wonder Neal Gafter moved on.