"I guess you could interpret it that way, but that wasn't the intent."
I understand that and I didn't take it as hostile. But I couldn't find a better word, although I'm sure there are plenty. :) "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." Agreed it's not a completely fair comparison. And point taken. Maybe it's a tooling problem though. Most IDEs abstract away the classpath and the only time you deal with it is when deploying desktop apps (?). And I wasn't talking about the presentation specifically but OSGi in general. You do have to understand alot more about class loading than I would like to believe is necessary. At least if one want to be able to parse the error messages. But maybe I'm wrong, maybe it is necessary to know that there is a class loading search policy and what boot delegation means. I will continue to live with the hope that future OSGi specifications/implementations will abstract away more of this though, but maybe it's hard or even impossible! :) (Thinking about it, maybe I'm just biased because I'm so used to the classpath... Just like I hope to becoming used to OSGi and "no longer have to care about it".) "Perhaps there could be a footnote in there for all the Maven users." Hehe, no, no, that's working in the wrong direction. Maven should come with a footnote about OSGi!! :) "Yeah, this presentation focuses on the minimum..." And it does so good. I didn't mean to imply otherwise. I just saw what I believed to be a few to many classloading troubleshooting pages that could be swapped out with services. But you're probably right. You have a good focus on modularity now instead. Regards, Per-Erik Svensson On Fri, Jan 21, 2011 at 12:01 AM, Richard S. Hall <[email protected]>wrote: > 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] > >
