EclipseZone - Glassfish to become modularised ...

The Rich Engineering Heritage Behind Dependency Injection

Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.

Java, the OLPC, and community responsibility

The "One Laptop Per Child" project has a great device ready to ship, but there's no Java on there. Let's think about working together to put Java on OLPC!

Replies: 22 - Pages: 2 [ 1 2 | Next ]
Threads: [ Previous | Next ]

Reply 1. At 11:17 AM on Mar 23, 2007, Chris Aniszczyk wrote:: Re: Glassfish to become modularised
I like your style.
Reply 2. At 11:52 AM on Mar 23, 2007, Jens Eckels wrote:: Re: Glassfish to become modularised
+1
There's sometimes a romance to being the "other guys" to an establishment (i.e. Apple/Mac), but you have to wonder in situations like this what the motivation is...; Jens, MyEclipse Eclipse Plugins, AJAX, J2EE, JSP, Web Services, Struts, JSF, JPA, MyEclipse Blog
Reply 3. At 11:55 AM on Mar 23, 2007, Steve Northover wrote:: Re: Glassfish to become modularised
It's called "Not Invented Here".

Steve
Reply 4. At 12:17 PM on Mar 23, 2007, Alex Blewitt wrote:: Re: Glassfish to become modularised
Yeah, but in that situation, the "other guys" are better
Reply 5. At 12:23 PM on Mar 23, 2007, Jens Eckels wrote:: Re: Glassfish to become modularised
Touché.; Jens, MyEclipse Eclipse Plugins, AJAX, J2EE, JSP, Web Services, Struts, JSF, JPA, MyEclipse Blog
Reply 6. At 4:35 PM on Mar 23, 2007, Jerome Dochez wrote:: Re: Glassfish to become modularised
actually it has nothing to do with NIH, it is pragmatism.

OSGi is a bit too big/complex for what we want to achieve, modsys is under 50Kb of code (which help our startup time quite a bit). I have added many hooks so we can support all types of modules like OSGi and maven for instance therefore it's pretty much open to any modules type. There is little doubt we will support some OSGi bundles at some point. We will however probably never need a be a full OSGi container.

Another reason is that we want to have a model which will ideally transition nicely with the JSR277 work that will appear in Java SE 7. Hence most of the current modsys interfaces are loosely based on the current 277.

The idea is that modsys.dev.java.net (for the modules/class loading) part would mainly become obsolete once 277 materializes in the JDK and we don't want to have to change too much GlassFish when that happens. Having modules and class loaders natively handled by the JVM is probably a good thing, and that should be irrespective on how modules are defined.

Of course this is still very early and the GlassFish community may influence these choices.
Reply 7. At 5:47 PM on Mar 23, 2007, Alex Blewitt wrote:: Re: Glassfish to become modularised
> actually it has nothing to do with NIH, it is pragmatism.

Fair enough. It would be good to know what the pragmatic issues are.

> OSGi is a bit too big/complex for what we want to
> achieve, modsys is under 50Kb of code (which help our
> startup time quite a bit).

Interesting. But this is only 0.1-SNAPSHOT release, right? You surely haven't finished implementing it. I'd bet that by the time it goes 1.0 (and a real 1.0, none of this Groovy 1.0-RCrandom() crap for years) that it's significantly more than 50k.

Did you know that Knopflerfish tiny is 278k?

http://www.knopflerfish.org/releases/2.0.1/knopflerfish_osgi_tiny_2.0.1.zip

OK, so that's 5x what your current version is, but it's been tested for some time. Similarly, ProSyst has an implementation (based on R3) which is 230k

http://www.prosyst.com/datasheets/mBS/mBS_CLDC_Edition_1.0.pdf

> I have added many hooks so
> we can support all types of modules like OSGi and
> maven for instance therefore it's pretty much open to
> any modules type.

OSGi is more than modules, and to underestimate it means that you won't be able to support it later. It defines the way in which classloading occurs and the lifecycle, rather than statements like:

Module subsystem should notify modules when the module is loaded, started or stopped. A module can only be loaded once within a class loader, however, it can be started and stopped multiple times. Modules which are not used are elected by the module subsystem for garbage collection. Once a module is garbage collected, the runtime will stop the module and then ï¬‚ush its class loader. After this operation, the JVM will be in a state equivalent to the module never being loaded. If the module is re-loaded, it will use a new class loader, hence all static variable and initialization will need to be redone.

