> 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.
> 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. 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.
