JCP In Trouble

It seems that some in the Java community are becoming impatience with Oracle's handling of the JCP. Doug Lea wrote an open letter why he did not want another term on the JCP and Stephen Colebourne, a JCP specification leader and Apache Software Foundation member, is rallying against the JCP. Obviously the lawsuit against Google and the change of heart concerning the Apache Harmony field of use restriction did not win Oracle many new friends. Neil Bartlett even blogs about OSGi taking over the role of the JCP for the Java Community ... LOL

Hmm ...

If you think about, the OSGi is the only other organization that makes specifications for the Java community. And in many ways the OSGi Alliance has an arguably much better structure for Java specifications than JCP ever had:

1. Copyrights - In the JCP the specification lead together with Sun (now Oracle) have a special status. They're not even a bit more equal than others, they are on a whole different plane concerning ownership of the created Intellectual Property (IP). The contributions of other members in the expert groups are gladly taken for free but do not provide any rights in return.
   The OSGi is different. A member is a member, regardless if this member has 100.000 employees or 3. All created IP is licensed forever to all members under exactly the same conditions. Additionally, the specifications are completely free to implement by non-members. Simple, and more important, it is fair.
2. Patents -The OSGi Alliance and some of its key members have pledged not to assert any patents that are necessary to implement the specifications. During the specification process great care is taken that no submarine patents slip in.
   
3. Process - In the JCP the process is more or less in the hands of the specification leads. Having been a member of a number of JSRs I can assure you the process differs significantly. JSR 291 was run quick and efficiently, and I guess we all know what happened to JSR 277 and JSR 294, not to forget my 2 years in JSR 198, the most futile JSR of all.
   In the OSGi there is a much more standardized process that focuses on requirements first, API later. Over the past 30 years I've worked with oh so many developers developing APIs. It is a lot easier to get an agreement on requirements than on an implementation proposal. Therefore, the OSGi EGs always first work on an Request For Proposal (RFP); a document focused on requirements. Maybe those documents are not always perfect requirement documents but the process of making this requirements provides the opportunity for the EG members to create a common vocabulary. This collaborative mood helps tremendously when it is time to create the Request For Comments (RFC).
   
4. Reference Implementations (RI) - In the OSGi process a Reference Implementation is mandated before a specification can be published. For the previous releases the OSGi worked with several open source groups to provide the RI. However, the OSGi also has their own RIs when no group steps up.
   
5. Compatibility Tests (CT) - Every specification requires a CT that runs on the OSGi test harness. These CTs are free for the members and can be obtained free of cost for qualifying open source projects.
   
6. Architecture - The quality and architectural aspects of JSRs differs wildly because there is no central gating function. The running of a JSR is more less up to the specification leads and they can basically deliver what they want.
   In the OSGi Alliance all APIs have to go through the CPEG, which acts as an architecture board. Though this can be a bottleneck and a pain, it ensures consistency between specifications which is a big benefit for the users.
7. Quality Specifications - Again, in the JCP the specification is more or less what the specification lead wants to make of it. Some are excellent, other are a bit less. In contrast, all OSGi specifications are written as data sheets in the same template. Overall releases pack up a number specifications and bundle them together in a high quality book.

So what arguments could one think against the OSGi Alliance taking over the JCP role?

1. Opennes - Though the OSGi has been releasing RFCs ahead of the specifications the name lingers that the OSGi is very closed. I do think the OSGi Alliance should try to open up more but I also believe that the EG should have a period to get their act together before they have to publish. Specification writing is hard and agreeing within an EG is even harder. Anyway, so far there has been surprisingly little feedback on our released RFCs.
   
2. OSGi is Expensive - Today, the OSGi Alliance subscription fee is $25k or (€18k). They are currently trying to change our bylaws so they can actually have different tiers that will allow the subscription cost to go down for many companies. And they have invited researchers for qualifying academics. However, a bit of a reality check here. If you want to work on specifications it will cost you time and travel; both are highly expensive. If you want to do a good job, these costs dwarf the cost of the subscription fee. If the fee is the problem, should you really be wanting to work on these specifications anyway?
   The biggest advantage of the fees is that the organization is independent of the big guys and can thus be truly democratic for its members. With different tiers the big guys will pay significantly more but will require to become more equal. And was that not one of the problems with the JCP?
3. Not everyone uses the OSGi Framework - True, our specifications take the framework into account but most service specifications are written for pure POJOs. For architectural consistency it would be necessary to consider the framework in new specifications but that would not influence their usage outside a framework.
   In practice, this means ensuring the specifications are properly cohesive and uncoupled. For example, instead of putting the Factory and Provider classes inside the package, they would have to be kept in a separate packages, but that is also good modular practice in non-OSGi Java.

I am probably day dreaming to even consider for the OSGi Alliance to take over the JCP role for the Java community. But looking at the arguments it looks like Neil has a valid point ...

Peter Kriens

Masterclass Experiences

Last week Neil Bartlett and I gave a masterclass in Girona. We had a very good crowd: 10 very clever people. The first day was an introduction day but we learned the second day that we had to repeat some of the introductory material on the first masterclass day. The key reason was that even the most experienced users were not really aware how easy it is to use µservices with the bnd component annotations in bndtools.
The days were pretty intensive, going from 9 in the morning to deep in the evening. Though we stopped around 6 in the afternoon, we then tended to just move to the lobby and continue discussing and exploring. The lobby was the only place with Internet, though this sounds limiting, the effect was that we all had a good time together instead of sitting in our rooms working alone.


