2007-03-19

OSGi, JSR 291, and JSR 277 misinformation

The problem with the referenced eWeek article is the author apparently chose only quotes which try to promote OSGi as the end all be all to everyone and everything and attempt to bash JSR 277 and Sun Microsystems. JSR 291 and 277 are not actually competing. 277 will actually make its way into standard Java, and will be part of the standard runtime used by the SE and EE platforms, where as 291 isn't a new specification. It is another location which points one to OSGi. It isn't a real specification of the JCP, so why is it even an actual JSR? That doesn't seem to make much sense outside of commercial politics.

291 can not even be contributed to by JCP members without first joining the OSGi Alliance (291 means OSGi in this case). Individuals such as you the reader or myself can join the JCP for free. Individuals can pay the OSGi Alliance $3,000 US. This seems strange to me, considering IBM, the main OSGi Alliance member (Eclipse Funding), was the loudest critic of Sun Microsystems open-sourcing Java. I believe the OSGi Alliance needs to take their own advice and move this initiative completely to the JCP. I get Sun used to be an OSGi Alliance member, and I don't really get why this wasn't first run through the JCP, but it needs to be now.

I agree with the sentiment of some, and I have been a proponent myself of modularizing the entire JRE/JDK, that a module system needs to remain a separate entity from the JRE/JDK itself. This allows the module system to be separately upgraded without waiting for a new JDK release. However, we need JVM level support for better partitioning of ClassLoaders and variable and static visibility. This allows better optimizations and other language and technology hooks which can have greater benefits than a single layer approach. Both ideas have their place.

A good point of view is expressed by Glyn Normington (JSR 291 lead and JSR 277 member) in this blog post with regard to both JSRs. If you are reading through an RSS reader you may need to use:
http://underlap.blogspot.com/2007/03/state-of-java-modularity.html

If OSGi were to fall under the JCP process I could get more behind it. Currently it is one more thing to be dependent which is not as easy to contribute to or influence by small startups or individuals. I would feel the same way if the JCP process is changed to be more closed in the future.

4 comments:

Neil Bartlett said...

Hi Wade,

I share your frustration that the OSGi remains closed to small companies and individuals. I have heard rumours that this may be changing soon though...

As for the justification for JSR 291, please see my blog entry on this subject.

Regards
Neil

Wade Chandler said...

I can see some of your points in the post you mentioned. On Tim et al. I think there is enough of that type thing on both sides of the IDE line. My main frustrations with Eclipse stem from large downloads not to have all I need for building the applications I want to get started on. That and I am a Swing fan.

I should go ahead and mention I'm a Netbeans Dream Team member as I have been around the NB community for years. I might be a little biased, but I think everyone gets that way over their projects. So, to each their own on that stuff.

A little healthy competition and back and forth never hurt anyone. It keeps competition alive I think :-). I can tell you are passionate about Eclipse.

Peter said...

Just some factual corrections ...

1. JSR 291 was run fully in the open with access from -anybody- to put in requirements. The submitted requirements have been discussed and most made it into OSGi 4.1/JSR 291. Your statement that JCP members could not contribute is absolutely not true.

2. The OSGi has an open input process. Any requirements can be submitted to the organization and will be duly processed. The actual design work is left to members because there many IPR issues at stake. See the patent pledge of Nokia, ProSyst, IBM, Samsung, and Gatespace.

3. Anybody can implement the OSGi specifications without a license.

4. JCP is -not- a non profit organization. The OSGi Alliance is, with all the legal safe guards and checks that guarantee fair play. JCP us a wholly owned by SUN.

5. Though you can join the JCP for free, your rights are non-existent. I tried very hard to get into JSR 277 (and as one of the foremost OSGi experts I think I have the credentials) but was denied, even after having the backing of some very important people in the Java community. The OSGi organization has a membership fee but it can not legally exclude companies.

5. You do not have to get behind the OSGi Alliance, nor the specification. You can fully ignore us and use both JSR 232 or JSR 291. These JSRs will give you all the rights that are associated with JSRs. Anybody can implement it or use it, no license fees attached. What more would you get if a non-profit like the OSGi Alliance would fall under SUN, which is a single commercial company?

