Why choosing iPOJO?

A simple development model

Trying to do an OSGi-based application with services can be really challenging. The OSGi API is complex to use and a lot of knowledge about internal mechanisms has to be known to avoid synchronization issues. iPOJO provides a very simple development model. Let's look:

@Component
@Provides
public class MyServiceImplementation implements MyService {
 	...
}

@Component
public class MyServiceConsumer {
 	@Requires
	private MyService myservice;

	// Just use your field as any regular field
}

Is that not easy? Providing OSGi services and requiring them have never been so simple.

Simple but Powerful

Supporting OSGi services is not the only feature of iPOJO. iPOJO provides a lot of others features that allow developing sophisticated applications very easily. In addition of OSGi services, lifecycle control, and configuration, iPOJO supports the Configuration Admin, allows receiving and sending events with the Event Admin, allows remote configuration with JMX... And that's just examples.

Flexible

A missing feature, would like to adapt iPOJO for your application. No problem. iPOJO provides an extensibility mechanism allowing to mange other (specific) requirements. You can easily adapt iPOJO for your own needs.

Creating an extension does not require to modify the core, just implement your own specific handler that will be plugged on your instance. Moreover, handlers can use any other iPOJO features.

"Embeddable"

iPOJO works on any R4.1 OSGi implementation, It also works on a lot of Java virtual machines such as Oracle JRockit, JamVM, Dalvik (Android), Mika... iPOJO requires only a J2ME Foundation 1.1 virtual machine. So, iPOJO can be embedded inside mobile phone applications or inside your washing machine.

Small footprint, minimal overhead

Been powerful is great, but what about footprint and performances?
iPOJO is small, and was designed to stays small. iPOJO core size is 205Kb (against 816Kb for Guice-Peaberry and 2112Kb for the minimal Spring-DM configuration). In addition of the core, you only deploy required features. For example, you need proxy injection, just deploy the temporal dependency bundle (less than 70Kb).

The overhead of iPOJO is also very small. On the Peaberry benchmark, iPOJO has very good performance.

Guice-Peaberry:	276.00 ns/call
iPOJO Service Dependency:	  118.00 ns/call
Spring-DM:	 2384.00 ns/call
iPOJO Temporal Dependency:	  159.00 ns/call
iPOJO Temporal Dependency with proxy injection:	  173.00 ns/call

Other benchmarks were also applied. For French readers, you can find them in the chapter 10 of iPOJO - A flexible service-oriented component model for dynamic systems

Debug & Introspection

Developing OSGi applications can quickly become a nightmare, when it doesn't work as expected. iPOJO helps you to debug your application (and it often happen). First, you can debug iPOJO components as normal OSGi applications (stack traces and line number are not modified).

Then, thanks to the iPOJO introspection mechanisms you can know the structure of your application (which instance uses which service...). So, you easily understand why a service dependency is not fulfilled, property values...

Designing applications

iPOJO also provides an architecture description language to design applications in a flexible and hierarchic manner. Designed applications are expressed in term of service to be natively dynamic, and to support implementation evolution and substitution. Moreover, iPOJO supports service isolation to get your own private service.

Conclusion

So, let's have a try.

For any question or feedback, send an email on the users@felix.apache.org mailing list (send a mail to users-subscribe@felix.apache.org to subscribe).