> What do you think would make sense? How about including something like "internal.${version}" before doubleparser?
So for 2.18.0- it would be: com/fasterxml/jackson/core/internal/2/18/0/doubleparser/ And/or including "shadow" or "shaded" could also help minimize accidental use downstream. com/fasterxml/jackson/core/internal/2/18/0/shadow/doubleparser/ On Mon, Apr 15, 2024 at 3:39 PM Tatu Saloranta <t...@fasterxml.com> wrote: > On Fri, Apr 12, 2024 at 8:28 PM Josh Curry <branewo...@gmail.com> wrote: > > > > > But would package name change help? > > > > I think it would - the current package name is very easy to infer to be > part of jackson-core. > > So the suggestion would be to use a package name outside of > "com.fasterxml.jackson"? > I guess that is a possibility, although namespacing in itself is used > to reduce the chance of name collision > (so shaded version won't conflict with any potential external package). > > What do you think would make sense? > > > > > > Shading is done mostly to keep jackson-core as a > > zero-runtime-dependency library > > > > Yes, agreed that this might be useful. > > > > > > > I do not think that change to explicit regular dependencies would be > that much better at all, wrt > > versioning problems.It is still possible to (and maybe even more so) > > to rely on FDP transitively; and whenever Jackson upgrades its > > version, downstream usage may well break. > > > > This is a general problem though for any dependency that someone takes - > including jackson-*. At some point the application owner has to make a > choice on which version of a dependency they take in the event of a > conflict. And yes, if there is little trust that the dependency > > will provide backward compatible upgrades, then maybe it makes sense to > shade - or perhaps find a different dependency that is more reliable. > Also, when fastdoubleparser was shaded, it was a dot release - so the > likelihood of changes was higher. However, now there is a 1.0 release, so > theoretically it will be more stable. > > Be that as it may; at this point I prefer keeping FDP shaded. > > I am +0 on changing shaded package name prefix, but could be convinced > to do that with a good suggestion. > > -+ Tatu +- > > > > > > > > > > > > > > On Fri, Apr 12, 2024 at 4:46 PM Tatu Saloranta <tsalora...@gmail.com> > wrote: > >> > >> On Fri, Apr 12, 2024 at 2:09 PM Josh Curry <branewo...@gmail.com> > wrote: > >> > > >> > It was recently discovered another library is using one of the > fastdouble shaded classes from jackson-core. > >> > > >> > > https://github.com/aws/event-ruler/blob/main/src/main/software/amazon/event/ruler/ByteMachine.java#L3 > >> > > >> > Since the relocated package is not included in the module-info, it > seems pretty clear that there was no intention for downstream consumers to > be able use this code. However, there is no way to prevent it when not > using modules, and usage of shaded code is a common problem, which is often > done by accident. Because of this and tendency to bloat application sizes, > I generally find shading more trouble than its worth. However, it can be > useful sometimes, and one approach is to randomize the package name of the > relocated code in order to make consumption more obviously frowned upon as > well as more difficult. > >> > >> Right, this is a problem. But would package name change help? My > >> experience has been its IDEs that are the reason for exposing shaded > >> packages, and that tends to be based on class names and package names > >> are all but ignored (by tools and -- alas! -- developers). > >> > >> Once upon a time I had a clever (so I thought) way of preventing such > >> accidental imports: I added `private` as part of package name -- like > >> "com.jackson.core.private.shaded.xxxx" since it's actually legal in > >> package name, but illegal in source code ;-) > >> So one could not get auto-completed import statements to work. > >> > >> But some people strongly protested for some reason I don't even recall > >> any longer (probably some tool somewhere having heartburn despite > >> being legal usage at bytecode/JVM/JDK level) so I went back to some > >> legal identifier instead. > >> > >> > >> > Is there a specific reason for shading this dependency other than not > wanting to expose a new dependency to consumers of jackson-core? If not, > then might be easier or clearer to expose the dependency in the next > release - 2.18. > >> > > >> > Thoughts? > >> > >> Shading is done mostly to keep jackson-core as a > >> zero-runtime-dependency library, and I do not want to give up that > >> property. > >> Second benefit is that this prevents version incompatibilities between > >> jackson-core and fast-double-parser. > >> > >> So: I'd be fine improving ways that reduce the likelihood of > >> accidental (or intentional for that matter) use of FDP via > >> jackson-core. > >> But I do not see it beneficial to change shading into regular > >> dependency: that seems to have more downsides for regular users. > >> And while I do not want to set anyone up to failure, I also have only > >> little sympathy for those who use transitive shaded dependencies -- > >> developers really should know what they are using and from where. > >> Automatically click-click-clicking IDE suggestions is dangerous habit > >> and can lead to all kinds of issues with unwanted dependencies. > >> > >> Actually, come to think of that -- I do not think that change to > >> explicit regular dependencies would be that much better at all, wrt > >> versioning problems. It is still possible to (and maybe even more so) > >> to rely on FDP transitively; and whenever Jackson upgrades its > >> version, downstream usage may well break. > >> > >> -+ Tatu +- > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "jackson-user" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to jackson-user+unsubscr...@googlegroups.com. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/jackson-user/CAGrxA24oK3mDW6WDm3jdN%2BMV%3DWybi0_ad2kUfrXjeOr%2BWs88Jw%40mail.gmail.com > . > > > > -- > > You received this message because you are subscribed to the Google > Groups "jackson-user" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to jackson-user+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/jackson-user/CAOSep7JeRjfgAvKZs-YeugcyqU7V0dy3LmK6U8NVi8iD%3DJqQ_w%40mail.gmail.com > . > > -- > You received this message because you are subscribed to the Google Groups > "jackson-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jackson-user+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jackson-user/CAL4a10jSXq6xpyRwErtzoZ8bUgEzHOk4VHPTMoNptOvOqcNoJw%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "jackson-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/CAOSep7JH6NZ_OuF8syjO9mqcE7pFcoOtpT-WZJE4PjKEhQyF-Q%40mail.gmail.com.