6. OSGi frameworks are quite small, Eclipse is a large download because it contains a complete IDE. (This as a reply to one of the comments). Go to Apache Felix or Knopflerfish and see that the download is minimal.

And I have a question ... You seem to indicate that JSR should not be an organization that points to other standards but should develop these. I really can not understand that position so maybe you can enlighten me. For me, the goal of the JCP should be to simplify the life of the programmer by sorting out the mess of possible APIs and their myriad of licensing rules.

If there are no good APIs for a specific topic, one could resort on developing them. However, if good APIs exist, why not adopt them?

I think the JCP is extremely ill suited as a design group, as (too) many JSRs show. Keeping the eye on the ball I would say that if the goal is to simplify the life of Java programmers, than JSR 291 is a great thing. We should have more of those: mature, well documented, a large number of commercial and open source implementations, and very well supported.

And if you have extra requirements, please send them to me or the OSGi Alliance, we more than welcome them.

Kind regards,

Peter Kriens

Wade Chandler said...

Before I write anything else I should say that I like what I have read about the OSGi specifications, and this has been the case sense I first saw it some years back. I at promoted it once as possibly being the base module system for Netbeans. This was before I gave it more thought and discussed it with others.

The only reason NB hasn't really built on something such as OSGi is that it already has a capable module system, and this system has been in place for a long time. Replacing it would not achieve any real gain, but would add a lot of work for developers. Just as Eclipse, to do anything useful with extensions in the Netbeans IDE and RCP one has to have the other APIs which are run within the module system which make the Netbeans IDE and/or Rich Client Platform (used for making your own custom applications). The module system is a very small part in this respect.

Peter wrote:
>1. JSR 291 was run fully in the
>open with access from -anybody- to
>put in requirements. The submitted
>requirements have been discussed
>and most made it into OSGi 4.1/JSR
>291. Your statement that JCP
>members could not contribute is
>absolutely not true.
I agree, that needs to be totally different, and doesn't reflect what I was really thinking in that regard. There are a lot of concerns this all brought up. I shared some with Glyn Normington, but not nearly as much as I end up writing here.

It is my understanding JCP members including expert group members have about as much influence as myself or some other individual who is not from a "full member" of the OSGi Alliance. I understand comments can be made through the list. I should have elaborated much more on my concerns within that paragraph.

Certainly within the confines of the JCP certain things need to take place. Otherwise someone else can become the specification lead and owner of the specification, but only if 2/3 percentage of the group vote this way. It seems nearly all members of the JSR expert group are OSGi Alliance members. This seems a conflict of interest, and appears to be the OSGi operating inside the JCP.

It seems the JCP members don't really have the rights, but rather OSGi as the majority. This may be wrong, and you can fill me in, and I reiterate my statement this should have been more clear. If I'm completely wrong then great!

Personally I think there need to be limits to external groups members and who can be within an expert group. Especially for something as important as a plug-in/module system for the JVM everyone uses. What those exact limits are I'm not so sure at this time.

It doesn't seem in the greater communities interest. That doesn't mean these specific groups/companies on JSR 291 don't have the greater communities interests in mind, nor they have any malicious intent what so ever. It is just easy for a Trojan horse with one groups interests to slip into the JCP the way things are currently working.

>And I have a question ... You seem
>to indicate that JSR should not be
>an organization that points to
>other standards but should develop
>these. I really can not understand
>that position so maybe you can
>enlighten me.
It depends really. How does one make sure a JSR operated as this one follows the expert group later on? It can't really, and where does that leave a technology which may have a JSR for one version, then the next not have one such as possibly OSGi 4.2 or what ever the next extension to or after 4.1 may be called. This really goes to your point #2.

