
JDK 9: Pitfalls for the Unwary - Randgalt
https://www.azul.com/jdk-9-pitfalls-for-the-unwary/
======
grabcocque
Curious as to why, out of all the hundreds of deprecated calls in the JDK, it
was those six methods that got removed.

~~~
elygre
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.

~~~
Ironlink
Correct. The parameter of those methods use(d) a class from the Swing desktop
UI toolkit, and logging can't depend on that.

Parameter class in question:
[http://download.java.net/java/jdk9/docs/api/java/beans/Prope...](http://download.java.net/java/jdk9/docs/api/java/beans/PropertyChangeListener.html)

~~~
vbezhenar
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.

~~~
needusername
> 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...](https://docs.oracle.com/javase/8/docs/api/java/beans/BeanInfo.html)
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.

~~~
lmm
What's the use case for java.beans in a non-GUI application? Why do you say
almost every Java application depends on it?

~~~
vbezhenar
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.

------
evacchi
if you are interested, these are the slides of the talk referenced in the
article [https://www.slideshare.net/SimonRitter/55-new-features-in-
jd...](https://www.slideshare.net/SimonRitter/55-new-features-in-jdk-9)

------
m0shen
Cached version:
[https://webcache.googleusercontent.com/search?q=cache:Pkk2OK...](https://webcache.googleusercontent.com/search?q=cache:Pkk2OKf6IgYJ:https://www.azul.com/jdk-9-pitfalls-
for-the-unwary/)

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

~~~
peeters
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
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
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
> 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
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
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
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
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
> _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...

