On Fri, Dec 20, 2024 at 4:48 PM Alex Buckley <alex.buck...@oracle.com> wrote:
> On 12/20/2024 12:48 PM, David Lloyd wrote: > > A replacement library (or even an original library) might be > > obligated to change one of *its* implementation dependencies (like a > > utility library) due to security problems of this sort, and since it > > is an implementation detail, it would not be natural to expect any > > user to consider that the third library's having a different API/ > > package set could introduce some new hygiene problem. We've always > > considered it to be a natural property of encapsulation for the > > consumers of A to not have to worry about what's going on with C in > > an A->B->C scenario (or its presence or absence). > When you say that M should "not have to worry about what's going on with C", I think you mean that _even if C exports all its classes and even if > M arranges to consume C_, some additional mechanism should provide > _isolation_ for C, such that M's code cannot access C's code. > > Such isolation would open the door to replacing C by D -- a module with > different bits, and different dependencies, but the same name and > exports as C. D and all of its dependencies would be outside the worry > range of M, just as C was. > It would also open the door to replacing C with E: a module with different bits, dependencies, *and* name and exports, as a part of upgrading B to a new version, without breaking A. Not only that, but if M decides it needs C - or it needs something that needs C - you are not necessarily locked into the problem that A and B must agree on a version of C, if there is an isolation mechanism. Version convergence can be a very challenging problem when dealing with hundreds or thousands of modules. Shading with package relocation would be a traditional workaround for this kind of problem, but it brings troubles of its own. Managing a set of available modules in a container to a user base is itself a kind of API, in that you want to restrict its surface area (aka coupling surface) as much as possible. The JDK can use accessibility for this purpose without encountering these issues, because it comprises either code that originates in OpenJDK, or third-party modules that have been package-relocated. A container or other extensible run time environment will often use third-party libraries internally which are not intended to be a part of the surface area of available modules and should be isolated from the user if possible. -- - DML • he/him
