So, 'none of the reasons cited are good reasons'. Okay. Says you. That was a big part of my rant: OSGi folk just piss all over jigsaw without -EVER- mentioning anything constructive except that tired old bitty of 'There is no point' and 'It will fracture the market'. The podcast quite clearly explained that jigsaw has overlap with OSGi, but there are things OSGi can do that jigsaw can't (read: jigsaw is easier in some respects), *and vice versa* (jigsaw fulfills certain requirements that OSGi cannot). Hence, there IS a point, and the modularization (heh) of finding resources means that it won't fracture the market nearly as much as most OSGi folk think it will.
You say that the OSGi community is very open and welcoming, and yet your reply is anything but. I've *never* seen anybody involved with jigsaw throw stones at OSGi. Ever. Quote, please. On Jun 22, 2:35 pm, Eric <enewco...@gmail.com> wrote: > I have to say I these strong statements about OSGi are very > uninformed. Nor does the cleverness of the language improve their > credibility. > > None of the reasons cited are a good reason to invent a new module > system, i.e. Jigsaw. It would be better for the industry to kill it, > and the sooner the better: > > http://modualrit.blogspot.com/2009/06/kill-project-jigsaw-now-please.... > > If speed to market is an issue, inventing something new is actually > slower. Unless of course the argument is that Java is not, and never > was, a standard but rather a product developed by Sun who can > therefore do anything they like with it, regardless of any other > vendor's investment. I have not heard that said before, but perhaps > that's your position? > > OSGi has existed for 10 years, is used in thousands of technologies > and projects, is mature, widely adopted, and proven to work. Lots of > people would like new things to become standards, but it's impossible > to achieve that simply by wishing it to be so. It takes many many > years for new technologies to become widely adopted. We have two guys > saying don't worry, we'll take care of all of those external forces by > ourselves, and get Jigsaw as widely adopted and accepted as OSGi > already is. > > It is also a provable fact that the OSGi Alliance runs an open > process, and that OSGi folks have participated in JSR 294 from the > beginning. They would have participated in Jigsaw if they had been > able to. > > Many of the arguments are not in dispute. Everyone acknowledges the > benefits of including modularity in the language. However, it can also > be shown that it's infeasible to guarantee consistency of modules > through the language/compile/runtime/packaging stages. This remains a > very theoretical argument. In fact what we are seeing is the "theory" > and "promise" of Jigsaw being compared to the reality of OSGi. The > problem is not the need for modularity, but the promises since the > beginning of Jigsaw that the Jigsaw project would work within OSGi to > ensure compatibility. These have been completely empty words - why > don't you spend a little time researching the Jigsaw/JSR 294 > statements about their intention to "harmonize" what they're doing > with the OSGi community, and see if any one of them has done anything > to back up their statements? > > One question: if someone says they're going to do something and they > do not, is pointing that out a fair criticism? > > I take very strong exception to the criticism of the OSGi community. > Having been a member of that community for nearly three years now, I > can say for sure that it is the most open and welcoming community I've > ever participated in (including BTW the JCP). I have personally > reached out to Sun members on several occasions to encourage them to > participate more actively but they apparently prefer to sit outside > and throw stones, and somehow manage to convince others who have > little or no experience with OSGi to do the same. > > Eric > > On Jun 20, 6:34 pm, Reinier Zwitserloot <reini...@gmail.com> wrote: > > > Responses inline. > > > On Jun 20, 11:33 am, Neil Bartlett <njbartl...@gmail.com> wrote: > > > > I haven't seen these requirements stated directly by the Jigsaw team > > > (if indeed there is a team, I thought it was just Mark Reinhold). > > > Listen to the podcast. The 'team' is Buckley and Reinhold, and the > > requirements were said on the podcast. > > > > OSGi certainly can do this. Bear in mind that without a classloader > > > for the module, it's not really a module because it has no enforced > > > separation from any other code sharing the same classloader. > > > Of course its a module. Just because they have no enforced *RUNTIME* > > separation makes them not a module? You can't take the english word > > 'module', tack an arbitrary definition on top of this, and them point > > at other people using the word and say they are doing it wrong. > > > If I create 10 eclipse projects, and carefully orchestrate the project > > dependencies of these eclipse projects, I just rolled myself a module > > system. It's a compile-time only module system, certainly, but it is > > nevertheless a module system. Projects larger than a manyear or two > > that aren't split up like this (handrolled as such, or via e.g. OSGi), > > are going to become unmaintainable very very quickly, so this isn't > > just a little 'gimmick' - it's of crucial importance. > > > This was a big part of the spiel by Reinhold and Buckley: A module > > system is something that exists both at compile/write/deploy time, and > > at runtime, and the concerns are very different between those two > > modes of operation. From what I heard, jigsaw does an excellent job in > > being flexible enough to serve for any situation. Nice case in point: > > There are *PLENTY* of times when I really, -really- do not need *ANY* > > runtime module separation, but it would be nice if I could roll up > > some module spec that mijn build tools and IDEs all understand, and > > that will cause them to automatically go ahead and find dependencies. > > > Jigsaw can more or less do this. So can OSGi, but OSGi also FORCES > > various other concerns on me, many of which are related to runtime > > separation. > > > > I'm not sure why this is a requirement since it just drags you back > > > down to the old non-modular classpath-based approach (and the same > > > will be true for Jigsaw when they do this... the classpath lives!), > > > but nevertheless it's there if you need to do it. > > > What are you talking about? > > > The classpath has two crucial properties: 1) a method which finds > > classes (and data files) by scanning through a list of file system > > locations, and 2) This list is effectively global for that instance of > > the JVM. > > > This just isn't true for jigsaw, even when using local deps. The idea > > behind a local dep is that you use N compile-time modules to construct > > 1 runtime module. There are lots of situations where this is > > *CRUCIAL*, and I find your inability to grok this very telling for > > what I'm hearing form the OSGi camp (namely: They are sticking their > > fingers in their ears and yelling loudly). > > > As Reinhold and Buckley specifically mentioned: In jigsaw, quite > > unlike OSGi, 'split packages' is perfectly fine. This is excellent > > news, because you can modularize not just vertically, but also > > horizontally. > > > Example: > > > java.nio.Buffer has support for OS lowlevel directly linked buffers > > for e.g. networking. There are plenty of uses for those, such as > > rapidly reading out files, using an OS level shared buffer (you use > > those on e.g. mac os x to share e.g. raw video data, as on mac os x > > you can't just hand your window ID to another app and let them write > > in your window; mac os x doesn't allow that for security reasons. This > > is how the mplayer frontend works - it fires up an mplayer instance > > and blits video data through a shared buffer!) - or, of course > > networking. The shared buffer stuff should probably be a separate > > module, and should probably exist as a unique module per target OS. > > > I can easily imagine that there are useful package private methods in > > java.nio.Buffer that such implementations need. OSGi just makes this > > needlessly complicated. Jigsaw just lets you get to work. > > > > This is quite funny. Of course OSGi cannot move into the runtime > > > (presumably you mean the JRE) without co-operation from Sun, because > > > Sun owns the JRE. If Sun choses to implement the OSGi specification > > > within the JRE then voila, OSGi is in the JRE. > > > Isn't that just what I said? I only added that sun chose to roll their > > own because they presumed it was going to be faster than working with > > OSGi. Given the political storm OSGi's been cooking up, so far they > > appear to be in the right on that topic. Still, you're right, on this > > singular aspect they probably could have worked with OSGi just as well > > or better. However, in light of the other requirements that OSGi > > doesn't meet, the decision to roll their own makes more sense. > > > > If OSGi needs technical changes to make that work, then Sun should > > > just go ahead make those changes. > > > You're saying : Sun ought to have forked OSGi. > > > Who gives a crap? Seriously - that's an implementation detail. > > Neither you, nor I, nor anybody in the OSGi camp could possibly know > > which strategy would lead to the best implementation in the least > > amount of time. It could very well be that forking OSGi appeared to > > cause more complexity than it would solve. > > > > starting from OSGi and changing it where it needed to be changed, Mark > > > has chosen to write a whole new module system from scratch, thus > > > delaying the release of Java 7 still further... and he won't explain > > > why. > > > Mark was quite adamant that attempting to work with OSGi would have > > caused far more of a delay than rolling his own. > > > > Remove chapters 4, 5, and 8 from the OSGi core specification: you now > > > have a module system specification without lifecycle management. How's > > > that for simplicity? > > > But then it wouldn't be OSGi. Which would be confusing. So they called > > it jigsaw. > > > > We would very much like to work with Jigsaw, if it comes into > > > existence and if we possibly can, and we would also like to help > > > Jigsaw interoperate with OSGi. The channels of communication are open, > > > but it takes two to tango. > > > It takes two to tango? Seriously? Man, you OSGi people get on my > > nerves. Do you not see how presumptuously arrogant this looks? It's > > the OSGi camp that's been insulting any attempt by sun to create a > > module system that doesn't involve saying "We'll copy and paste OSGi > > verbatim into the JRE". If I was sun, I would have stopped giving a > > care in the world about OSGi a long long time ago. The jigsaw team is > > still trying to communicate with OSGi. See > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
