How do libraries not get messed up when different plugins depend on different versions?

Say plugin A and plugin B both depend on a library. plugin A depends on version 1 of it, and plugin B depends on version 2. When the classes are loaded, only one plugin is going to get the version it needs, unless the library changes it's class path with each update. However, I don't see libraries like vault doing that. Do libraries like vault just depend on everybody requiring the same version? What if someone's plugin depends on an earlier version? Could that break everybody else's plugin if their plugin is the first to load the library, so an older version gets loaded?

 

@MrZoraman

Libraries like Vault that require a seperate plugin on the server don't suffer from this because the files that are built against are not included in the jar release, and all the plugins on the server share the same plugin that is installed on the server.

If you include a library in your plugin, and don't assign it a class path that begins with your own classpath (very bad idea) you will run into this problem of class collision.

 

It's also a good idea to keep backwards compatibility within a library by never changing existing interfaces.
So a newer plugin can use new features of a library while an older plugin will still run with the new lib version.

 

Java as an overall language is Design by Contract, which is a very good homage to the principles of an API contract. Methods do not get introduced or removed on a whim, and as such unless there is a significant difference in dependencies (in which case the older project should be updated), there generally won't be an issue as the older software should still be calling on existing methods.