JCP maintenance overview:
"The completed specification, reference implementation, and Technology Compatibility Kit are updated in response to ongoing requests for clarification, interpretation, enhancements, and revisions. The Executive Committee can review all proposed changes to a specification and indicate which ones can be carried out immediately and which will require the specification to be revised by an expert group. challenges to one or more tests in a specification's Technology Compatibility Kit are ultimately decided by the Executive Committee if they cannot be otherwise resolved."

In the above I take completed to apply to the specification, reference implementation, and the TCK, and the final product to be maintained within the JSR in the future. Can't the OSGi just not worry about this at all once operating outside the JSR and JCP processes within the OSGi Alliance processes? Will they or won't they? Will specification changes to OSGi take place within the JCP JSR processes from now on, or will they happen in both places without review of the JSR group for the things OSGi adds out of the JCP?

What if the OSGi Alliance pulls out of this process after the JSR? Can the JCP continue on with creating a new lead and then will there essentially be a fork of OSGi as the "Dynamic Component Support for Java" with the OSGi specification not actually falling under OSGi? It seems this could be highly possible once the JSR is complete.

The rules get mighty tangled, and it wouldn't be clear what a court ruling would be on those type issues were someone to take it to that level. What would that do to the Java community? It sounds like a good intro for a Unix war style flub up to me.

These worries have not been addressed in a form readable to anyone which I can tell, and they also matter for other JSRs with the same type basis not just OSGi ones. How does it help the larger community. It seems to leave many holes as to who is forming the specification and which body is actually the owner of the specification once a JSR is finalized.

Obviously, for the JSR to finalize, things need to happen within the JCP process, but from the standpoint of moving forward it seems a mess of rules and regulations when things happen this way. i.e. What if updates to OSGi 4.1 end up not done through the JCP, and instead take place purely through the OSGi?

I don't think the outcome would not be good. This doesn't mean it has to happen this way nor will. But, an example, what is OSGi certification compared to JSR 291 TCK compatible?

The JCP rules probably need to be more clearly defined to take into account the transfer of specification rights, and who exactly it is the specifications belong. A good up front operating agreement could be put in place to maintain certain design decisions and ideas of the main Java creators much as a Constitution or other document provides safe guards for a nation. Maybe, to get rid of the feel of some this is a Sun show, it could be opened up as some type of non-profit as you mentioned.

>For me, the goal of
>the JCP should be to simplify the
>life of the programmer by sorting
>out the mess of possible APIs and
>their myriad of licensing rules.

It is a standards organization not an API directory. Its rules could be changed. So, to me, sure it could be both, granted the API be submitted to it as a standards organization much as what happens with ANSI and the ISO standards. I understand it is not a named non-profit organization as the above mentioned but a community process. However, the rules for JSRs don't indicate anything along the lines of referencing another project like a project or API directory.

>If there are no good APIs for a
>specific topic, one could resort
>on developing them. However, if
>good APIs exist, why not adopt
>them?

I agree. My thoughts revolve around how standards should be governed within the body once they are part of it. I don't think the ISO accepts a standard as something they just link to. Probably because of the confusion I wrote about. I believe they become the owner of the standard once it is handed over to them. They don't just endorse things.

I realize work took place within the JSR, but what I'm getting at is the OSGi can make any determination and not even bother with the JSR members who are not also OSGi members if they so choose. It seems this was also the conclusion came to by others who voted No to the JSR. It doesn't mean anyone is right, but that there is no clear definition. It isn't exactly OSGi's fault if you ask me.

There were no outright corrections to these concerns I saw noted within the JSR summary and description. I also believe for all org.whatevers this should be the case not that I want to specifically pick on the OSGi. It seems to me things need to be clarified in the JCP rules for these type issues.

What the OSGi does or does not do is a different story, but it seems two bodies like this coming together in this way is a good setup for many headaches, and leaves any number of doors open outside the JCP in general. Which brings me back to why even have a JSR for this. Unless of course all OSGi API proposals and furthering of the specifications are going to fall under the JCP, and all work takes place in this manner from now on. Again, I feel this way for all APIs from 3rd party organizations which end up as JSRs.

