Rodrigo Kumpera wrote: >>>In terms of extensibility, the classlib is mostly a dead-end, an >>>end-user should be better using some SPI. But good modularity keeps >>>the software entropy low. >>> >>> >>> >>> >>I am not sure what you are referring to with "classlib" here. >> >> > >The j2se lib, eg what classpath is implementing. > > In that case, I agree that extensibility of the class library is a dead end, but that doesn't mean structuring it as a nice collection of modules with well defined relationships is a dead end. >Well, the classpath folks seen to be doing just fine without an OSGi >like container. There are some implications for building such thing, >first is the fact that a big part would need to live in a >"container-less" enviroment, as it would be hard to read a manifesto >file without the package available. ;) > > It just depends on how you want to look at. I guess by that definition Sun would be doing fine too, but I have butt my head against Sun's implementation because it doesn't expect class loading delegation to be a graph so it can deadlock, for example. It also expects that all VM implementation classes are available from all class loaders, as another example. There are just numerous areas like these where it is problematic if you do not follow strict rules. Again, I am not proposing using an OSGi container. I am proposing to use class loaders to enforce separation, that is all. Also, I do recognize that there is more than one way to achieve similar effects. I must admit, though, that I have an ulterior motive, which is the desire to see this sort of modularity functionality become available to application programmers themselves, so that they can get all of the benefits that I am describing. I think this is a necessary step for Java if is wants to better position itself against .NET (assemblies and GAC). -> richard