Bio Tim Ward is a Senior Consulting Engineer and Trainer at Paremus, a co-author of Enterprise OSGi in Action, and has been actively working with OSGi for over six years. Tim has been a regular participant in the OSGi Core Platform and Enterprise Expert Groups, and led the development of several specifications, including OSGi Promises and Asynchronous Services.
Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
1. Hi, I’m here with Tim Ward, who is a Senior Consulting Engineer at Paremus at OSGi DevCon 2014 in conjunction with QCon New York 2014. Tim, you worked on something called the OSGi Promises spec which is a draft status of the OSGi Enterprise 6 draft, can you just tell us a little bit about what Promises are and why you think they are useful?
In Java, you can’t; well, you can now in Java 8 because they’ve added a CompletableFuture type. However it’s a concrete type and has an awful lot of methods on it, so you can do a lot of very powerful things, but it’s not that easy to use. So one of the things we really wanted to do with OSGi Promises is we wanted to keep them small and separate, so the OSGi Promise API can actually be used independently of OSGi; it has no dependencies on the core framework, has no dependency on any other specification in OSGi. it’s small and isolated and it can actually be implemented on Java versions going way back. So the default implementation uses some Java 5 primitives, because it makes it slightly easier for us to write it, but actually we’ve produced versions that work on Java 1.4 and Java 1.3 and we’re pretty certain that we could do it further back, but nobody has much of the stomach for writing Java 1.1 code.
I think not so much for Java 1.1 and 1.2; but at the moment there is still no real solution for people who are running in embedded frameworks and wanting to use Promises, so something that embedded people often do is they want to send data, say, from an EDGE device and they may be using something like GSM which has horrendous latency and actually Promises are ideal there. But they are stuck using Java 1.4 because the mobile frameworks haven’t advanced beyond that, JavaME sort of stopped in Java 1.4. So, yes, obviously going back further is probably not that useful, but being able to run on Java 1.4 is more useful than you might think and certainly not having to require Java 8 is very useful because despite the fact that it’s great and I love using it, a lot of people aren’t there yet.
Yes. And given that we didn’t want to tie it to the framework, but we do want OSGi framework and other OSGi specs to be able to use it, we don’t want to force an OSGi specification to move to Java 8 just so that they can get some function that actually doesn’t really benefit from having Java 8 baked into the API; it benefits a lot from the addition of lambdas in Java 8 because all of the callbacks are single abstract method types so you can use lambdas to do really elegant stuff when you are composing Promises or mapping them or flat-mapping them or adding fall backs, and all of that you can do with lambdas and it looks great, but equally you don’t need to have lambdas in order to be able to use it, so there is no reason for us to depend on Java 8.
Alex: So these Promises can be used in any Java application, not just OSGi ones.
Absolutely. That was a hard requirement when we were putting it together.
The documentation is public, which includes the JavaDoc, which is pretty much the entirety of the API, it’s very small so people can look at and start playing around with it now, there are already examples coming out of using it and using it with asynchronous services specification. So yes, people can definitely look at it, I would recommend going to the OSGi design repository on GitHub and looking at osgi.org to get the full scoop there. [See https://github.com/osgi/design for more details]
The draft implementation at the moment is in the OSGi build repository; I do work with the EEG [Enterprise Expert Group] but I am not responsible for releasing so I can’t tell you exactly where and when these things are coming out, but one of the things about the draft specification getting a formal nod and a release from the board is these things can be made public.
Alex: Ok, so we’ll look forward to that in the future. Tim Ward, thank you very much.