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 e.g. http://www.osgi.org/blog/2008/12/project-jigsaw.html - and the OSGi team is talking back. It's the fanboys like yourself that are still militant. > > Point me at some vitriol or whining and I will go and tell off the > author. That is, if I agree with you that it's vitriolic or whining. > If not, I implore YOU to stop whining. > Google around for any blog post about OSGi and jigsaw. See above link where an OSGi alliance member himself raises the word 'violently' to describe OSGi fan reaction to the versioning scheme (which is another nice point: Jigsaw's is clearly superior; the decision in OSGi that text implies a newer version is ridiculous). Here's a troll that suggests using OSGi could _get you fired_. Holy crap. That's quite a statement. Not to mention that it asks the user a false choice: http://neilbartlett.name/blog/2009/03/25/using-suns-jigsaw-may-get-you-fired/ I have a nagging feeling you're going to side with the author on that one, for some strange reason :P > So, which member would you like to "grow up"? IBM? Oracle? Red Hat? > SAP? Sun...? The fanboy crowd, actually. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
