3 ms·
It would maintain actual backwards compatibility, since that is the hill Java has been dying on for 8 minor versions. This tradeoff is between two principles w
by ivanbakel 9y ago
It would maintain actual backwards compatibility, since that is the hill Java has been dying on for 8 minor versions.
This tradeoff is between two principles which really shouldn't be compromised on - there is no halfway for backwards compatibility where you can only break some APIs and get away with it. If the designers are willing to sacrifice rarely-used parts of the language to make way for new features, then there are plenty of other places that are begging for a nip and tuck as well. They don't have to overhaul the language completely, but it's not like there aren't areas in need of improvement where change wouldn't affect 99.999% of existing code, as is the case with these APIs. Abandoning purity for this little of a modification is practically an insult to all the people who have demanded change in the past.
This has brought about what should be Java 2.0 (or however you would represent that in their strange version counting system) by right, and it's been botched.
- malcolmgreaves 9y ago1) It is a major revision: it's called Java 9. 2) This is a very mature, professional, thoughtful, low impact way to break backwards compatibility. It is also a break for a very good idea: core library modularization. 3) Emotionally, it sounds like you've staked out this hill that you're set on dying upon. I think you're prepping yourself for some unnecessary suffering. Your words sound incredibly binary. Real world engineering is about finding balance: all solutions are trade-offs because we're optimizing many variables.
- ivanbakel 9y agoJava numbers work differently - presumably to build up the hype of new releases. Java version x is in fact version 1.x, a minor revision from Java 1.0. This started with Java 5, and is still visible if you do `java version` today since it correctly displays the 1.x version - in my case, 1.8. >It is also a break for a very good idea: core library modularization. I understand perfectly well the justification they have for breaking backwards compatibility, and that's not the point - the question is why this justification is now accepted above the principle of backwards compatibility in such a way that they've permitted no other changes which would have a similar impact on users. The designers have made a major change - why go halfway?
- coldtea 9y ago>The designers have made a major change - why go halfway? Because you're not supposed to slide head down on the first slippery slope you encounter...
- imtringued 9y ago> there is no halfway for backwards compatibility where you can only break some APIs and get away with it. There is. You're assuming that breaking backwards compatibility only has a fixed cost and that therefore you should try to break as many things as possible because it costs "nothing". You're forgetting that migrating from an old version to a new version costs time and money, the more you break the higher the cost and risk of a migration. If you break too many things at once like python or angular did you end up with a split community.
- ivanbakel 9y ago>You're assuming that breaking backwards compatibility only has a fixed cost and that therefore you should try to break as many things as possible because it costs "nothing". Of course not. The point is more understanding where the Python2/3 style boundary lies and what changes which might benefit the language are on each side of it. I doubt this is the least impactful breaking change they could have made, and there are others of a similar size which haven't been included - why?