4 ms·

One wonders what the point of working so hard for backwards compatibility is if they're just going to introduce breaking changes anyways.

peeters 9y ago
Really? Getting rid of a few rarely used and deprecated APIs (for the first time EVER) in a 21-year-old ecosystem is enough to discount the value of those 21 years of backwards compatibility?
- ivanbakel 9y ago
  Literally? Yes. I can understand maintaining backwards compatibility, and there's nothing wrong with it, but if the design commitee is willing go back on that now, why limit themselves to such tiny changes? The difference between these APIs existing and not existing is miniscule - what's the point of removing them at all? They've made a breaking build for no benefit, and it just smacks of laziness.
  - Others 9y ago
    There really is a reason though, and it's described in one of the sibling comments to your original comment. Why would you assume that the developers are just being "lazy"? Do you really think they would just delete the functions for no reason?
    - ivanbakel 9y ago
      > Do you really think they would just delete the functions for no reason? What part of my comment suggested that? I'm just asking why "backwards compatibility above all" is no longer being followed as a principle if it's cost the language so much in the first place? The developers have clearly worked hard in the past to introduce new features without breaking changes, but if the API is going the break, then you might as well go whole-hog - "we can't make this highly-anticipated new feature" seems like a great reason to justify a slew of other changes that Java sorely needs. It's a job half-done.
      - puritypurity 9y ago
        what would purity in this instance serve? this is the real world, we don't have to be all-or-nothing for the sake of it. tradeoffs are a legitimate path, and this is a terribly small one
        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 ago
        1) 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 ago
        Java 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?
  - malcolmgreaves 9y ago
    They limit to tiny changes to minimize the breaking API impact. This is a good idea.
  - coldtea 9y ago
    >Literally? Yes. I can understand maintaining backwards compatibility, and there's nothing wrong with it, but if the design commitee is willing go back on that now, why limit themselves to such tiny changes? Because doing something in extreme caution or in moderation is not the same as doing it all over the place. Backwards compatibility is not a binary between either "total compatibility all the time" or "let's remove anything we don't like anymore". >The difference between these APIs existing and not existing is minuscule - what's the point of removing them at all?They've made a breaking build for no benefit, and it just smacks of laziness. If you don't know what the reason is, the charitable thing to do is to assume that you're ignorant of it (which makes perfect sense: after all, you're not on the team, haven't followed their internal discussions, and don't know the codebase and its future plans like they do). Instead you opted for an explanation that requires them being idiots or lazy. Does that sound like a clever approach?

peeters 9y ago

Really? Getting rid of a few rarely used and deprecated APIs (for the first time EVER) in a 21-year-old ecosystem is enough to discount the value of those 21 years of backwards compatibility?

ivanbakel 9y ago
Literally? Yes. I can understand maintaining backwards compatibility, and there's nothing wrong with it, but if the design commitee is willing go back on that now, why limit themselves to such tiny changes? The difference between these APIs existing and not existing is miniscule - what's the point of removing them at all? They've made a breaking build for no benefit, and it just smacks of laziness.
- Others 9y ago
  There really is a reason though, and it's described in one of the sibling comments to your original comment. Why would you assume that the developers are just being "lazy"? Do you really think they would just delete the functions for no reason?
  - ivanbakel 9y ago
    > Do you really think they would just delete the functions for no reason? What part of my comment suggested that? I'm just asking why "backwards compatibility above all" is no longer being followed as a principle if it's cost the language so much in the first place? The developers have clearly worked hard in the past to introduce new features without breaking changes, but if the API is going the break, then you might as well go whole-hog - "we can't make this highly-anticipated new feature" seems like a great reason to justify a slew of other changes that Java sorely needs. It's a job half-done.
    - puritypurity 9y ago
      what would purity in this instance serve? this is the real world, we don't have to be all-or-nothing for the sake of it. tradeoffs are a legitimate path, and this is a terribly small one
      - 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 ago
        1) 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 ago
        Java 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?
- malcolmgreaves 9y ago
  They limit to tiny changes to minimize the breaking API impact. This is a good idea.
- coldtea 9y ago
  >Literally? Yes. I can understand maintaining backwards compatibility, and there's nothing wrong with it, but if the design commitee is willing go back on that now, why limit themselves to such tiny changes? Because doing something in extreme caution or in moderation is not the same as doing it all over the place. Backwards compatibility is not a binary between either "total compatibility all the time" or "let's remove anything we don't like anymore". >The difference between these APIs existing and not existing is minuscule - what's the point of removing them at all?They've made a breaking build for no benefit, and it just smacks of laziness. If you don't know what the reason is, the charitable thing to do is to assume that you're ignorant of it (which makes perfect sense: after all, you're not on the team, haven't followed their internal discussions, and don't know the codebase and its future plans like they do). Instead you opted for an explanation that requires them being idiots or lazy. Does that sound like a clever approach?