Re: [jakartaee-platform-dev] Oracle's position on Jakarta EE 9

[Martijn Dashorst <martijn.dashorst@xxxxxxxxx>]

On Thu, Oct 3, 2019 at 10:20 AM Mark Thomas <markt@xxxxxxxxxx> wrote:
> Pruning - No view as it doesn't impact the specs Tomcat implements.

> API Compatibility - I'd like to see the API elements that have been
> deprecated for many years finally removed. I wonder if it is worth
> having a more defined process for removal such as "deprecated in n
> releases and removed in the n+1th release"

On both these I'd suggest doing that in the release *after* the package rename.

As a consumer of the APIs in my multi-million lines of code projects I
don't want to conflate API changes due to the rename with API changes
because of grinding an axe.

Removing old cruft, while it has it merits, means more discussions:
TCK's need to be altered beyond the package rename, interoperability
between specs need to be discussed. It opens up the process for much
more delay.

I'd urge the Jakarta community to do focused releases:
- Java EE 8 -> Jakarta EE 8: transition 'as is' from Oracle to
Jakarta, including all the paperwork, documentation and TCKs.
- Jakarta EE 8 -> Jakarta EE 9: rename all the things: make the world
live in the jakarta package
- Jakarta EE 9.x/10.x -> evolve the specs to your liking

I understand the allure of removing cruft from the APIs, but the thing
is that folks have workarounds in place that can/will fall over when
you remove the cruft. This will break if you conflate the package
rename with cleanup, and you won't know exactly if it is broken due to
the package rename or cleanup.

Martijn Dashorst