Gary - if we have a ticket to upgrade DBCP to java 11, I can take it up. > On Dec 17, 2022, at 1:09 PM, Richard Zowalla <rich...@zowalla.com> wrote: > > Sure. Sounds like a plan :) > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory > <garydgreg...@gmail.com>: >> I think we should wait for a little while: I'd want to release current code >> from git for Commons Pool, then DBCP (which sits on top of Pool), make sure >> all is well, then see about going to DBCP 3, on Java 8 for now but >> considering Java 11 maybe. Do consider that the Commons community is small >> and I would not want to support concurrent support and releases on bothe >> DBCP 2 and 3. >> >> Gary >> >> Gary >> >>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla <r...@apache.org> wrote: >>> >>> 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 >>> >>>
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
