API Deprecated/Removal Process

[Eric Bresie]

I know the benefits of API / implementation removal accommodates change and efficiency to the platform, which I welcome however the more removals that happen, the more risk this will break existing application code, the risk of additional cost for updating existing developed products (which not everyone may have the budget to do so given much is spent on updating own products and priorities without having to introduce changes like this, which prior to pruning of API was less a concern with Java), and just plain risks leaving a bad taste in developer and user’s mouth which could drive people away, which no one wants. So with that said...

What is the process when dealing with deprecated and removed API? Or more specifically use case of alternative implementations?

I understand depreciation/removal details are usually document in applicable API content and JEP 277 Enhanced Deprecation (https://openjdk.java.net/jeps/277) provides rational and how to annotate things and denotes the need to utilize new interface if available or to use alternative implementation.

So define aspects of handoff activities to include potential donation of deprecated/removed code, forking to the alternative, address licensing concerns, how to handle name-spacing concerns (i.e. is the old namespace available or does new namespace needed), and documenting alternatives (i.e. tracking alternatives via wiki, doc, javadoc/api, etc).

Or could some form of dependency injection be used to specify alternatives to ease the transition?

Eric Bresie
Ebresie at gmail.com (mailto:Ebresie at gmail.com)