FX Experience Has Gone Read-Only

I've been maintaining FX Experience for a really long time now, and I love hearing from people who enjoy my weekly links roundup. One thing I've noticed recently is that maintaining two sites (FX Experience and JonathanGiles.net) takes more time than ideal, and splits the audience up. Therefore, FX Experience will become read-only for new blog posts, but weekly posts will continue to be published on JonathanGiles.net. If you follow @FXExperience on Twitter, I suggest you also follow @JonathanGiles. This is not the end - just a consolidation of my online presence to make my life a little easier!

tl;dr: Follow me on Twitter and check for the latest news on JonathanGiles.net.

I was just working my way through the last few days of posts on the JavaFX OTN forums and noticed somebody who was trying to learn how to write a custom layout pane and included the following code in the forum posting:


public class MyLayout extends Pane {
@Override protected void layoutChildren() {
// TODO
}

@Override protected void layoutInArea(Node arg0, double arg1, double arg2,
double arg3, double arg4, double arg5,
HPos arg6, VPos arg7) {
// TODO
}

@Override protected void impl_layoutBoundsChanged() {
// TODO
}
}

This reminded me that I had failed to write a blog warning of the perils of using impl_ methods in JavaFX 2.0. DON’T EVER USE THEM!!

In JavaFX we had several places where we needed to have methods which were technically public, but which needed to be excluded from the “public API” requirements of backwards compatibility. Basically we needed friend methods. There is a pattern for this, but we didn’t get it implemented in time for the 2.0 release. We carefully did 3 things to make sure these methods were very clearly not part of the public API and to tell people not to use them, so that we could fix them in an update release (and remove them from the public API entirely):

  1. We gave them all an impl_ prefix ugly name
  2. We hid them all from the JavaDocs. We didn’t just omit docs, we actively prohibit the doclet from generating documentation for them at all.
  3. Knowing many people (including myself) tend not to read docs but use code completion, we also marked them all as Deprecated and included deprecation text that indicates they will be removed and should not be used

So please, do not under any circumstances rely on these methods. They will be removed soon! If there is some functionality there that you really need, be sure to file an RFE with JIRA so that we can add the appropriate functionality as a proper public API!