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 java.io 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
