[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
- From: Mark Struberg <struberg@xxxxxxxxxx>
- Date: Wed, 15 May 2019 08:25:36 +0200
- Delivered-to: firstname.lastname@example.org
I agree that JakartaEE must find a policy about backward compatibility.
And I fear there is much more to think about:
a.) so far JavaEE has been incredible backward compatible from a code aspect. It was way harder to move from one vendor to the other than from one version to the next!
b.) I _hope_ that JakartaEE is moving much faster than JavaEE which sometimes took 4 to 5 years per version. So the requirements for backward compatibility is much higher in my opinion. While it's ok to do bigger changes every 5 years, it's not likely to happen every 1.5 years.
c.) If we have a strict javax.* to jakarta.* for certain packages then this can be auto-transpiled via class transformer, etc. Even consuming both at once. So I personally don't think about this as a normal backward compat change.
> Am 14.05.2019 um 22:00 schrieb Bill Shannon <bill.shannon@xxxxxxxxxx>:
> Greg Wilkins wrote on 5/14/19 12:58 AM:
>> Binary compatibility sounds easy... Specially if it starts off as 1:1. But
>> eventually APIs and behaviours will evolve so it will become 1:1.1 or more.
>> Then binary compatibility is more difficult and nuanced.
> As I said before, we need to think about what requirements we want to have in
> general for version-to-version compatibility.
> Assuming we introduce a bunch of new/renamed jakarta.* APIs in Jakarta EE 9,
> what are the compatibility requirements for those APIs in Jakarta EE 10? Or
> Jakarta EE 14? When (if ever) do we decide that it's ok if applications written
> for the EE 9 jakarta.* APIs fail to work?
> The javax -> jakarta transition can be just a special case of the general
> problem. We need to decide what we want the rules to be in the general case and
> then consider whether to apply them here.
> jakartaee-platform-dev mailing list
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit