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.
