Backward compatibilily is present if we change only package name. But if
specification evolve, we have same issue that upgrading Java EE 7 and
Java EE 8 : Not tools and human intervention.
Exactly! It is precisely because of EE6 -> EE7 -> EE8 compatibility that we have not already pruned/deleted old methods and classes.
Renaming the packages does not absolve us of any backwards compatibility requirement, so I don't see why it gives as any more opportunity to prune than any other EEn -> EEn+1 change. In fact I would argue that because of the need to change entire code bases, it is the transition that would be most difficult to do it in as removing cruft is hard enough to do at the best of times, doing it during a large disruptive renaming exercise is going to make the renaming (either source of binary), more difficult!
It still might be the best time to do it, but let's not discount the extra effort that will be required. Any thoughts of simple translation tools can be forgotten and the tools will have to be smart semantic aware tools that will either know how to rewrite deprecated code patterns or signal humans which parts of the code need to be rewritten.
cheers
