Niclas Hedhman wrote:
On Wed, Dec 17, 2008 at 11:45 PM, Richard S. Hall <[email protected]> wrote:
For the most part, I believe what you describe is possible with what OSGi
provides. Clearly, a lot of legacy code makes this difficult, but that is
not the fault of OSGi (nor the legacy code, since it was created pre-OSGi).
The real issue is not where API packages reside, rather it is that tools
like Hudson do not understand the dependency model of bundles.
1. Yes, it is in theory possible, provided that;
a. The container doesn't have obscure bugs.
b. The programmer manages to clean up the mess in stop().
c. That the stuff "cleaned up" really do what it claims.
Are you expecting that there will ever be a time when there will be no
bugs in programs and programmers will always to the right thing? Don't
hold your breath.
2. Yes, but we have a lot of programmer's who have not been 'fed the
red pill' and don't even know how deep the rat hole goes, and continue
with current practices.
Which is exactly the difficulty of living during a transition. If Java
never allowed anyone to use the default package, we wouldn't have to
worry about people doing it in the first place...that doesn't really
help us now, though.
So, from my PoV, fixing the tool chain is only a fraction of the
overall problem. Yes, it fixes the build part of OSGi/Modularity
conscious individuals, but that doesn't mean it is a 'solved'.
Clearly, fixing the tool chain is only a fraction, but unfortunately it
is a larger fraction than it might be if we were starting from scratch
with designing the Java language and platform with hindsight. We don't
have the option to make a clean break from the past because we are
working on an evolution of Java. However, I am all for starting over
from scratch, if you can convince everyone else.
As for containers properly working in endless update/refresh cycles ->
I only know that 2 years ago, even one of the simplest cases didn't
work reliably on Equinox, and I therefor doubt that the more complex
scenarios that are possible in OSGi actually works reliably today.
Problem being that it is extremely hard to test (TCK is far too weak
in this area) and diagnose, so I am not surprised... It is an
excellent tool for development, but I don't dare to recommend it (no
restarts) today for any mission critical applications. Hopefully this
improves over time.
That's what keeps us all employed...
-> richard
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