One of the first things we did is play with Vaadin. We used a little bundle I wrote some time ago that made it trivial to build a Web GUI with Declarative Services. We then continued with configuration. I discovered some really cool stuff just doing these exercises. Though I was the author of the Metatype specification, I never really used it since then, though I heard that the Apache Felix Webconsole supported it very well (as long as the Metatype Service is installed). A Metatype defines a type for a configuration record with sufficient information to automatically generate a decent UI for this type. It was kind of magic how a little bit of XML in the bundle suddenly allowed you to control the configuration of the component as well its number of instances. I knew it could be done, just did not realize how powerful it is.

To work on these examples we used Neil's Auction application he used for his tutorial. In this application, an Auction is (obviously) a service. Now would it not be cool to see the auctions of the others in the room? Seems like a job for Distributed OSGi! Before the masterclass Neil had investigated the existing open source implementations for the Remote Service Admin but they were either not up to the standard yet or not robust enough. So we had asked Paremus to provide us with a copy of their Remote Service Admin (RSA) implementation. They were still in active development so there was some reluctance from Paremus but they were fortunately brave enough and it paid off, RSA worked like a charm! In the end we all got each other's auctions on our screens. Distributed OSGi looks like a clear winner.

The next thing we tried was persistence. The last enterprise release provides a way to use JPA based on services. I'd never tried it so we decided to see how it works. I guess I should have prepared this part because it initially went badly. I mistakenly used the Eclipse Link bundles because they mentioned OSGi, however, it turned out that they were not at all related to the OSGi Enterprise specification. After we wasted too much time I got the brilliant idea (not really) to check how we tested the OSGi specification and then noticed that the Eclipse Link bundles we used there did not even remotely resemble what we were using. It turns out that all this work is in the Eclipse Gemini project and this is still in incubator status. Desperately after wasting so much time I used the bundles in the OSGi build. You can find now some information at the Eclipse Wiki but this desperately needs a good example. In the end we got it work thanks to Ralf Ebert who persevered.

Three attendants came from ACA-IT and used the week to work on a little Web based message aggregator based on the technologies we explored in the masterclass. They really wanted to use websockets (two way communication between browser and server) but these were only available in Jetty 7. Using parts from Felix and Equinox they actually got this to work. It was really nice to see how they leveraged the knowledge learned during the day to add this to their app during the night.

During the days we discussed an amazing amount of information. There was a lot of knowledge in the room and we could do some sparring about subjects like testing, versioning, builds, and many of the other things that occupy us as developers.

The last day each attendant had the change to submit a question to the rest of the group. This is the part I always like best because you learn about user problems. It was clear that also that day went by amazingly fast and provided a lot of food for thought. We invited all attendants to an exclusive mailing list for ''Masterclass on OSGi'' attendants. It is already working heavily.

Neil and I were very tired after this exhausting week but also very satisfied. It had been a lot of fun to do but we also learned a lot. We went out for dinner with my wife (accidentally ending up in an Irish pub with the for Neil oh so familiar English pub food) and evaluated the masterclass. As it looks now we are going to repeat it early next year on the west coast of the US. We'll inform you about the details.

Peter Kriens

Minimal OSGi Systems

Every now and then the question pops up about OSGi in really tiny environments. The press release from ProSyst last week about the smallest OSGi stack caused this question to enter my inbox: "Can OSGi be used in constrained embedded solutions?"

Though OSGi is a no-brainer, the underlying question of the use of Java turns out to be harder, even after a decade where memory prices tumbled and processor speeds exploded. In this market the Bill Of Material (BOM) still is the all overriding concern, combined with 99% experience in C(++) coding in this world. Java is usually seen as a sidekick. Nice to have but real men use C(++).

The first OSGi app I worked on was the Ericsson e-box, a home gateway with 32 Mb of RAM and 2 Mb of flash. I always wanted to get rid of the Linux on it and run Java on the bare metal so we would have a single management model. I actually wrote Java implementations of DNS, DHCP, and even wrote a Java implementation of the TCP/IP stack to be able to communicate with SLIP devices! However, others in the project were experienced Linux people and found it a lot easier to just do everything with existing software. Fighting about this architecture wasted a lot of time and in the end we ended up with an ugly hybrid that was hard to manage.

Last week, a presentation from Andre Bottaro (Orange Labs/France Telecom) and IS2T on the OSGi community event seems to indicate that things are moving again. These companies developed a minimum OSGi stack in a really small device by removing Linux and running the VM on bare metal. However, though these tiny OSGi implementations are interesting exercises I must admit that I have mixed feelings. OSGi is about downloading modules, such a model requires some headroom to have value. Why waste resources to a mechanism that can only be used for trivial downloads? Java in the phone did not become very useful until Android provided an SE like class library that was sufficiently rich and the hardware had sufficient headroom to make downloadable apps feasible.

That said, I do believe that in the end OSGi is the way to go because providing new and updated functions become more and more a necessity. And there are more activities around this. Also at the community event Tim Ellison (IBM) demonstrated Apache Harmony and how the modular approach of Harmony (it uses OSGi metadata for its modules) can be used to create really small and efficient VMs. I am going to look more in Harmony because it looks like an ideal VM to run OSGi on. I also spoke to Marcel Offermans (Luminis) who is submitting a proposal to Apache for a C(++) based runtime that is based on the principles of OSGi and will work together with OSGi through the service registry. This seems even more ambitious than the Universal OSGi idea that we played with in the OSGi Alliance a few years ago.

I do hope we do see more efforts shrinking the OSGi stack like ProSyst, Luminis, Orange Labs, IS2T and many others are doing. One day we will be at a place where OSGi is a no-brainer, in small devices, including the Java part.

Peter Kriens