Link Details

I totally agree. Just because some feature makes some sense for 3 or 4 cases, there is no need to make the whole language more complicated and fuzzy.

Java's straightforward simplicity is one of its important productivity factors.

edit: a case where it makes some sense is Math.round, but I don't really mind casting every once in a while... I really don't.

You consider Java (a language that takes something like half a dozen lines for a simple Hello World program) is a straightforward and simple language?

This is scary stuff - simply for the fact that such major changes to the language are most likely going to be compile-time conveniences - much like generics which has no runtime type parameterisation, and has left holes in the implementation. I fear the same thing will happen to these other proposals. This breaks the common sense object technique of isolating responsibility - what ever happened to simple conditional statements? This and the ridiculous idea of operator overloading, closures etc need to be binned before they get any traction. Use Groovy if you want these benefits and leave the language alone.

Change for the sake of it will ruin java before anything else.

Maybe I'm not understanding this... but what possible reason is there to have multiple return values in Java? You can always create a class to handle the return type (this could be a very simple static inner class even). Given that all objects in Java are pass by reference, you can always do a call like someMethod(this), and then the someMethod() can set values in the this. You can always return an array of Object[] if you really can't think of some saner way to do it. I can't even see any cases where it makes sense, except in cases where the programmer is new to the language, or new to programming.

Oh I can think of plenty of places where you need to return multiple things. The most trivial example is where you have to return coordinates of something. Sure, all these cases can be handled by creating a new type or returning an Object array, but that is very verbose and heavyweight. x,y = foo() is much nicer and cleaner than FooResult result = foo(); x = result.getX(); y = result.getY();, or even worse returning an array and having to go through all sorts of checks on the array length and object types before you can finally do something with the results.

I don't know if this benefit would be enough to justify a change in the Java programming language (though I think it would be much more useful and easier than the var-args crap put into Java 5), but it certainly isn't a useless feature. It could do a lot of good, and in fact does in other languages.

THat's just lazy programming. Surely the existing way you illustrate shows intent more clearly, all we need is more junk code to have to make sense of - yeah, sure, you could comment, but thats a sure recipe for disaster. Remember, code is written once but read many times, and should be written to be read.

Java's strength (inho) is it's enforcement of expressiveness through the use of objects with clear responsibilities. If you want sugar, use Groovy/Jruby/Jython/[insert script here]. Java should stop trying to be everything to everyone, and just be itself. It's turning into a syntax whore.

First, being lazy is good. Generally speaking, keeping things simple and avoiding unnecessary verbose and complicated code results in better quality and code that is easier to understand.
Second, how do you mean the existing method shows intent more clearly? How does going through some completely unnecessary FooResult object that has nothing to do with the problem being modeled and only exists as a wrapper so both results of the foo method can be accessed make things more clear? Or do you mean its clearer to you because you are currently more used to it. That may be, but don't speak of that as some universal truth.
Third, what do you mean by sugar? Do you mean any feature that makes it easier to do something you could previously do? Then surely the entire Java programming language (or any high level language) consists of nothing but syntactic sugar, as you can do anything it does in plain old assembly code. But many of these pieces of "syntactic sugar" help developers model their problems more effectively, and that lends power to the programming language, and that makes them worthwhile.

Again, I'm not commenting on whether or not this particular feature has a place in the Java programming language, I agree much of what has been proposed is coming out of an identity crisis with Java wanting to be more like Python and Ruby. All I am saying is that just because you are unfamiliar with the convention does not make it complicated and unnecessary.

like I said, if you want to be lazy use groovy.