Hi Maxim, IMHO, each dependency must be justified by a significant gain in terms of coding and algorithm. It is to compare to: 1. the cost to check the dep against last one (mitigate the later upgrade) 2. the cost to scan and test the dep against vulnerability (secure software/lib) 3. the cost to integrate the stack in all supported environments (flat classpath, standalone, webapps, OSGi at least for us - and here any dep can break an integration, in particular OSGi part which is not that greatly tested yet) 4. the bytes cost (not everybody care but I do care to have 10M to have an entity manager when 4 or even less are enough, don't forget it ends in docker layers or archives and this means network transfer costs + scanning time in some env at the end). To give you an idea, if you take geronimo microprofile stack (a subpart but the same in the comparison to be fair) you will end up around 25M whereas the same done at smallrye in a "open bar dependency" mode ends up at around 65M. I'd like us to be clean to enable users to have clean stacks and not hesitate to import us. JPA by itself requires already several code so better to not add a ton for nothing ([collections4] is around 750k, with the import we get ~200k so we gain 1/2M with less conflicts, and work/management to do). 5. the conflict resolution (with some other libs developed like us, you must resolve the version manually to enforce one compatible with both in flat classpath env - ie not OSGi). 6. the cost to do it ourselves, here java 8 (guess 6) superseded [collections4] in our usage for a lot and the remaning parts are very thin so bringing [collections] is only a drawback today IMHO
Add to that our codebase is pretty stable and I dont see us using collections4 anymore in the future, it means it is safe to cut it today IMHO. Current import can look a lot but compared to collections4 it is not and if you drop most of the abstraction without any real logic (abstractX, decorators, interfaces, emptyX) it is almost nothing so IMO we gain way more dropping it than keeping it hanging at the risk to keep depending on it. Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 16 sept. 2020 à 12:59, Maxim Solodovnik <solomax...@gmail.com> a écrit : > Hello Romain, > > why is it so important not to have dependencies? > > On Wed, 16 Sep 2020 at 17:20, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > HI everyone, > > > > we talked of it a lot but i only took some time to work on it this > morning: > > https://issues.apache.org/jira/browse/OPENJPA-2831 > > > > Dropped commons-collections4 from our stack (for now just copying the few > > classes we use but it enables more easily drop code and abstractions we > > don't use). > > > > I suspect the next dependencies we can drop are serp and commons-logging, > > then we would be "pure" (ie only depend on jpa spec and asm - not sure > this > > one can be dropped). Serp is "frozen" and should be replaced by direct > asm > > code but it requires some investment. Commons logging is easier to drop > but > > is a breaking change (in terms of config) we can desire to avoid so maybe > > for next round ;). > > > > Hope it makes sense. > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > -- > Best regards, > Maxim >
