6 ms·

JDK 9: Pitfalls for the Unwary

106 points by Randgalt 9y ago

m0shen 9y ago
Cached version: https://webcache.googleusercontent.com/search?q=cache:Pkk2OKf6IgYJ:https://www.azul.com/jdk-9-pitfalls-for-the-unwary/ https://webcache.googleusercontent.com/search?q=cache:Pkk2OK...
grabcocque 9y ago
Curious as to why, out of all the hundreds of deprecated calls in the JDK, it was those six methods that got removed.
- elygre 9y ago
  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 9y ago
    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/PropertyChangeListener.html http://download.java.net/java/jdk9/docs/api/java/beans/Prope...
    - vbezhenar 9y ago
      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.
      - jdmichal 9y ago
        From the JavaDocs for PropertyChangeListener [0]: > 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/PropertyChangeListener.html http://download.java.net/java/jdk9/docs/api/java/beans/Prope...
      - needusername 9y ago
        > 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/BeanInfo.html 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.
        lmm 9y ago
        What's the use case for java.beans in a non-GUI application? Why do you say almost every Java application depends on it?
        needusername 9y ago
        > What's the use case for java.beans in a non-GUI application? 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
        vbezhenar 9y ago
        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.
- Someone 9y ago
  https://bugs.openjdk.java.net/browse/JDK-7192274 https://bugs.openjdk.java.net/browse/JDK-7192274: "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."
- hinkley 9y ago
  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).
ivanbakel 9y ago
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.
evacchi 9y ago
if you are interested, these are the slides of the talk referenced in the article https://www.slideshare.net/SimonRitter/55-new-features-in-jdk-9 https://www.slideshare.net/SimonRitter/55-new-features-in-jd...

106 points by Randgalt 9y ago

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

grabcocque 9y ago

Curious as to why, out of all the hundreds of deprecated calls in the JDK, it was those six methods that got removed.

elygre 9y ago
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 9y ago
  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/PropertyChangeListener.html http://download.java.net/java/jdk9/docs/api/java/beans/Prope...
  - vbezhenar 9y ago
    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.
    - jdmichal 9y ago
      From the JavaDocs for PropertyChangeListener [0]: > 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/PropertyChangeListener.html http://download.java.net/java/jdk9/docs/api/java/beans/Prope...
    - needusername 9y ago
      > 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/BeanInfo.html 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.
      - lmm 9y ago
        What's the use case for java.beans in a non-GUI application? Why do you say almost every Java application depends on it?
        needusername 9y ago
        > What's the use case for java.beans in a non-GUI application? 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
        vbezhenar 9y ago
        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.
Someone 9y ago
https://bugs.openjdk.java.net/browse/JDK-7192274 https://bugs.openjdk.java.net/browse/JDK-7192274: "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."
hinkley 9y ago
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).

ivanbakel 9y ago

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.

evacchi 9y ago

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