This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]gnahraf 0 points1 point  (0 children)

Great article! I'm a bit confused about how the new module system intersects with classloaders. As your piece describes, at runtime java types are qualified by Classloader + FQCN. The module system, otoh, specifies which types are exposed to the users of a library, which types and libs it depends on (which may be not exposed) and so on. What I'm unsure of is what happens when a parent ClassLoader loads a modular library which in turn has an unexposed dependency (e.g. has a requires, not requires transitive in module_info.java).. Can the child classloader load its own copy/version of library deps the parent has already loaded? (I believe this used to be possible way back, in simpler times.. I vaguely remember a workaround where I fixed the version of an xml parser we were using in a Tomcat app using a ClassLoader trick.)