For DBCP, it basically boils down to BasicManagedDataSource.java DataSourceXAConnectionFactory.java LocalXAConnectionFactory.java SynchronizationAdapter.java TransactionContext.java TransactionRegistry.java
Looking at these classes, the move to jakarta definitley affects binary compatibility as we have changes in return types / arguments of public methods. Given that it breaks binary compatibility, we could even increase the java level to 11 and drop deprecated things in a potential dbcp 3. In the end, I am happy with everything, which brings DBCP into the Jakarta world ;) If we have consensus for a route, I am happy to work on it / make it happen via related PRs but would need some guideance on the best way to move forward. Gruß Richard Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau: > If not done in new classes (both can live in the same lib > technically), > sadly yes. > > Le ven. 16 déc. 2022 à 20:14, Richard Zowalla <rich...@zowalla.com> a > écrit : > > > Thanks for your replies. > > > > I guess, that switching the namespace leads to binary > > incompatibility (If > > I take the definition from [1]). I cannot drop it in a running JVM > > / app > > and expect no issues with it as the related APIs are breaking > > namespace > > changes (at least at runtime if they aren't present) :-) > > > > Aside from that fact, method signatures might also change from > > javax -> > > jakarta, which would require a short investigation and usage of the > > existing tooling to see if this happens. > > > > From a commons point of view that would mean to go for dbcp3, > > right? > > > > Gruß > > Richard > > > > [1] > > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/ > > > > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas > > <ma...@apache.org>: > > > On 16/12/2022 13:24, Gary Gregory wrote: > > > > Thank you Richard for starting this thread. > > > > > > > > My view is simpler perhaps: I would not make this about the > > > > javax vs > > > > Jakarta namespaces. > > > > > > > > I don't want to double the numbers of jars we produce from the > > > > same > > branch > > > > for affected components as one of the scheme proposed. It feels > > > > like a > > > > burden to maintenance moving forward and a very brittle process > > > > with > > some > > > > unforeseen side effects. > > > > > > > > This is just a code change IMO. For a given component, either > > > > it is > > binary > > > > compatible, or it is not. You don't know until you try it and > > > > see if > > public > > > > and protected elements break, using our existing configuration > > > > of Maven > > and > > > > japicmp (or revapi). > > > > > > > > If it is binary compatible, then let's consider making the > > > > change. If > > not, > > > > then do it in a major version, where the previous major version > > > > is > > > > maintained as we do now, as need be. > > > > > > > > A new major version also benefits from the usual dropping of > > > > deprecated > > > > elements and making any other changes with seem reasonable. > > > > > > +1. I don't see this as any different to increasing the minimum > > > version > > of Java and supported new JDBC methods. > > > > > > Mark > > > > > > ----------------------------------------------------------------- > > > ---- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
