On 1/20/11 17:13, Per-Erik Svensson wrote:
Great read, although a little "hostile" to newcomers maybe. :)
I guess you could interpret it that way, but that wasn't the intent.
Maybe hostile to people who think they can use something without even
attempting to understand it, but really i was just trying to make
assumptions clear.
The parts about class loading might, as others have suggested, be a bit too
complex for us average java developers too. I certainly didn't know about
this before starting with OSGi. And I still have alot to learn of course!
And I believe this is the place where OSGi has the most left to do. Class
loading is an implementation detail that shines through. When I declare a
method to be private, I never have to worry about how the JVM enforces that.
In the same sense, I shouldn't have to worry about how OSGi enforces package
visibility. But that's another story.
Technically, the presentation is about type visibility, not class
loading. Only at the end do I talk about class loading...and definitely
the end is a little more complicated. However, type visibility shines
through even in standard Java...if you don't understand how to set the
CLASSPATH variable, you don't get very far in Java. So, the main point
is that the "standard" type visibility rules no longer apply in OSGi,
you must learn new type visibility rules.
So, in that regard, I don't agree with your implication that you need to
worry about how OSGi enforces visibility, since I don't really talk
about class loaders at all. In the end, you need to understand what the
primitives mean and what to do when you get an error. Just like if you
make a method package private and try to access it from another
package...you have to understand that this is an error and how to fix
it. Module visibility is exactly the same (if you don't specify a type
as "module public" (i.e., export it) and then try to access it from
another module you'll get an error...no need to understand anything
about class loaders...but for debugging it can help to understand search
order, just like the class path).
Also, I think a presentation like this is a great place to emphasize the
difference between "jar dependency management" and "package dependeny
management". Had I read the presentation a few years back (two maybe) before
having started to "Felix" (yes, it's a verb now), I might have thought
"Well, maven does most of this for me, and without those silly
restrictions!.". It is a profound point about OSGi that might be easily
missed when reading "starter materail". But I guess one can't cover
everything at every possible depth. And you do talk about it, and you do
mention versions. I just think that the whole "per package!!" idea might get
lost between all modules, jars and cookies. :) A module is a set of
packages, depending on other modules with packages. A module is not a jar
with classes depending on other jars with classes (as with maven).
I agree that this is a distinction, but it is between Maven and OSGi.
This presentation highlights the differences between standard Java and
OSGi. In standard Java there is no concept of a dependency at all.
Perhaps there could be a footnote in there for all the Maven users. :-)
And of course, to further shoot down "maven does it for me"-like arguments,
slam a big "services means *modularized* *dynamism*" sticker on top of every
page. Ok, don't... But, as I said, people might get the impression that OSGi
is a way to manage your jars - when it can actually cook and wash your car
too.
Yeah, this presentation focuses on the minimum...in particular, it
focuses purely on modularity since that is often the entry point for
people and they only get that far.
As said, very interesting read! In fact, it got me wondering about a few
things so I'm off asking questions in a mail list near you! Thanks! :)
Thanks for the feedback.
-> richard
Regards,
Per-Erik Svensson
On Thu, Jan 20, 2011 at 5:32 PM, Richard S. Hall<[email protected]>wrote:
On 1/20/11 10:47, [email protected] wrote:
Thanks for doing this Richard!
I like the sound of OSGi but I've never made the leap to it because I
don't feel that I understand it well enough to convince myself that it is
the right direction to go in.
Your slides have clarified a number of things for me and your analogies
are both clever and funny! I found the slides very easy to follow but I
found myself getting confused in the "Understanding search order" and "When
things go wrong..." sections, I think partially because I don't have a solid
grasp of the terminology. What is class loader delegation?
I am familiar with the notion of dependency management from my experiences
with using Maven to build my projects so I can somewhat follow you in the
"When things go wrong..." section where you first mention transitive
dependencies. However, old school developers that are stuck using Ant might
find it more difficult. You touch on the subject in various places but I
think it would be helpful if you had a couple of slides that briefly talked
about dependency management in the context of OSGi before moving on to
troubleshooting.
Those two sections will be the most difficult to follow, for sure, so
you'll just have to catch me presenting it sometime. :-)
Seriously, though, I am already working on improving that section by trying
to improve the error messages printed by the Felix framework. I will see if
there is anything else I can do to add some more introductory overview for
class loaders (without adding too many more slides).
-> richard
Cheers!
-John
Quoting "Richard S. Hall"<[email protected]>:
After some recent experiences I had with some developers trying to use
OSGi without even understanding the basics, I decided to work on a
presentation highlighting what you must understand about OSGi to use
it. Please find it on the presentations page:
http://felix.apache.org/site/presentations.html
The direct link to the PDF is here:
http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
Comments welcome.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