> We will however probably never need a be a full OSGi
> container.

To underestimate what you'll need is to ignore history. Eventually, you'll end up developing something and going through the same learning process as the OSGi did, except six years later.

> Another reason is that we want to have a model which
> will ideally transition nicely with the JSR277 work
> that will appear in Java SE 7. Hence most of the
> current modsys interfaces are loosely based on the
> current 277.

So, instead of using a well-defined, well-tested system to implement a modular architecture (and, it should be noted, one that every other competitor - IBM, BEA, JBoss already uses), you're basing it on a specification which hasn't even been implemented yet? I'm intrigued. Why that choice?

> The idea is that modsys.dev.java.net (for the
> modules/class loading) part would mainly become
> obsolete once 277 materializes in the JDK and we
> don't want to have to change too much GlassFish when
> that happens. Having modules and class loaders
> natively handled by the JVM is probably a good thing,
> and that should be irrespective on how modules are
> defined.

This is a circular argument. You're basing it on JSR277 because you want it to be based on JSR277, and then justify that by saying that this is a Good Thing and that this will involve less changes to base it on JSR277. You might as well argue it makes sense to implement it in Ruby, because then there will be less changes when you finally use Ruby.

> Of course this is still very early and the GlassFish
> community may influence these choices.

So if the GlassFish community didn't start this idea, who did?

Alex.
Reply 8. At 6:10 PM on Mar 23, 2007, Neil Bartlett wrote:: Re: Glassfish to become modularised
There's another open source OSGi runtime called Concierge which weighs in at under 80k, although it is R3 only: http://concierge.sourceforge.net/

However this completely misses the point: Glassfish is an implementation of the Java Enterprise Edition specification. OSGi, particularly Concierge, is designed to run in resource constrained environments such as mobile phones or vehicle engine management systems as well as standard desktop and server systems.

Since when was Java EE concerned with resource-constrained environments or saving a few hundred K? Isn't it far more important to build a robust platform on a mature, well designed core?
Reply 9. At 8:03 PM on Mar 23, 2007, Jerome Dochez wrote:: Re: Glassfish to become modularised
> > actually it has nothing to do with NIH, it is
> pragmatism.
>
> Fair enough. It would be good to know what the
> pragmatic issues are.
>
> > OSGi is a bit too big/complex for what we want
> to
> > achieve, modsys is under 50Kb of code (which
> help our
> > startup time quite a bit).
>
> Interesting. But this is only 0.1-SNAPSHOT release,
> right? You surely haven't finished implementing it.
> I'd bet that by the time it goes 1.0 (and a real 1.0,
> none of this Groovy 1.0-RCrandom() crap for years)
> that it's significantly more than 50k.

actually I hope not. most of the innovation will come on top of the module/class loading which actually can run on OSGi runtime out of the box since I have put in place APIs to isolate from the actual module/class loading.

>
> Did you know that Knopflerfish tiny is 278k?
>

yes I know knopferfish, it is a very good OSGi distrib.

> http://www.knopflerfish.org/releases/2.0.1/knopflerfis
> h_osgi_tiny_2.0.1.zip
>
> OK, so that's 5x what your current version is, but
> it's been tested for some time. Similarly, ProSyst
> has an implementation (based on R3) which is 230k
>

I have not heard such good things on R3 but that's beyond the point.

> http://www.prosyst.com/datasheets/mBS/mBS_CLDC_Edition
> _1.0.pdf
>
> > I have added many hooks so
> > we can support all types of modules like OSGi
> and
> > maven for instance therefore it's pretty much
> open to
> > any modules type.
>
> OSGi is more than modules, and to underestimate it
> means that you won't be able to support it later. It
> defines the way in which classloading occurs and the
> lifecycle, rather than statements like:

right and that's some of the problems I have with it. I just want modules and class loaders, not much else.

>
>

