EclipseZone - Sun submits JSR 316, still doesn't get ...

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

Reply 1. At 2:33 PM on Jul 4, 2007, Neil Bartlett wrote:: Re: Sun submits JSR 316, still doesn't get OSGi
Alex,

I think that you've read it a little wrong. JavaEE 6 will target JavaSE 6, so JSR 277 will NOT be available. The disappointing thing therefore is not that they've chosen JSR 277 for JavaEE 6 (because they can't!) but that they've ignored JSR 291.

This JSR states that any consideration of JSR 277 will be deferred to JavaEE 7, which is so far in the future that I don't think we really need to worry about it yet.

I tend to support the goals of JavaEE 6: to make JavaEE more flexible and extensible, and less of a bloated "one size fits all" monolith. However I also agree with Peter that the implementation, using "profiles", is not likely to be workable.

Neil
Reply 2. At 3:10 PM on Jul 4, 2007, Jilles van Gurp wrote:: Re: Sun submits JSR 316, still doesn't get OSGi
I've worked a bit with OSGi in the past few months. Like many programmers, the benefits are quite clear to me. However, I find it has a number of deficiencies as well that simply need to be addressed for it to be integrated in the Java platform and to be part of next generation JEE which probably is still quite some time away from reaching the market.

A problem with OSGI is simply that it is designed to interoperate with pre Java 5, java systems. That's great on obsolete platforms or limited platforms (e.g. CDC java where I'm currently using it) but doesn't make much sense looking forward to JDK 7 and JEE 6 and beyond to stick with a lot of design decisions that predate much of the nice new language and platform features that have been added and will be added to the language since.

Specifically, OSGi does not make use of Java annotations instead relying on Sun's first attempt at doing metadata: the manifest file.

A second problem is that it works around the default import mechanism in the language by requiring an additional one and it adds a similar mechanism in the form of an export mechanism. Having explicit imports and exports is great for modularity. It's a huge step forward for Java. But the OSGi way is not necessarily the best or the only way of doing this.

A third problem is the Activator cruft where I find myself copy pasting & adapting code that in my opinion should not be written in the first place. Annotations are designed to solve this. Specifically the service tracker pattern is overly verbose. Surely there's nicer ways of injecting dependencies and declaring services than messing around with inner classes and complicated frameworks these days.

These are important points because a key feature of JEE5 is that it got rid of a lot of this type of cruft. JEE6 should not undo that progress and therefore OSGi is not the most natural choice there.

My point is not to bash OSGi. It's great technology. I use it, and even like it. My point instead is that there are better ways of doing what it does in the next gen Java. I have no idea if the JSR 277 people have the right level of ambition here but I find the conservatism surrounding the OSGi crowd also a bit disappointing. The attitude of OSGi being just fine as it is one I don't share or understand. Of course backwards compatibility is something to take into account. Even the JSR 277 people seem to agree with that. But OSGi is not the final answer to modularity in Java.

So instead of insisting that OSGi is the one size fits all component model, a more productive way forward could be ensuring that JSR 277 is a success. E.g. by participating and ensuring full support for key features in OSGi in a way that is more appropriate in light of the current version of Java.

I think much of the current criticism on JSR277 is quite justified. If you are going to make a next gen component model it should be better than the ones it displaces. For example, JSR277 doesn't seem to include a lot of core OSGi features which does not make a lot of sense to me either. These features work on anything from CDC java to high end clusters but somehow are not desirable to have in Java 7? I don't think anyone buys that. I certainly don't.
Reply 3. At 3:57 PM on Jul 4, 2007, Neil Bartlett wrote:: Re: Sun submits JSR 316, still doesn't get OSGi
Jilles,

A lot of what you want to see in OSGi can be built on top of it. You ask "surely there are nicer ways of injecting dependencies and declaring services than missing around with inner classes and complicated frameworks". Yes of course there are, you just have to look!

