A flag day on a bytecode format is "hating users"? It's a Python 3 split? Come on now. Heck, I can't come up with anything (and I've been thinking about this a lot for a few weeks, as I spend more personal time in C# and getting stuff done quickly that's kind of a pain in Java) that'd prevent automatic translation of pre-flag bytecode to an equivalent matching the old code's intent. If a jar has a pre-flag bytecode format, then rewrite to treat those parameters at runtime as T => Object and transparently box value types that are supplied for T. The pre-flag jar still contains the necessary information for the compiler to throw a rod if generic constraints are violated. (You could even experiment with more restrictive runtime constraints, but I haven't thought through the implications thereof.)
But you know? If it takes laggards three years instead of the usual two to jump from Java 9 to Java 10, I don't care. I shouldn't care, because I'm not them. Oracle might. They can do that. But Oracle doesn't want my business if they do to my detriment, and the more time I spend outside the JVM the more annoyed I am by their self-imposed limitations. Microsoft seems like they wouldn't mind my business, though, which is faintly astonishing. I'm happy giving it to them if they're going to provide a better product. (I'm reserving judgment until we see their Linux and OS X ports of their CLR, but I'm high on it.)
And if you're seriously going to get riled up about "laggards", I hope you never take an economics class, because they think words mean things and I do too.
Yes, you're probably right that they don't care about your business. Oracle's actual customers are large businesses running hundreds of millions of lines of code and they probably don't understand all of it. They probably care a lot about preserving their existing investment. If they decide to put off upgrading to the latest VM, Oracle can't sell them stuff.
The point here is to have some empathy. There are other people in the world with different priorities. You can't say whether a technical decision is good or bad without understanding what they're trying to do.
>Yes, you're probably right that they don't care about your business. Oracle's actual customers are large businesses running hundreds of millions of lines of code and they probably don't understand all of it.
That was true for SGI, HP, DEC, SUN etc at some point too. See how the ended when they didn't adapt?
SUN could still be alive and be pioneering all this cloud and web programming in 2014...
They could have created something like Heroku (or lower level like AWS), they could have added some flexible Rubu/Python Django/Rails like option for the JVM (instead relying on third party ho-hum small attempts). They could have pioneered the big data space.
Instead the insisted on Java for everything, and kept it as stale as they could. This is were it got them...
They did try. Sun had all sorts of innovative projects that didn't work out (such as JavaFX), but they've been forgotten. Java on the server is what remains. It may not be flashy, but it's a survivor (still around even after Sun is dead) and it's likely to last as long as Fortran and COBOL.
It's only in the early adopter community that survival doesn't seem to count for anything.
I'm stating what I want in my tools. I've been very clear that, while I am entirely convinced that they are wrong and will suffer for it, they can do whatever the hell they want and I'll respond in kind. Where is the lack of empathy here?
And, as coldtea notes, lashing themselves to boat anchors hasn't done Java, or Java's owners, much good throughout its history.
There's nothing wrong with saying what you want in your tools. But it's rather weird (though a common sort of move on the Internet) to follow that up by saying that the Java maintainers are making the wrong decision and therefore they are courting disaster. Why draw that conclusion? I'm assuming you're not so much of an egotist to think your desires are that important?
A more reasonable conclusion would be that what I want, or what you want, and what's good for Java have little to do with each other. You should use another language that fits better (since you're fortunate to be free to switch), and Java will probably be fine.
Because the history of tech and business is "stagnation kills"? I cannot envision a mindset where "we exist because we can't be excised from decades-old businesses" is a desirable place for Java and the JVM to be. If Oracle thinks they can grow the JVM off of stagnant customers who can't afford to move, they're nuts. If they think forward-looking customers are going to settle when competitors are getting better, faster around them, they're also nuts.
I want healthy competition, and so yeah, my jimmies are rustled when they're making bad decisions because even if I exit the JVM ecosystem for my own purposes, one of the major players being too afraid of their own customers to fix a central rot of their product is bad for us all.
The issue is whether it's actually "central rot" or not. That's not an objective statement. It depends on your point of view. If you're putting your customers first, you have to look at if from their point of view.
Startup thinking is that you never have enough users, so you have to appeal to a lot of new users or you die. Companies selling consumer products are similar - you have to convince a lot of new customers every year. But that's not where Java is. It's going to last as long as COBOL and Fortran and C++. Making small, careful changes and paying attention to migration costs so you don't leave people behind will work fine.
For a business with many large, satisfied, long term customers, the software can survive as long as they're willing to pay maintenance. The userbase may slowly fade, but the customers they have aren't going to be too quick to move if things are working. If anything, disruptive changes will make them move away faster since they're forced to do something, so why not do a rewrite that's bigger impact?
Making migration easy is not "stagnant", it's good customer service, allowing old code to be modernized a bit. If you know the real cost of upgrades, a more dramatic change may not be worth it.
And for those of us doing new projects, well, there are a lot of other shiny toys to play with. We don't have to disrupt everything.
But you know? If it takes laggards three years instead of the usual two to jump from Java 9 to Java 10, I don't care. I shouldn't care, because I'm not them. Oracle might. They can do that. But Oracle doesn't want my business if they do to my detriment, and the more time I spend outside the JVM the more annoyed I am by their self-imposed limitations. Microsoft seems like they wouldn't mind my business, though, which is faintly astonishing. I'm happy giving it to them if they're going to provide a better product. (I'm reserving judgment until we see their Linux and OS X ports of their CLR, but I'm high on it.)
And if you're seriously going to get riled up about "laggards", I hope you never take an economics class, because they think words mean things and I do too.