3 ms·

I wish the Java Language committee would stop wasting time and just blatantly copy C# already. The answer is "var", and it was always var, and it will always be

I wish the Java Language committee would stop wasting time and just blatantly copy C# already. The answer is "var", and it was always var, and it will always be var. But they're dragging their feet because they want to be different from C# out of some misplaced spite (Which is how the last debacle with the lambda notation happened). Just do what C# did. Then rinse lather and repeat for Generics, Async/Await, Auto-Properties, and Extension methods. And all the features I don't know about in C# 6 because I've been stuck in the dreary land of Java since before that came out.

exabrial 11y ago
well said
kodablah 11y ago
I disagree. The answer is not just "var" because you have now completely dismissed local variable immutability (something C# does not have). Did you read the link you are responding to? I am also not sure why you believe they want to be different "out of some misplaced spite"...any source for these claims? Finally, Java needs to be easy to parse and backwards compatible, and after all it does have many runtimes by other companies. What if I had a class named "var" (which does happen in auto-generated code)? These things need to be discussed out in the open (something C# did not do during those older decisions). As for the other features you mention, there are many reasons why they are different and many people can argue in favor of Java's approach (e.g. generic type erasure is backwards compatible as opposed reification, async/await are library problems not language ones, etc). They are different languages, they take different approaches to changes, and I believe it is unfair to hand-wavingly dismiss it as "wasting time".
- dfkf 11y ago
  > The answer is not just "var" because you have now completely dismissed local variable immutability (something C# does not have) It is something that C# does have. It just doesn't allow immutable variables to be implicitly typed, i.e. you can't write something like "const var x = 0;" This lack of let or val in C# is a reminder that "var" was introduced in the language not just to reduce visual clutter, but to support anonymous types, which were in turn introduced to greatly enhance LINQ experience allowing for such nifty feature as "let" clauses in query expressions...
- landryraccoon 11y ago
  `final var` handles the immutability case. Any of the potential keywords `let`, `val`, `var` could potentially conflict with auto generated code. This would be a breaking change with those generators.
jsmith0295 11y ago
I don't think they can do it with Generics because of an architectural problem. And while var is probably the best approach to having type inference, I don't even think that's a particularly important feature if you're comparing Java to C#. Having async/await and async IO basically be the default as it is in C# now would be huge. Trying to make things asynchronous in most Java web projects is considerably more difficult than it ought to be. Play framework isn't bad, but given that it's a Scala framework, there's a different set of issues when you're trying to use it from Java.
- deanCommie 11y ago
  It's a backwards-compatibility problem. I say, make the breaking changes. The Java philosophy is diametrically opposed to this.

exabrial 11y ago

well said

kodablah 11y ago

I disagree. The answer is not just "var" because you have now completely dismissed local variable immutability (something C# does not have). Did you read the link you are responding to? I am also not sure why you believe they want to be different "out of some misplaced spite"...any source for these claims? Finally, Java needs to be easy to parse and backwards compatible, and after all it does have many runtimes by other companies. What if I had a class named "var" (which does happen in auto-generated code)? These things need to be discussed out in the open (something C# did not do during those older decisions). As for the other features you mention, there are many reasons why they are different and many people can argue in favor of Java's approach (e.g. generic type erasure is backwards compatible as opposed reification, async/await are library problems not language ones, etc). They are different languages, they take different approaches to changes, and I believe it is unfair to hand-wavingly dismiss it as "wasting time".

dfkf 11y ago
> The answer is not just "var" because you have now completely dismissed local variable immutability (something C# does not have) It is something that C# does have. It just doesn't allow immutable variables to be implicitly typed, i.e. you can't write something like "const var x = 0;" This lack of let or val in C# is a reminder that "var" was introduced in the language not just to reduce visual clutter, but to support anonymous types, which were in turn introduced to greatly enhance LINQ experience allowing for such nifty feature as "let" clauses in query expressions...
landryraccoon 11y ago
`final var` handles the immutability case. Any of the potential keywords `let`, `val`, `var` could potentially conflict with auto generated code. This would be a breaking change with those generators.

jsmith0295 11y ago

I don't think they can do it with Generics because of an architectural problem. And while var is probably the best approach to having type inference, I don't even think that's a particularly important feature if you're comparing Java to C#. Having async/await and async IO basically be the default as it is in C# now would be huge. Trying to make things asynchronous in most Java web projects is considerably more difficult than it ought to be. Play framework isn't bad, but given that it's a Scala framework, there's a different set of issues when you're trying to use it from Java.

deanCommie 11y ago
It's a backwards-compatibility problem. I say, make the breaking changes. The Java philosophy is diametrically opposed to this.