JDK 9: Pitfalls for the Unwary
azul.com
azul.com
Parameter class in question: http://download.java.net/java/jdk9/docs/api/java/beans/Prope...
> 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.
[0] http://download.java.net/java/jdk9/docs/api/java/beans/Prope...
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.
Mostly simplified calling of getters and setters, i.e. emulation of object properties.
> Why do you say almost every Java application depends on it?
- JAXB (XML binding) and Activation depend on it, so if you have direct or indirect dependency on JAXB or Activation you need java.beans.
- Spring depends on java.beans
"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."
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).
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.
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.
>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?
Because you're not supposed to slide head down on the first slippery slope you encounter...
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.
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?
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.
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.
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?