This is very confusing and odd practice for a library. It makes the experience of using this library very poor for a number of reasons:
Having duplicate classes in the classpath makes the development experience bad, as anyone using IDE autocompletion features, refactoring, etc. will have duplicates of every common dependency (which includes the entire Kotlin stdlib in this example).
It needlessly bloats the size of the jar. Any project that shades in posthog-java, or uses it in other contexts, will have the file size bloated due to duplicate files.
It makes it impossible to update the libraries that this library uses. Some of the libraries, such as json-java, are out of date, meaning that performance improvements and bug fixes are missing and there is no way to update them without forking the library and updating them manually. See https://github.com/PostHog/posthog-java/issues/46 for an example of an issue that required an entire update to the library, rather than simply adding a more up-to-date version of the library in the consumer's build files.
Some of the libraries used have issues when relocating (Kotlin doesn't play nicely sometimes) which can cause confusing bugs when developers accidentally use the relocated versions of files (even if they don't already have them in the class path).
The original reason for shading (https://github.com/PostHog/posthog-java/issues/22) doesn't make much sense (the issues that the develop faced were not elaborated on and possibly could have been fixed in their build system) and it doesn't feel like it's a good reason to make this library worse because of it.
I would suggest reverting the change and would be happy to make a PR for this if desired.
This is very confusing and odd practice for a library. It makes the experience of using this library very poor for a number of reasons:
The original reason for shading (https://github.com/PostHog/posthog-java/issues/22) doesn't make much sense (the issues that the develop faced were not elaborated on and possibly could have been fixed in their build system) and it doesn't feel like it's a good reason to make this library worse because of it.
I would suggest reverting the change and would be happy to make a PR for this if desired.