felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: New OSGi presentation
Date Thu, 20 Jan 2011 23:01:52 GMT
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<heavy@ungoverned.org>wrote:
>> On 1/20/11 10:47, john.dunlap@exceter.com 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"<heavy@ungoverned.org>:
>>>   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: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org

To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message