4 ms·

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 b

by 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?
        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.
  - unclebucknasty 9y ago
    It is small, and I think it's impressive that these are among the first API removals in 21+ years. OTOH, there may be a general fatigue setting in with developers these days. For instance, consider what Google did to its Angular 1.x adherents. Maybe the fatigue I sense emanates partly from this whole mantra of "move fast and break things", along with this explosion of frameworks, libs, projects, tools and tech in general to keep up with. Combine this with agile and continuous integration, etc. and you get a recipe for exhaustion. It's hard being a dev these days. Productivity is at an all-time high in our industry, but I would wager that burnout will soon be a significant issue that will require change. There is an implicit assumption in tech that devs are more machine-like than human, with endless sprints and ever changing tech. If you follow that, burnout is more a matter of when than if. EDIT: To clarify, I am not saying burnout is the case with the author of the GP comment. But, I've experienced this kind of impatience with even "reasonable" changes due to pure change fatigue. I know others have as well. In fact, for anyone who has yet to, I'd say just give it time.
- clhodapp 9y ago
  I think that you are suffering way more downvotes than you deserve because your actual point (which becomes clear in this comment) is really good but your original comment is a little too vague and your tone is somewhat abrasive. But I do think it's true: up until very recently, Java features that break compatibility in any way whatsoever have been rejected out of hand simply on that basis. If the standard had been a this loose in the past, we might have a better Java now. That said, I feel like this change really just means that it's time to start proposing changes that give major benefits at the cost of minor compatibility breaks, rather than trying to resist the change of standards.

by Others 9y ago

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?
      - 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.
- unclebucknasty 9y ago
  It is small, and I think it's impressive that these are among the first API removals in 21+ years. OTOH, there may be a general fatigue setting in with developers these days. For instance, consider what Google did to its Angular 1.x adherents. Maybe the fatigue I sense emanates partly from this whole mantra of "move fast and break things", along with this explosion of frameworks, libs, projects, tools and tech in general to keep up with. Combine this with agile and continuous integration, etc. and you get a recipe for exhaustion. It's hard being a dev these days. Productivity is at an all-time high in our industry, but I would wager that burnout will soon be a significant issue that will require change. There is an implicit assumption in tech that devs are more machine-like than human, with endless sprints and ever changing tech. If you follow that, burnout is more a matter of when than if. EDIT: To clarify, I am not saying burnout is the case with the author of the GP comment. But, I've experienced this kind of impatience with even "reasonable" changes due to pure change fatigue. I know others have as well. In fact, for anyone who has yet to, I'd say just give it time.
clhodapp 9y ago
I think that you are suffering way more downvotes than you deserve because your actual point (which becomes clear in this comment) is really good but your original comment is a little too vague and your tone is somewhat abrasive. But I do think it's true: up until very recently, Java features that break compatibility in any way whatsoever have been rejected out of hand simply on that basis. If the standard had been a this loose in the past, we might have a better Java now. That said, I feel like this change really just means that it's time to start proposing changes that give major benefits at the cost of minor compatibility breaks, rather than trying to resist the change of standards.