What Future Java Might Look Like

To me, most of the JVM languages have 2 similar problems with the "defaults": references are optional, rather than mandatory; objects are mutable, rather than immutable.

It's past time for a language that makes it's references mandatory unless you explicitly indicate "optional" / "maybe" or whatever. Slapping "Optional" on stuff when "mandatory" isn't enforced seems to just make things worse.

Similarly, classes/objects, methods, modules, packages should be side-effect free, unless there is a flag for mutation or other side effects.

We don't need Java 1.9, we need 2.0, with "breaking" (fixing) changes :-)

Scala shows some good ideas, but it doesn't go far enough. That, and I kind of liked Groovy, too, as I would like to be able to turn on and off strong/static type checking. (default on, but if you ask nicely...)

We are going OT here, but one last comment in this thread to clarify what I meant.

Putting a comment saying just "Just another vile article", without any thoughts about why it is vile, is just completely against the guidelines (from the points mentioned in my previous comment). Even if you agree with its content or not.

Also, I do not believe the guidelines encourage people to down-vote for disagreeing (or at-least from my understanding). It is just in our nature and the consequence of the fact, that there is a down-vote button. (I have never tried it, still under 500 karma.. :) )

Is the excessive virtual dispatch still really slowing down simple for loops in Scala? I thought Paul Phillips did a special-case fix for that. That's very disappointing if that's still a problem.

When I programmed in Scala, I felt like this sort of thing showed that priorities weren't quite right in the leadership somehow. For-loops are pretty basic and their performance is important - simple ones shouldn't have ever been slower than the equivalent Java ones IMO.

Another instance of misplaced priorities (again IMO), was the problem that you couldn't have local/temporary variables in your class constructors (see for example http://www.scala-lang.org/old/node/1198.html). Any values that you created inline in your class body (which is your primary constructor) could be used but would implicitly become fields in your class instances even if they were never used in any methods. Sure you can make factory methods in a companion object etc but should have to do that always? That's worse than Java and for no good reason! The "simplified" syntax of not having an explicit block representing scope for the actual constructor code, separate from member declarations, really bites in this case.

An example of this was the gcd value in Oderski's rational number class which is one of the first examples in his book. The gcd value is needed to initialize the numerator and denominator values, and you want to save it after it's first computed temporarily so you don't have to compute it twice. But naming it at all made it an actual instance field, not just a temporary in the constructor. So every Rational would be carrying around this significant extra storage unbeknownst even to a programmer who would have reviewed the source code, unless they are in the habit of examining javap output for everything or already knew to watch for this issue.

I don't know if that's been fixed or not. The very fact that this could stand for so long, and how implicit the whole thing was about something so fundamental (object construction!), really bothered me about Scala though.

Sounds great, really, but it didn't work once when I tried to put up well-reasoned arguments. Why would I follow guidelines any further when everyone seems to interpret them as they well damn please? So, basically 'upvote' is for the popular opinion, and it doesn't matter if it's well reasoned or not. And the 'downvote' is for preventing flame wars by suppressing the unpopular opinion, no matter if well reasoned or not? I'm very confused.

Some languages have official versions than you need to declare right at the start. As in specification version, not implementation versions.