The mission of the core platform really is to be as small as possible while enabling people to build whatever features they like on top, such as annotation driven dependency injection and so on. For example, take a look at the work Stuart McCulloch has done integrating Guice with OSGi. Also take a look at Spring-OSGi, or iPOJO, or the Declarative Services spec.

As for exploiting Java 5+ features, there are significant challenges with doing that while also remaining compatible with earlier versions. However it's certainly something that the OSGi Alliance is looking at, and I believe it's planned to be addressed in R5.

OSGi people certainly don't think that OSGi is "just fine as it is". They are not resting on their laurels, but continuously pushing the spec into new areas. Nobody believes that OSGi as it stands is the "final answer to modularity", and JSR 277 would be very welcome if it incorporated the past 8 years of experience in building OSGi. It would be fantastic if JSR 277 could build on OSGi and make it even more powerful through direct JVM support, but at the moment they're not extending, they're reinventing.

Fortunately there are some OSGi people on the JSR 277 expert group, such as Glyn Normington, Bryan Atsatt, and Richard Hall. However it's very unclear to me whether they will ultimately have any significant influence over a specification which is largely being defined by Sun.

Regards
Neil
Reply 4. At 4:22 PM on Jul 4, 2007, Peter Kriens wrote:: Re: Sun submits JSR 316, still doesn't get OSGi
I agree with the most of the shortcomings you mention, however, they were intentional.

The goal of Java was to write once, run anywhere. We all know the jokes about write once, debug anywhere. However, I still think it is a laudable goal we should try to achieve and my work in the OSGi is largely directed towards this goal.

All the features you want are supported on top of OSGi. For example, you can easily use annotations and generate the manifest data in runtime so that your code runs in a wide variety of environments. Obviously you can also use annotations but then your code only runs on >5 systems. Yes, some things in OSGi are basic but we are finding that this gives us a surprising flexibility. For example, you can write code against the raw OSGi API, or Spring-OSGi, or iPOJO, or Declarative Services and they can all communicate over the service layer.

This does not mean that we do not change. We are careful but there is a lot of work going on inside the OSGi in the Enterprise Expert Group to address issues that are important for enterprise applications. We are not standing still, and we love to get feedback. We have a simple process. If you think there are shortcomings in OSGi, please write an RFP, a few pages is enough. Describe the application domain, problem, use cases, and a set of requirements. We take those very serious, we currently have about 20 RFPs in progress for the next release. I'd love to hear where we can improve. Unfortunately, your mail does not seem to provide clues how and where these improvements could be made?

By the way, I have not written an activator for many months I use declarative services.

Peter Kriens
Reply 5. At 4:28 PM on Jul 4, 2007, Richard Hall wrote:: Re: Sun submits JSR 316, still doesn't get OSGi
Admittedly, I am a little biased when it comes to OSGi (Apache Felix VP and member of EGs for JSR 277 and 291), but let me respond to some of these issues that were raised...