>2. The OSGi has an open input process. Any requirements
>can be submitted to the organization and will be duly
>processed. The actual design work is left to members
>because there many IPR issues at stake. See the patent
>pledge of Nokia, ProSyst, IBM, Samsung, and Gatespace.

This touches on a point I have made to different people about many things concerning patents in software. Many of these companies have been looking to OSS for ideas for a long time. I can not be convinced many ideas they patent don't have basis in others works. It is very evident when we look around the projects available. To me this is part of the problem in general. Java has now been open sourced and relicensed.

These other pieces need to follow suit in my opinion. I wouldn't want to see things like APIs be GPL, but a more open license such as the CDDL, Apache, or BSD. Something along those lines to not limit the products built on these APIs which have become standards.

>3. Anybody can implement the OSGi
>specifications without a license.
To be certified do they not have to also be a member of the OSGi? What range is the TCK from the JSR going to fall into? Says not to exceed $50,000 in the JSR. Glyn had some ideas here, but nothing concrete I don't think. Free would be nice if it is to be considered an API and a JCP standard. It isn't exactly a runtime, and is why I would hope for a very liberal license. Also, what is the difference between being compliant with the JSR 291 TCK and being OSGi certified?

>4. JCP is -not- a non profit organization. The OSGi
>Alliance is, with all the legal safe guards and
>checks that guarantee fair play. JCP us
>a wholly owned by SUN.

As far as I understand it neither one are that much different in that regard. Once Sun puts out an agreement and you the individual or a company agree with the terms, then the terms are the terms which can be legally binding between the two entities. The terms would hold up in a court room as long as you have abide by them, and their wasn't room for interpretation which can go either way in the disputed section of the agreement. Agreements are much easier to maintain if something is needed later versus making changes to the way a non-profit must do business.

Non-profit doesn't mean someone isn't making money from it. Plenty of non-profits have run different members out and not had fair play. It is a matter of legal vs fair.

>5. Though you can join the JCP for free,
>your rights are non-existent. I tried very hard
>to get into JSR 277 (and as one of the foremost
>OSGi experts I think I have the credentials)
>but was denied, even after having the backing
>of some very important people in the Java community.
That stinks really. I know Glyn Normington is a member of JSR 277. Maybe they had a limit they wanted to set for the number of folks in the group. Did they give you a reason?

>The OSGi organization has a membership fee but it can
>not legally exclude companies.

They could really do what ever they wanted to do within a given expert group I imagine. I haven't seen anything which legally binds an expert group created by one company to force inclusion of others. Obviously it is in the companies best interest to be as inclusive as possible as a "full member" has voting rights, and anything they do could be limited to a waste of time.

As I understand it, you pay annually $20,000 to be a full member or you pay annually $5,000 ($3,000 first year) to be an adopter. You are given certain rights legally limited only by what you specifically have in writing to be guaranteed. The same goes for the JCP agreement. You can create a JSR, you can join others expert groups (may not get in), and you can go to the JCP events and meetings. The agreement is what makes it binding in either situation.

>6. OSGi frameworks are quite small, Eclipse is
>a large download because it contains a complete
>IDE. (This as a reply to one of the comments).
>Go to Apache Felix or Knopflerfish and see that
>the download is minimal.
Yes, I was specifically referring to Eclipse vs Netbeans in that comment. In the blog post Neil referenced he had some things about Eclipse and Netbeans.

>I think the JCP is extremely ill suited as a
>design group, as (too) many JSRs show. Keeping
>the eye on the ball I would say that if the goal
>is to simplify the life of Java programmers,
>than JSR 291 is a great thing. We should have
>more of those: mature, well documented, a
>large number of commercial and open source
>implementations, and very well supported
I will agree with all of that. The things which make the JCP ill suited as a design group need to be addressed all around. I think some of the issues with many JSRs is the lack of availability to the on going work by the public in general. If it is really for the Java "community" more openness and transparency needs to be available. This would help get better input from those who will be using the end result. More details need to be outlined in the JCP rules and explanations. My personal view on JSR 291 revolves around what I have written already about the JCP and 3rd party organizations in general, so I won't go into more detail there.