> Module subsystem should notify modules when the
> module is loaded, started or stopped. A module can
> only be loaded once within a class loader, however,
> it can be started and stopped multiple times. Modules
> which are not used are elected by the module
> subsystem for garbage collection. Once a module is
> garbage collected, the runtime will stop the module
> and then ï¬‚ush its class loader. After this
> operation, the JVM will be in a state equivalent to
> the module never being loaded. If the module is
> re-loaded, it will use a new class loader, hence all
> static variable and initialization will need to be
> redone.
>

>
> > We will however probably never need a be a full
> OSGi
> > container.
>
> To underestimate what you'll need is to ignore
> history. Eventually, you'll end up developing
> something and going through the same learning process
> as the OSGi did, except six years later.
>

not me, I am planning to delegate that work to the 277 expert group really...

> > Another reason is that we want to have a model
> which
> > will ideally transition nicely with the JSR277
> work
> > that will appear in Java SE 7. Hence most of
> the
> > current modsys interfaces are loosely based on
> the
> > current 277.
>
> So, instead of using a well-defined, well-tested
> system to implement a modular architecture (and, it
> should be noted, one that every other competitor -
> IBM, BEA, JBoss already uses), you're basing it on a
> specification which hasn't even been implemented yet?
> I'm intrigued. Why that choice?

you are not intrigued, you just want to sell me the technology you like ! Note that I do like OSGi too, however, I think relying on the JDK is the way to go, I would love to see 277 and OSGi meet somewhere...

as for the well-defined well tested argument, it's only valid to a certain extent. For instance, applying blindly we would still be doing cobol and cics. Innovation is important. Again, don't try to drag this into a OSGi/277 fight I think it would be more constructive to try to influence both crowds to come to a mutually beneficial solution.

>
> > The idea is that modsys.dev.java.net (for the
> > modules/class loading) part would mainly become
> > obsolete once 277 materializes in the JDK and
> we
> > don't want to have to change too much GlassFish
> when
> > that happens. Having modules and class loaders
> > natively handled by the JVM is probably a good
> thing,
> > and that should be irrespective on how modules
> are
> > defined.
>
> This is a circular argument. You're basing it on
> JSR277 because you want it to be based on JSR277, and
> then justify that by saying that this is a Good Thing
> and that this will involve less changes to base it on
> JSR277. You might as well argue it makes sense to
> implement it in Ruby, because then there will be less
> changes when you finally use Ruby.

sure if I wanted to migrate to Ruby, I think starting by implementing some part of the system in Ruby would make perfect sense.

>
> > Of course this is still very early and the
> GlassFish
> > community may influence these choices.
>
> So if the GlassFish community didn't start this idea,
> who did?

I never said it did not start it, I just said things may still be changed.

Jerome

>
> Alex.
Reply 10. At 1:39 AM on Mar 24, 2007, Sean GAO wrote:: Re: Glassfish to become modularised
+1.
Nice point, Alex!; When the going gets tough, the tough gets going.
Reply 11. At 4:53 PM on Mar 24, 2007, Alex Blewitt wrote:: Re: Glassfish to become modularised
> Interesting. But this is only 0.1-SNAPSHOT release,
> right? You surely haven't finished implementing it.
> I'd bet that by the time it goes 1.0 (and a real 1.0,
> none of this Groovy 1.0-RCrandom() crap for years)
> that it's significantly more than 50k.

> actually I hope not. most of the innovation will come on top of the module/class
> loading which actually can run on OSGi runtime out of the box since I have put in
> place APIs to isolate from the actual module/class loading.

I'm not sure what you're saying here. Does this mean that modsys will run on top of OSGi? If so, what exactly is the point? Or do you mean to imply that OSGi will run on top of modsys? The latter won't work -- OSGi *is* the module system, and so there's very little point of it sitting on top of another module system which it won't end up using.

> > OSGi is more than modules, and to underestimate it
> > means that you won't be able to support it later. It
> > defines the way in which classloading occurs and the
> > lifecycle, rather than statements like:
>
> right and that's some of the problems I have with it.
> I just want modules and class loaders, not much else.

Remember what modsys is being designed for, as an under-the-hood implementation of J2EE servers, which are not known for their memory or resource constraints.

