Spring's Rod Johnson on OSGi
phil swenson
"We have changed our views on OSGi over the years, and one of the
reasons for that is that OSGi simply cannot be made as easy to use and
as productive as we feel is consistent with Spring values."
"Niche"
Chris Adamson
personal attacks to show up in the comments. I remember the OSGi
community being much quicker to anger than that.
On Jun 23, 4:22 pm, phil swenson <phil.swen...@gmail.com> wrote:
> http://www.theserverside.com/news/2240037102/OSGi-Not-Easy-Enough-to-...
Kirk
Lets see, MS tried it with COM/DCOM.. failed, Smalltalk tried it with Envy.. failed.... OSGi is modeled some what on Envy from a failed attempt to port Envy to Java... (Envy was bought by IBM)
You know, I'm seeing a failed in those attempts. Hope isn't much better for Jigsaw but....
Ok, now why the failures. Well, my real world experience with some of what OSGi is trying to achieve is simple combinatorial complexity that just naturally comes with dependency management. Unless this problem can be tooled (and even then), the whole thing grows beyond a humans ability to manage it. Many systems we are building today are just way too complex for this extra level of complexity.
Did I mention OSGi breaks the already broken Java classloading system? Must see talk, "Do you really get classloaders" by Jevgeni Kobanov, the Zero Turn-around guy. I'd swear he knows more about classloading than the JDK guys that devised the evil scheme we all face today (I know for sure that they consider him a PITA :-)). Is OSGi classloading any better? Hard to say. Does it solve any of the current classloading issues? My answer is none that I know of (correct me if I'm wrong). Does it create issues of it's own? Yup, just had fun with Resin, OSGi and a profiler that kept breaking. Visibility was an issue! Java packaging is already hard enough, seriously, do we really need to make it any harder?
Regards,
Kirk
> --
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
>
Kevin Wright
Kirk
OSGi *is* tricky to get right, that much is true.But... You need the right tools to get there, and it would seem that Spring simply doesn't have what it takes, that's hardly OSGi's fault though!
Have a talk from OSGi & Eclipse specialist Neil Bartlett at JavaWUG, it's rather good. He explains matters more clearly than I could:
Steve Lindsay
> Looking at the TSS article, I'm surprised it took over an hour for the
> personal attacks to show up in the comments. I remember the OSGi
> community being much quicker to anger than that.
>
about a whole community.
OSGi can be pretty nice, modularity and runtime dynamism are not
things that Java tends to do well normally. To me it seems that the
main problems for OSGi are that Java devs are used to good tools and
OSGi tooling is immature; and that library/framework writers
are used to using the classpath in a way that doesn't play nicely with
OSGi.
For OSGi to really succeed it needs a critical mass of developers
embracing it. There's a lot of 3rd party code that is painful to
use - the first time you hit a lirbrary that doesn't play well with
OSGi the typical response is "OSGi is annoying", and not "this
library writer is making assumptions about the classpath that are not
always going to be true". IMO to succeed* in the long term it
would really need to be part of the core java platform, and that seems
pretty unlikely, esp. now with Jigsaw on the way.
* At least where "success" == mainstream adoption, it is arguably
already very successful in some areas.
Fabrizio Giudici
and I was happy to see that since 6.9 they started a convergence and
today the NetBeans Platform module system has got a high degree of
compatibility with OSGi. I thought of myself in the OSGi camp since a
couple of years, even though I'm still less than a newbie (I had other
high priority things and I decreased OSGi priority as I see adoption
slower than I expected).
Yes, module system have got problems with the classloaders. But as far
as I see with the NetBeans Platform, they can managed. I think that the
more complex an application is, the higher the need for a module system
is. Take Hudson/Jeskins, for instance. At the beginning it was a piece
of cake to use and upgrade. Since more than one year every update
experience is a pain in the ass, because some plugin breaks. As far as I
understand, the Hudson/Jeskins plugins are versioned, but there's no
compatibility enforcing facility that could prevent me from installing
an incompatible plugin (and if there is such a facility, well it's
broken as I just upgraded Hudson and a plugin broke).
I can't imagine how to build an application with the complexity of
Eclipse or NetBeans or JDeveloper without a module system with enforced
versioning.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it
Ricky Clarkson
> or NetBeans or JDeveloper without a module system with enforced versioning.
Perhaps you could build an application with that level of
functionality but not complexity then.
*looking at IDEA*
Neil Bartlett
soundbites would suggest. He said that OSGi productivity is low
compared to "traditional" Java development, and it may surprise you to
hear that I agree with him on that point... currently.
However I don't consider that a reason for giving up on the goal of
building modular software. I and several others believe that OSGi can
actually be made *MORE* productive than non-OSGi development, and we
intend to prove it by building the tools that SpringSource failed to
build.
I do think that SpringSource could have solved this problem as well,
but they chose to focus on products like tcServer that were easier to
sell and provided faster profits. Actually this created opportunities
for smaller companies so ultimately I'm grateful to them.
Neil
On Jun 23, 9:22 pm, phil swenson <phil.swen...@gmail.com> wrote:
> http://www.theserverside.com/news/2240037102/OSGi-Not-Easy-Enough-to-...
>
Jess Holle
is to provide more tooling for OSGi or something simpler and possibly
better integrated with the language, e.g. Jigsaw.
On one of the point items I have to agree with the Posse -- if you get
to the point where you want different versions of the same library being
loaded at the same time, then that's generally a sign that your overall
dependency management has gotten out of control or that some modules are
not being adequately maintained. Sure, in some rare cases such a need
will occur, I've seen it -- but I'd be loathe to add complexity to >98%
of development for the <2% problem.
Neil Bartlett
1) Modularity is not important or useful.
2) Modularity IS important, but OSGi is not the best solution, and
better solutions exist already or will exist in the future.
3) Modularity is important and OSGi is the best solution.
Rod does not appear to be arguing position 2, instead he seems to be
arguing position 1, that modularity is not important or at least not
important in most cases. I disagree, I think it is important in far
more cases than Rod states... it's not just for infrastructural
products like Eclipse or Glassfish, but those large internal corporate
projects written by banks, insurance companies, retailers etc also
stand to make big gains from modular techniques: enhanced
productivity, reuse of components, more resilience to failure of
components, easier division of labour between teams, etc.
Position 2 is kind of what you said, that Jigsaw or something else may
be better for modularity than OSGi. It's kind of difficult to assess
this because Jigsaw is nothing more than a requirements document at
this stage (and incidentally those requirements are well aligned with
OSGi).
Obviously I'm at position 3. I think that companies can gain a
competitive advantage by using a module system that works now rather
than waiting an unknown amount of time for a new module system that
may or may not be better.
Regarding your other point about multiple versions of the same
library, I agree that it's undesirable, but it's necessary more often
than you think. If some of the modules you are using come from third
parties, then it really doesn't matter how actively you are
maintaining your own modules, and you may be forced to fork them just
to achieve single version compatibility. Anyway you have fallen into
the fallacy of picking just one of the things OSGi offers and arguing
against that as if it constituted an argument against the whole.
Regards
Neil
Roland Tepp
Nobody has any actual real world exposure to building real modular and extensible applications with it and there is no telling what kind of problems are people going to get themselves into when jigsaw hits the fan...
phil swenson
and easier, less risky approach is to use dependency injection enforce
your module breakouts with a decent build system (gradle). This gets
you most of the way w/o out all the tooling and testing headaches.
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/lM-SRAw0jssJ.
Roland Tepp
Modularity is just a concept you can implement in many was.
Dependency injection is another tool and it does help modularity in the implementation of your code by allowing to decouple interfaces from implementations, but it does not in any way offer you modularity in the architectural point of view. You can use DI with or without OSGI with equal ease.
Build systems can do only so much for modularity. More often than not I find people tend to say they build modular systems when in reality they simply chop up a big monolithic application into few separate interdependant projects and stil deploy the whole enchilada. Maven and Gradle helps quite a bit here, but only if you use them wisely, which is still a rare thing to behold.
I find OSGi helps me because it enforces same rigid class visibility on me both, in development time as well as at runtime. It is uncomfortable as hell to really think about things like separation of concerns or package visibility or defining explicit module dependencies when all you've used to do so far is slapping few classes into a jar and calling it a module.
Sure, former is more arduous work - you have to actually THINK about these things you've never actually really thought of before - sure, you might think you did, but in reality it was just so breaf and abstract, you might just as well not have. But all that hard work pays off when you start SEEING the actual dependencies and you can start reasoning about it. Hell, you can write programs that can reason about dependencies of your modules.
Another thing people are starting to see and get scared is the explosion of bundles/modules. When before you would have two jars you would likely see five or even six bundles. You would have your two API modules and two implementations of these API's and then you would have one or two "bridge" modules that make use of both API's. It tends to scare people. The dependencies are suddenly out in the open and in your face. And it scares people.
In it's simplest form, OSGi bundles are nothing more than jar files with some special metadata in their MANIFEST.MF file. It does not get simpler than that. You've actually got some pretty nice tools for generating that metadata in your jar manifest like Bnd and Bundler.
Beyond this, there is the dynamic lifecycle management of bundles in the runtime, OSGi Service registry and that warm fuzzy feeling that you get when you know that your runtime and your development time environments are actually pretty much same.
You do not have to use any of the extra runtime features if all you provide is a general purpose library like Log4j or JodaTime or Apache Commons or Google Guava. And you can afford to ignore this even when writing vertical applications relying only on the libraries in your dependancies as before.
When you use those advanced features of OSGi however, you need to pay attantion to some principal premises and this is where true complexity comes into play. Due to the highly dynamic nature of OSGi you need to be aware that services you are using may at any point in time go away. You can still opt to ignore this notion if you are absolutely certain that your environment has no need for hot-deployable services and you can tolerate some downtime for the duration of the upgrade.
There are of cours also some things you can not do that are easy in classpath based world where all the classes are essentially in one giant soup of a classloader and every class is implicitly visible to every other class. Hence problems and difficulties with frameworks heavy on dynamic reflection like Hibernate or Spring. Punching holes into the bundle visibility encapsulation like Eclipse-BuddyLoading help with visibility but introduce possibilities for sneaky classloader deadlocks that manifest themselves in a most bizarre and inconvenient moments.
All in all - I would not call OSGi as complex as it is made out to be. I would go as far as to compare the complexity of the OSGi to the complexity of Scala. Both are arguably complex beasts, but the main complexity is in accepting their differences and learning new concepts. Once you can do that, there is some inherent complexity of solving real world problems in a idiomatic way, but that is what we get paid for... :)
Incidentally, Scala standard libraries are also annotated with OSGi metadata, making them OSGi bundles. :)