The author has been on the road talking about this subject for a while now.
What I recall from him was that those 6 methods introduce dependencies between some of the modules just to access one type definition. For instance, one of the methods means that a big block of nominally 'server side' code would need one type definition from the UI library. For a function nobody uses anymore (relating to Beans configuration).
"LogManager has a highly undesirable dependency on java.beans classes that is problematic for modules. It is likely that we will need to remove these methods in Java SE 9 (assuming approvals, etc.). In preparation for this it will be necessary to deprecate these methods in Java SE 8 (again, pending approvals) so that developers/users of these methods know they are going away."
If I recall correctly, those methods had dependencies that crossed the module boundaries in unpleasant ways, so that keeping them would mess up the module boundaries.
Why java.beans.PropertyChangeListener is from Swing UI? Looks like part of Java Bean standard which is supposed to be just high-level reflection API. System thing, nothing wrong to depend on it.
> Why java.beans.PropertyChangeListener is from Swing UI?
Well the java.beans package and Swing UI are in the same module. Why? Because java.beans depends on AWT. Why? Because of interfaces like this https://docs.oracle.com/javase/8/docs/api/java/beans/BeanInf... Could AWT und Swing still be split into different modules? Maybe. Does that mean that almost every Java application will have to deploy two UI toolkits, PLaFs and sound even if it's just a web service? Yes because almost every Java application at least indirectly depends on java.beans. Does Oracle or Java 9 / Jigsaw marketing care? No.
It's hard to imagine an application without getters and setters. Now if you want to read/write those beans in a generic way, you need to use reflection. And correct approach is to use java.beans classes instead of rolling your own low-level solution.
> A "PropertyChange" event gets fired whenever a bean changes a "bound" property. You can register a PropertyChangeListener with a source bean so as to be notified of any bound property updates.
I believe the idea of a "bound" property is a Swing UI concept. That is, it implements a binding from the bean to a UI element. If you look at the implementing class list, it's all Swing UI components that implement it.
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?
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.
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?
> 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.
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.
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
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.
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.
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.
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?
> 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.
>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?
>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.
