This needs to be in the 4.0 pile too, see 4cf1dbd where the change was reverted because it broke method calls to subclasses.

@mbabker do I have to do PRs against the 4.0 branch for those cases?

That'd be preferred. Many of the deprecations are already phased out in the 4.0 branch so you'll want to check that too.

In general, static method calls are pretty easy to replace, but when you're dealing within object APIs it gets a little more tricky (like removing a call to a deprecated method or changing the class inheritance can introduce B/C breaks)

OK, I'll be checking the 4.0 branch then, thanks.
BTW, B/C breaks due to class inheritance I get, but why when replacing a call to a deprecated method with a call to a new method that was either proxied by the deprecated one or does exactly the same thing?

So in this case specifically, the older refreshIncludePaths() method was replaced with a new method at some point after the old one was originally pushed out in a release. So if you subclass the class and rely on refreshIncludePaths() to get called to do your extended stuff, but that stops happening because the calling chain changed, it breaks B/C in a goofy way (you can't rely on your extended refreshIncludePaths() method to do what you need it to in all releases within a major version series after it was included).

Even though the end result is the same in the class it's called within, because JLayoutFile can be subclassed (it's not declared final) everything that's a public or protected class member has a varying degree of API exposure and therefore falls under the B/C promise.

Yes, of course! Totally missed that one. Great explanation btw!! Thanks

This is a b/c break sadly - we did this before and it broke extensions (e.g. #11084) - We have also already merged this into the 4.0-dev branch - so I'm going to close this PR

@wilsonge Great! As noted earlier in this PR, I'll do PRs against the 4.0 branch, if B/C breaks might be an issue with 3.x.