> I've worked a bit with OSGi in the past few months.
> Like many programmers, the benefits are quite clear
> to me. However, I find it has a number of
> deficiencies as well that simply need to be addressed
> for it to be integrated in the Java platform and to
> be part of next generation JEE which probably is
> still quite some time away from reaching the market.
>
> A problem with OSGI is simply that it is designed to
> interoperate with pre Java 5, java systems. That's
> great on obsolete platforms or limited platforms
> (e.g. CDC java where I'm currently using it) but
> doesn't make much sense looking forward to JDK 7 and
> JEE 6 and beyond to stick with a lot of design
> decisions that predate much of the nice new language
> and platform features that have been added and will
> be added to the language since.

While I don't completely disagree that there are a few bad choices in the OSGi API, I think that you completely devalue the advantage of having a single dynamic modularity layer that works the same across all Java platforms. Clearly, this is worth the loss of generics and annotations to a good many people.

> Specifically, OSGi does not make use of Java
> annotations instead relying on Sun's first attempt at
> doing metadata: the manifest file.

This is true and given that OSGi technology started back in 1999, there wasn't much of a choice. However, if it were started from scratch today, I am not convinced that baking module information into the source code is necessarily the best solution, since it severely limits re-use. For example, it is not possible for me to use the same source in two different modules if the modularity annotations are baked into the source file. It is also possible that you might want to create different sets of modules out of the same source base for different purposes (e.g., deploying to a server vs a desktop vs a cell phone). So, while annotations seem like a slam dunk, an external meta-data mechanism is also not without its merits.

> A second problem is that it works around the default
> import mechanism in the language by requiring an
> additional one and it adds a similar mechanism in the
> form of an export mechanism. Having explicit imports
> and exports is great for modularity. It's a huge step
> forward for Java. But the OSGi way is not necessarily
> the best or the only way of doing this.

The "default import mechanism" of Java has nothing to do with code dependencies, it only has to do with namespace management; i.e., it allows you to type short names rather than fully qualified names, but nothing prevents you from always using long names and never using imports.

However, since OSGi imports are directly related to source code dependencies, it is quite possible to generate these imports directly by analyzing the byte code. There are several tools to do this...in Felix we rarely write our own import statements.

Regarding exports, there is pretty much no way around explicitly declaring them since it is not possible to divine the programmer's intent. There is no equivalent to this in the Java language.

> A third problem is the Activator cruft where I find
> myself copy pasting & adapting code that in my
> opinion should not be written in the first place.
> Annotations are designed to solve this. Specifically
> the service tracker pattern is overly verbose. Surely
> there's nicer ways of injecting dependencies and
> declaring services than messing around with inner
> classes and complicated frameworks these days.

I am not really sure I understand your point here. There is, however, a difference between low-level API and best practices nowadays. Yes, when OSGi technology was introduced, this low-level API was considered best practice, but this changed years ago. The Service Binder was introduced back in 2003 I believe, which eliminated the need for activators and the use of nearly any OSGi API. The OSGi R4 spec introduced Declarative Services. There is now Spring-OSGi and iPOJO. There are plenty of options for people out there for avoiding the low-level OSGi APIs.

> These are important points because a key feature of
> JEE5 is that it got rid of a lot of this type of
> cruft. JEE6 should not undo that progress and
> therefore OSGi is not the most natural choice there.

I think your points only tell half the story.

> My point is not to bash OSGi. It's great technology.
> I use it, and even like it. My point instead is that
> there are better ways of doing what it does in the
> next gen Java. I have no idea if the JSR 277 people
> have the right level of ambition here but I find the
> conservatism surrounding the OSGi crowd also a bit
> disappointing. The attitude of OSGi being just fine
> as it is one I don't share or understand. Of course
> backwards compatibility is something to take into
> account. Even the JSR 277 people seem to agree with
> that. But OSGi is not the final answer to modularity
> in Java.

It may not be the final answer to Java modularity, but it is by far the most advanced. JSR 277 will not even come close, nor will it really resolve the issues you are raising here (e.g., there will still be an external meta-data file). In addition, you will lose dynamics and many of the advanced modularity features of OSGi.

The fact that OSGi technology strives to remain backwards compatible may make it seem like it is standing still to you or that the "OSGi crowd" think it is fine as it is, however, nothing could be further from the truth.

OSGi R4 saw the most significant changes to the modularity layer since the inception of it. OSGi R4.1 saw a quicker release schedule to try to deal with issues raised by the JSR 291 EG. Now a substantial amount of work is underway to deal with EE concerns for OSGi R5. Yes, a goal will be to be compatible with Java ME where possible. If this is a problem for you, then I guess you can wait for JSR 277, but it is likely that it will further disappoint.

> So instead of insisting that OSGi is the one size
> fits all component model, a more productive way
> forward could be ensuring that JSR 277 is a success.
> E.g. by participating and ensuring full support for
> key features in OSGi in a way that is more
> appropriate in light of the current version of Java.

Again, I think this is a mischaracterization of the OSGi approach. Being backwards compatible is not a one-size-fits-all approach; there is no need to break compatibility for what amounts to syntactic sugar. Why create artificial barriers among the various Java platforms? Hasn't the whole "profile" model caused enough difficultly and confusion as it is?

The OSGi approach still allows you to push most functionality outside of the core, so if you need to create specific services on top of the OSGi core, then they are free to use whatever whiz-bang features you want.

> I think much of the current criticism on JSR277 is
> quite justified. If you are going to make a next gen
> component model it should be better than the ones it
> displaces. For example, JSR277 doesn't seem to
> include a lot of core OSGi features which does not
> make a lot of sense to me either. These features work
> on anything from CDC java to high end clusters but
> somehow are not desirable to have in Java 7? I don't
> think anyone buys that. I certainly don't.

Well, you will not be happy with the result of 277 then, since much of what you are asking for is outside of its scope.

-> richard
Reply 6. At 6:39 PM on Jul 4, 2007, Erkki Lindpere wrote:: Fork Java
Maybe it's time to fork Java? Get Apache, OSGi and Eclipse together and form a new platform, also get IBM, BEA, Red Hat, Google and others behind it.

Just kidding. But I think if Sun continues it's game, this will become more and more probable. A far better solution would be for Sun to take off the NIH goggles and start playing nice with everyone.
Reply 7. At 6:47 AM on Jul 8, 2007, Werner Keil wrote:: Re: Fork Java
Most of the companies you mention here are actually rather active members of the JCP

Except OSGi, which I am not aware of, they are also sit and vote in its Executive Committee, where decisions over various JSRs such as 277 and others are discussed and made.
Reply 8. At 6:53 AM on Jul 8, 2007, Werner Keil wrote:: Re: Sun submits JSR 316, still doesn't get OSGi
While involved in JSR 291, is OSGi and yourself actually participating in 316 or 277?
Reply 9. At 7:00 AM on Jul 8, 2007, Werner Keil wrote:: Re: Sun submits JSR 316, still doesn't get OSGi
If you look at the huge list of what Java EE 6 (JSR 316) will defer to at least 7, there's not just 277 or Java Modules to worry about:
* JSR-168 Portlet Specification
* JSR-170 Content Repository for Java technology API
* JSR-207 Process Definition for Java
* JSR-208 Java Business Integration (JBI)
* JSR-225 XQuery API for Java (XQJ)
* JSR-235 Service Data Objects
* JSR-286 Portlet Specification 2.0
* JSR-289 SIP Servlet v1.1
* JSR-301 Portlet Bridge Specification for JavaServer Faces

Especially some like Portlets (2 AND 1) go very far back and have been applied by almost the entire industry.

However, as most vendors have placed their Portal products on top of a Java EE Application Server (BEA, IBM, JBoss, etc.) it could also be in their interest, this remains like it for a little while.

And probably more users and customers who would otherwise have to deal with a full scale portal in any case even if they may need just a plain JSP or WebFlow application...
Reply 10. At 7:27 AM on Jul 8, 2007, Alex Blewitt wrote:: Re: Sun submits JSR 316, still doesn't get OSGi
I believe that Peter was prevented from joining the JSR 277 expert group.

http://www.aqute.biz/Blog/2005-08-11

After all, you wouldn't want someone with years of experience on a committee that's been formed to re-invent the wheel, would you?

Glyn Normington is on the expert group of both (representing IBM AFAIK) and has a useful comparison between them on his blog .

I don't speak for Peter or Glyn, obviously, but those URLs you might want to check out.

Alex.
Reply 11. At 3:58 AM on Jul 18, 2007, Alex Blewitt wrote:: Re: Sun submits JSR 316, still doesn't get OSGi
JSR 316 has recently been approved, although the JCP page hasn't updated as of 09:00 BST:

http://www.jcp.org/en/jsr/detail?id=316

Alex.