Thanks for your constructive comment Dick. I look forward to hearing your interview with Peter and BJ.
>From my point of view, the complexity you see and you heard about at EclipseCon this week is not actually the complexity of OSGi, nor is it the supposed pervasiveness. Rather it is the complexity of the new things that OSGi enables us to do. With OSGi we are no longer stuck in the world of flat classpaths, NoClassDefFoundErrors and making sure everything is built and released against the same version and never upgraded and so on. Those problems are solved whereas they are the bread and butter of traditional Java development. But every time you solve a problem you discover ten new ones, and it turns out that now we have the power to build large complex applications in a modular and dynamic way, that power must be used responsibly. In particular we need tools to manage large numbers of versioned artefacts, not because OSGi forces us to create them in such large numbers but because it *allows* us to do so. Note that Jigsaw, assuming it is ever built, would encounter all the same problems with managing complexity! I do strongly agree with your final argument. We should indeed use OSGi because it is the best, quickest and easiest, or we should use Jigsaw if it turns out to be the best, quickest and easiest. We should NOT use Jigsaw just because Sun puts it in the JDK and we don't bother even looking at its relative technical merits. On Mar 26, 11:48 pm, Dick Wall <dickw...@gmail.com> wrote: > Attending EclipseCon yesterday and talking to Peter Kriens and BJ > Hargrave forced me to finally take in some of the information about > OSGi, and I thought I would share some of my thoughts on this handy > thread. There may be some hard statements here, firm but fair > hopefully. > > Firstly, I really didn't want to care about the modularisation > mechanism, I just wanted to have the benefits, but it appears that > care I must. > > So I learned about OSGi. It looks like it does what it does very well, > but one theme running throughout the day was the complexity. LinkedIn > made a point of mentioning it in their talk, and even strong advocates > seem to admit it could be simpler. Note that the complexity is not a > function of the manifests (although they do repeat information which > is less than ideal), but mainly appears to be through the required > pervasiveness of OSGi throughout everything you do (all third party > libs, etc.). > > My own take is that while I understand the problem domain is a > difficult one, so is Java persistence, and yet we now have JPA, which > is a fine API that takes only a few hours to learn the basics and > start using in Java applications, surely the same could be true for > Java modularization. > > Being forced to finally learn about OSGi, I looked for areas where it > would help me - working in a fairly representative job with a medium > sized web site and back office management interface, as well as some > pretty neat calculation stuff. > > It occurs to me that the biggest benefit of modularization in my case > would be to bring down build time and increase developer productivity. > For our situation the ability to hot-swap modules in live systems is > not compelling - like (I suspect) many companies, we test release > candidates and then swap the final result onto a website - with > curtains down for a couple of minutes if necessary, I understand this > is not true for everyone, but making life more difficult for all > developers on the premise of "you might one day want to do this > obscure thing" is responsible for bringing us EJB 2.x. > > So - given the idea that my war files could be made smaller and much > faster to build and deploy, is that a compelling argument for OSGi. I > would have to say, not in it's current form. The amount of work > required to make bundles out of everything we depend on, and > reorganize our build into a set of OSGi modules just to get the war > sizes down, is completely out of line with the benefits it would bring > us. > > I believe the same will be true for a lot of smaller/medium sized > companies. > > I understand Neil's concerns about fragmentation, but on the other > hand a standard should not be kept just because it is a standard > (otherwise we would have never had Spring, and EJB 3.x would have > probably been even more complicated than EJB 2.x). > > To go further, it seems to me that the best way to ensure the > dominance of a standard is to make it a really good standard. Spring > shows what is possible when a good third party alternative goes up > against what is in the "standards" offerings, and that (along with > Ruby on Rails) drove a lot of positive change in the industry. > > The first step for, say, my (or our) adoption of OSGi would be to > bring down the price of admission significantly and make it worthwhile > for a small company like us to get the benefits more easily. Reducing > complexity and agreeing with other projects that handle dependencies > would be a good start, as would taking advantage of language keywords > and annotations. We should have learned by now that DRY is a good > idea, so why do I have import statements in Java source, dependency > definitions in OSGi and then again in Maven. That sort of stuff should > be kept in one place (the source), with enough pressure relief to > allow exceptional cases (like XML configuration overrides in JPA that > are only used when needed). > > In other words, let's use OSGi because it is the best, quickest and > easiest project out there, not because it is an entrenched standard. > If enough people think it is too hard or costly to use, don't we owe > it to ourselves to adopt something better? If fear of fragmentation is > what drives improvement of OSGi then great, it will only be better > from the effort. > > Cheers > > Dick > > On Mar 26, 2:22 pm, Reinier Zwitserloot <reini...@gmail.com> wrote: > > > OSGi, like any other programming language/library/whatever, has a > > community associated with it. Such a community has a certain > > reputation; its only natural for communities to develop certain quirks > > and groupthink. It is perfectly acceptable to take the community into > > account when choosing one library over another. > > > The groupthink of OSGi is to whine incessantly about the evil sun. > > It's one of the main reasons why I don't like OSGi. > > > You are certainly not the only loudmouth. 3 out of every 4 blogs I > > read that praise the virtues of OSGi actually just give me a thousand > > mile overview in one paragraph then spend the next 4 beating on sun. > > Trust me, that is not the right strategy for convincing non-believers > > to join your side. > > > On Mar 26, 6:35 pm, Neil Bartlett <njbartl...@gmail.com> wrote: > > > > Reinier, > > > > It's a shame you choose to see it that way. You know, if Sun had > > > admitted Java had a modularity problem 10 years ago then OSGi would > > > not have been necessary. Today OSGi is the standard, Jigsaw is way too > > > late and stands in opposition to the rest of the industry. > > > > I really don't want to whip Sun either. Like the curate's egg, most of > > > Sun is excellent and I feel they should not be throwing away goodwill > > > on this issue. > > > > Finally, "OSGi Advocates" are not an aggregated mass. I am a single > > > opinionated loudmouth. Hating other OSGi advocates for what I say is > > > just stupid. > > > > Regards, > > > Neil > > > > On Mar 26, 4:40 pm, Reinier Zwitserloot <reini...@gmail.com> wrote: > > > > > I'd like to 'me-too' Romain Guy and say that OSGi advocates annoy me. > > > > There it is, OSGi advocates. Do with this information what you wish. > > > > Just know that whipping on any attempt of Sun to join the > > > > modularization game is exactly what makes people want to hand you some > > > > valium, so - spectacularly- well done on proving Romain Guy's point. > > > > > I don't like jigsaw's sparse technical documentation either, but I do > > > > know that having a 'module' keyword is fantastic, and having a sun > > > > java installer that is modularized is similarly fantastic. > > > > > On Mar 26, 1:50 pm, Weiqi Gao <weiqi...@gmail.com> wrote: > > > > > > Neil Bartlett wrote: > > > > > > Romain, it's not like that at all. I believe there will be huge > > > > > > damage > > > > > > to the Java ecosystem from having multiple competing module systems. > > > > > > You want to write a module, which module system do you support? It's > > > > > > as bad as what Microsoft tried to do to Java. > > > > > > > If you don't want to use OSGi I really really don't mind. If you > > > > > > want > > > > > > to fracture the Java platform, I mind a lot. > > > > > > It seems to me that OSGi is the fracturing force. So could OSGi > > > > > please > > > > > just go away? > > > > > > I have nothing against OSGi and the above paragraph is merely to > > > > > illustrate a point. The point is that fracturing is inevitable. The > > > > > sooner the vendors start to thinks of ways to make their pet > > > > > mechanisms > > > > > work together for their customers the better. > > > > > > Just because some one invented OSGi twenty years ago doesn't mean > > > > > others > > > > > can't invent something similar to counter it. Think IE vs. Netscape, > > > > > C# > > > > > vs. Java, Eclipse vs. NetBeans, SWT vs Swing, Ruby vs. Smalltalk and > > > > > Perl, Gcj vs. Harmony vs. the JDK, Scala vs. Erlang, JavaFX vs. Flex > > > > > vs. > > > > > Silverlight, java.util.logging vs. Log4j, SOAP vs. CORBA, etc. The > > > > > list > > > > > goes on and on. And all the UNIXes. And all the Linux distributions. > > > > > And Windows vs. the Mac. And the GPL vs. the Apache License. > > > > > > Fracture leads to variety and variety leads to survival. > > > > > > Trying to get the whole world to use only one mechanism is not going > > > > > to > > > > > work. > > > > > > Had Sun allowed Java to fracture a little on Windows, we would be > > > > > writing Windows applications in Java rather than in C#. > > > > > > Had Sun not allowed Java to be implemented elsewhere and in > > > > > non-conforming ways, we would be writing Android applications in some > > > > > other language. PHP perhaps. I don't know. > > > > > > > On Mar 26, 8:12 am, Romain Guy <romain....@mac.com> wrote: > > > > > >> Technical merits aside, the OSGi advocates are really starting to > > > > > >> piss > > > > > >> me off. They go rant against anything that is even remotely like > > > > > >> OSGi > > > > > >> and they go rant against anything that doesn't use OSGi and could > > > > > >> perhaps potentially use it. This is *not* a good way to advocate a > > > > > >> technology. > > > > > > >> On Mar 25, 5:37 pm, JodaStephen <jodastep...@googlemail.com> wrote: > > > > > > >>> Joshua Marinacci said > > > > > >>> "Jigsaw is the modularity planned to be built into the JDK. It's > > > > > >>> purpose in life is to make the JRE modular. No other modules > > > > > >>> system, > > > > > >>> including OSGI, has the ability to do that because they simply > > > > > >>> can't > > > > > >>> work at a low enough level to make things work (such as JVM > > > > > >>> changes). > > > > > >>> Of course that conveniently ignores Apache Harmony, which is a JDK > > > > > >>> modularised using OSGi. I think you'll find there are some deeper > > > > > >>> forces going on here. > > > > > >>> phil.swenson said: > > > > > >>> "jigsaw is core to Java 7 isn't it?" > > > > > >>> No. Jigsaw is core to JDK7, not Java7. Huge difference. > > > > > >>> Stephen > > > > > > -- > > > > > Weiqi Gao > > > > > weiqi...@gmail.comhttp://www.weiqigao.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
