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.
