To start with, I am a Java EE user and small scale developer and not developing Java EE servers or supporting huge customers or code bases.
I would opt for option 1 - the so called "Big bang". I phrased it as "so called" because it is a real big bang, but not for the customers. It's a big bang for the platform vendors.
What I mean is, when a customer gets a new release of an application server, they do not necessarily upgrade their app to the latest Java EE release supported by that application server They rely on the fact that the server will support even their J2EE apps forever. If a customers wants to upgrade their apps to the new specs coming with the new EE release, the amount of work usually goes much beyond simple renaming of imports.Â
Just put it for an example in the perspective of JSF. You may have applications that you have written 10 years ago, which would look like much differently than contemporary JSF books, blogs and examples showcase. But still they are supported by the application servers. And the decision to migrate those apps to latest and greatest JSF goes far beyond simple renaming of lifecycle scope imports. So we already have migration effort all over our specs, but it was not put that dramatically so far.
I think supporting Java EE has never been out of scope for all the vendors here. Either formally via Legacy Profile as proposed by Richard or informally by byte code modification, I hope everyone is already elaborating the possible options. But this will be the biggest work to be done with this transition in my eyes. And not reworking existing apps.
But again, that from the point of view of a person that just develops small to medium scale apps and does not develop the app server or support J2EE apps anymore.