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]
