EclipseZone - JSR 291 passed ...

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: 9 - Pages: 1
Threads: [ Previous | Next ]

Reply 1. At 3:56 PM on Jan 23, 2007, Paul Davis wrote:: Re: JSR 291 passed
Any idea who will be creating the reference implementation?
Reply 2. At 4:33 PM on Jan 23, 2007, Glyn Normington wrote:: Re: JSR 291 passed
> Any idea who will be creating the reference implementation?
We plan to use Eclipse Equinox which already contains a prototype of the draft OSGi spec. that comprises JSR 291.
Reply 3. At 8:51 PM on Jan 23, 2007, Mike Milinkovich wrote:: Re: JSR 291 passed
> We plan to use Eclipse Equinox which already contains
> a prototype of the draft OSGi spec. that comprises
> JSR 291.

Since Equinox is EPL'd, that then addresses Apache's questions about an open source RI, doesn't it?; Executive Director, Eclipse Foundation, blog: milinkovich.blogspot.com
Reply 4. At 10:32 PM on Jan 23, 2007, Alex Blewitt wrote:: Re: JSR 291 passed
Other OSGi engines are also open source, but Apache's comment was probably meant to suggest choosing one (from Felix/Knopflerfish/Equniox) rather than there not being one:

As we noted in the review ballot, we encourage you to choose an open source implementation as the RI, and deliver the TCK as open source software.

Interesting question about the TCK though -- what/who is going to implement that? There isn't one of these at the moment.

Alex.
Reply 1. At 12:04 PM on Jan 24, 2007, Fred Grott wrote:: Re: JSR 291 passed
RIs are:

Eclipse Equinox

Apache Oscar

Knopflerfish is also under LGPL or GPL; Fred Grott, ShareMe jabber:fg82183@conference.javalobby.org(shareme) Official contributor to EclipseZone.com and supporter of JavaLobby.org.
Reply 5. At 3:59 PM on Jan 24, 2007, BJ Hargrave wrote:: Re: JSR 291 passed
> Interesting question about the TCK though -- what/who
> is going to implement that? There isn't one of these
> at the moment.

OSGi already has a TCK which will be extended to cover the new 4.1/JSR 291 function. This TCK will be licensed at no cost to qualified open source orgs like Apache and Eclipse. In fact, Apache and Eclipse have been provided the no-cost license for the current 4.0.1 TCK and are reviewing it prior to access.

Unfortunately, I don't see the TCK being open sourced at this time.
Reply 6. At 4:00 PM on Jan 24, 2007, BJ Hargrave wrote:: Re: JSR 291 passed
> Apache Oscar

I think you mean Apache Felix
Reply 7. At 6:09 PM on Jan 28, 2007, Alex Blewitt wrote:: Re: JSR 291 passed
A few interesting observations at kapustein.com/blog regarding OSGi and JSR277. It seems that the JSR277 is being proposed by committee, rather than actually being based on soliciting feedback (which incidentally, was one of the reasons that Sun voted 'no' on the JSR291).

So given the landscape for Java these days, JAR Hell is at least as likely as in the “good ‘ole days” of OCX/DLLHell.

OSGi (mostly) solves that problem.

JSR 277 (Modules) strives to help solve the same space.

But…OSGi is real, live, working code, with years of field experience in real world use. It’s the basis for Eclipse’s plug-in support, among others. It works. It’s proven. Sure, it’s got a few warts, but it seems it would take a small effort to smooth those out, and in ways that wouldn’t orphan existing users.

JSR 277 is…in committee. I delved into this in some detail at JavaOne. I talked to several people. I attended the JSR 277 BoF. I talked to the JSR lead. I’m unimpressed. And not just technically.

In fact, the Not Invented Here attitude seems to be prevalent in this opinion piece:

The JSR lead in particular (I forget his name offhand) was a real prick about it. I asked about the SxS [side by side] scenario - the fundamental and thorny problem in this space - and he blew me off. (And a few others in the JSR standing around) acknowledged it’s a problem (once they understood the scenario - scary part: I had to explain it, in detail. They didn’t know it and kept proposing ’solutions’ that weren’t. Which is telling in its own right, but that’s another issue.) The lead told me the spec would make things clearer, I asked where I could find more info so I could come up to speed and, if my concerns weren’t addressed as a I feared, contribute to the dialogue. I was told the spec will be out in ‘a few weeks’. I said great, but then it’s pretty much locked down short of a major catastrophe, can I get a copy sooner, and I was told the JSR materials are not public until that spec comes out.

Let’s recap:
* I’m not a member of the JSR (and wouldn’t be able to join any time soon)
* JSR material was private
* By the time the spec was publicly accessible, it’s pretty much locked down and just looking for refinements
* OSGi, a seemingly working solution, is being ignored in favor of a totally differnet solution from the ground up
* JSR 277 wouldn’t ship for 2+ years (JSE 6 wasn’t expected for another 6 months at that point, let alone 7)
* JSR 277 would only solve half the problem, and not the realy important one
* The spec lead had an attitude of “Go away, you bother me” and couldn’t wait to get away, despite my obvious experience and understanding of the issues involved

You can read the full post .

Alex.
Reply 8. At 8:42 PM on Jan 30, 2007, Richard D. Jackson wrote:: Re: JSR 291 passed
Knipflerfish is under BSD not GPL or LGPL