Absolutely. So, Promises, I think a lot of people will have heard of them, at least in passing, as something people typically are using in JavaScript. What Promises are is a representation of some deferred execution. So, something that’s happening asynchronously and you start it over here, it will finish it at sometime over here, but what you’ve got is a holder for the value in the meantime. What you can do is in the style of a Java Future you could block on that and wait for it to finish, or more usefully what you can do is register for a call back that will happen when this thing has completed. And this is something they do a lot in JavaScript because obviously it’s a single threaded model and if you do block, you’ve stopped anyone from running any code in the whole of the web framework, so your browser is just hung and people don't tend to like that. So, that’s at the nub of what a Promise is.
2. You mentioned Java Future there as well. What’s the difference between a Future and a Promise?
A Promise type is something that you can take and represent a deferred execution but has a mechanism for resolving it, so something where you can set a value in it later, it will have some kind or resolve() or setValue() method. A Future is effectively a view on this deferred execution, but the resolution happens behind the scenes. So a java.util.concurrent.Future is a Future and rather counter intuitively an OSGi Promise is also, academically speaking, a Future because it doesn’t have a method on it to resolve it. On the other hand if you want to use a Java Future and an OSGi Promise in the same piece of code, I think you would quite rightly curse our names if we’d chosen to call it a Future. So, what we have is a Promise because it’s a lot like a JavaScript Promise, which is something that people are used to dealing with, and what OSGi also defines as a deferred type, so the deferred is equivalent to what academics would call a Promise because you can resolve it, so a deferred you create, the person who creates it holds on to it and can later use it to resolve the Promise that is created by the deferred.
3. For both of them, can you add call backs when the result changes?
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.
Community comments