Furthermore, there's a lot of things that you might find you need later, even if you think you'd only need modules. In any case, you're missing one of the main points, which is even if you don't need everything (and bear in mind that the KF tiny distribution only contains the mandatory layers, and not the optional ones e.g. DS) that it's still a well-tested and tried module system that's gone through all of the learning of finding the problems (e.g. what classes are visible from what classloaders, ensuring that bundles don't start up if there's an inconsistent set of dependencies, what happens in the case of multiple versions etc.) which would solve the problems modsys is trying to solve immediately.

In addition, Glassfish would then be able to use other OSGi bundles natively without any kind of mapping layer which may not achieve what you want.

> > To underestimate what you'll need is to ignore
> > history. Eventually, you'll end up developing
> > something and going through the same learning process
> > as the OSGi did, except six years later.
> >
>
> not me, I am planning to delegate that work to the 277 expert group really...

How can you start putting together modsys when there's only an early access draft which does a lot of hand-waving about how module lifecycle is supposed to work? Surely you're going to need to wait until there's some kind of draft (or TCK) before you can start putting this together? Or is this a Sun-funded project that will try to be a JSR277 reference implementation?

> > I'm intrigued. Why that choice?
>
> You are not intrigued, you just want to sell me the technology you like !
> Note that I do like OSGi too, however, I think relying on the JDK is the
> way to go, I would love to see 277 and OSGi meet somewhere...

I'm still intrigued as to why you would choose to base this on a non-existent specification with 0 years proof in the field, versus a solid specification that has been in use for over 6 years, unless this is the planned JSR277 reference implementation work. Regardless of which may be my preferred solution (and bear in mind there's nothing to prefer with 277 since it doesn't exist yet), I'm intrigued as to why anyone would risk basing it on a moving specification.

In any case, it's somewhat irrelevant; 277 *isn't* in the JVM yet, and there's no guarantee that it will be. Even when 277 is finished, there will still be many JVMs that don't have it installed, so the adoption is likely to be a long way down the road.

OSGi and JSR277 could come together; but the 277 JSR EG don't appear to want to come and join the OSGi party, preferring to stand alone in the corner with a lone drink and not talking to anyone.

Alex.
Reply 12. At 2:15 AM on Mar 25, 2007, Alexis MP wrote:: Re: Glassfish to become modularised
Alex, why are you over-simplifying and trying to make this sounds it has to be an either/or between OSGi and JSR277? Really, this is not the point.

I would also be interested in knowing what *you* would gain from GlassFish using "straight" OSGi and I'd much rather have this discussion happen in the GlassFish community (forums, mailing lists, user experience meetings, ...). You are most welcome to join.
Reply 13. At 4:57 AM on Mar 25, 2007, Alex Blewitt wrote:: Re: Glassfish to become modularised
Thanks for the invite, but I'm already involved in too much community stuff at the moment.

What I would gain from GlassFish being OSGi? Right now, absolutely nothing. I don't use it. To that extent, it doesn't affect me personally or professionally at all.

However, all the other major players (WebSphere, Weblogic, JBoss) are already using or moving towards an OSGi runtime. That means if I wanted to target extensions for those servers at some point in the future, I'm going to target the technology that's got the biggest market share, which will be OSGi. Will I bother writing something that works for modsys? Not really; that's only one of the implementations and an equivalent size customer base to other open-source servers (which historically, have less money than their commercial counterparts).

In the IDE space, each one of IntelliJ/NetBeans/Eclipse has their own plugin system, and none of them are compatible. Wouldn't it be great to be able to use plugins/libraries interchangeably on these systems?

In the server world, the choice has already been made to use OSGi by the big commercial backers. I therefore wondered aloud what possible benefits there can be for GlassFish bucking the trend and doing its own thing.

As for the either/or for OSGi or 277 -- it's more like either/nor. There is no 277 at the moment; there are at least four implementations of OSGi already available (three of which are open source).

If you're going to build some kind of compatibility layer for 277, do it on *top* of OSGi. Don't take the simplistic view that OSGi is another layer that you can bind on top of another module system; OSGi *is* the module system.

Alex.
Reply 14. At 5:38 AM on Mar 25, 2007, Alexis MP wrote:: Re: Glassfish to become modularised
I really think we're not having this (valuable) discussion in the right place and I still think you're looking at it only thru the OSGi lens (you did mention it 9 times in your last post! )