tag:blogger.com,1999:blog-5479191305093780981.post5669162121671682137..comments2022-02-28T11:35:44.077-08:00Comments on Lex Spoon: Private dependencies in JavaLex Spoonhttp://www.blogger.com/profile/13859632965228608649noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-5479191305093780981.post-46553368287268666712009-02-02T10:59:00.000-08:002009-02-02T10:59:00.000-08:00I think you should take a closer look at OSGi. Man...I think you should take a closer look at OSGi. Many of these problems are <EM>exactly</EM> what OSGi is designed to support. The "component related" features exist at a higher level in OSGi called the Service Layer, so it's possible to learn about and use the Module Layer on its own if that's your preference.<BR/><BR/>As you implied, OSGi creates a separate classloader for each module (or "bundle", to use the OSGi terminology) and strictly controls the visibility of classes between bundles using a system of exports and imports. The old Java flat classpath is not used.<BR/><BR/>So the "diamond" scenario you described is solved this way in OSGi. A and B both import Lib, and they may choose to import different versions of Lib (all imports and exports are versioned). Both versions reside in memory at once.<BR/><BR/>This works very well as long as A's and B's use of Lib is "internal". If instances of classes from Lib need to be passed out of or between A and B, or up to App, then you will get a ClassCastException. But this is as it should be: if A and B need to communicate in terms of artefacts from Lib then they should have a common understanding of what those artefacts are.Neil Bartletthttps://www.blogger.com/profile/08588098030811273044noreply@blogger.com