Hello Reinier, Some responses inline below. I consider myself in the so-called OSGi "camp", though I am not an OSGi Alliance member nor do I speak for the Alliance or any of its members.
On Jun 20, 12:35 am, Reinier Zwitserloot <[email protected]> wrote: > I think the jigsaw team spelled it out pretty well: 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). Nevertheless it's useful to see *something* in terms of requirements, I'd appreciate it if you could point me to where you read them. > 1. There are things OSGi can't do that we deem important. > Specifically: > > - Run different modules into the same classloader if you so choose. > (OSGi being incapable of doing this annoys me to no end - low level > operations can get really thrown off if you can't do this, and the jvm > core is obviously filled to the brim with these) 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. But since an OSGi bundle is just a JAR plus metadata, you can add that JAR to your bundle classpath, or load it dynamically using a URLClassLoader. 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. > - Move modularization into the runtime (OSGi's modularization support > is awkward and annoying at runtime, through no fault of their own, > because java just doesn't support it in v1.6 and down!) - WITHOUT > needing to wait for OSGi to get with the program. This is a bit more > contentious, perhaps, but java moving fast for a change - I can't > really bring myself to complain about it. 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. If OSGi needs technical changes to make that work, then Sun should just go ahead make those changes. Hopefully they would then come back to the OSGi Alliance and tell the other members what had to be changed, so those changes could be incorporated into the specification for future releases. That would be very welcome, and it would not need to slow down the development of Java at all. However instead of 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. > - Keep things simpler by excluding e.g. lifecycle management. Simpler > is another one of those things. 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? OSGi is specified in layers. You don't want to think about dynamics and lifecycle, then don't use them. You can benefit from the modularity layer of OSGi without ever needing to learn about lifecycle, if you so chose. > I also believe the jigsaw guys made a decent case that OSGi can > probably adapt quite easily to be able to work flawlessly with jigsaw > modules (but not the other way around, as OSGi is a lot heavier in > certain areas). 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. Why is OSGi heavier? 29 core classes, of which 14 are interfaces. > I'm not _certain_ this is true, of course, and the > sheer vitriol and whine spilling out of the OSGi camp 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. > makes me think > they might just be juvenile enough to obstinately refuse to write > support for jigsaw modules into OSGi (seriously, OSGi people, grow > up!). Here's how support for Jigsaw or anything else can get into OSGi. First an RFP (Request for Proposal) is written by somebody who is interested in doing so. Anybody can do this, it is just a simple requirements document. Then the OSGi core platform expert group (of which Sun is a member) will vote on whether to create an RFC, which is a work-in-progress specification document. Only OSGi members can work on RFCs, but again, Sun is a member so they can participate fully. Finally the RFC is written into the specification and implementers such as Eclipse Equinox and Apache Felix can build the support. No individual member company of OSGi can "obstinately refuse" to support Jigsaw (unlike the JCP, no member has any special veto), and if Jigsaw support is defined by the core specification then no OSGi implementation can leave it out and remain a compliant implementation. So, which member would you like to "grow up"? IBM? Oracle? Red Hat? SAP? Sun...? > Nevertheless I hold high hopes that this will happen, and that > it won't require that much work for the OSGi camp. Therefore, the > 'this will split the java world in twain' argument is FUD. I believe you are being over-optimistic about the chances for interoperability, but let's see. Even if they interoperate, it will suck if developers have to understand two or more module systems and work with them in parallel in the same application. > > On Jun 18, 2:12 am, Steve <[email protected]> wrote: > > > > > On Jun 12, 1:17 pm, Augusto Sellhorn <[email protected]> > > wrote: > > > > I'm kind of surprised there's not a lot more discussion around Jigsaw > > > since it includes such fundamental changes, and there's till the whole > > > controversy around Sun not leveraging OSGi. > > > My ill-informed take on this is: > > - modularity inside Java itself is obviously a good thing > > - if OSGi was not an appropriate choice for that, then Sun coming up > > with their own module system is fine for the task of modularising the > > jvm > > - bringing the concept of modules to the language itself is also a > > good thing > > > The issue is when Jigsaw is positioned as something *application* > > developers might want to leverage, I can't see how that cannot result > > in fragmentation (for example, finding 3rd party libraries with OSGi > > metadata is already difficult, asking developers to support OSGi *and* > > Jigsaw is not going to endear them to the cause of java modularity). > > > The podcast interview was good (they always are:) however the guys > > should have nailed them more on why we need another module system > > targeted at application developers (as opposed to intra-vm stuff). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
