I got involved with Java when it was released in alpha in 1995, probably at the start of my last year at University. Until then I’d been learning many new programming languages, having taught myself Prolog and ML ahead of the University course requirements, but until then I’d mainly done Objective-C on my NeXT station. This was at a time when my fellow University students were looking at Linux, probably 1.x releases (I think it was 1.3 at the time when I had my NeXTstep 3.3 software).
Anyway, a friend of mine was interested in learning Java, and as I’d had object oriented experience as well as familiarity with C, we started putting together a few dummy apps. One of the first we wrote was a crossword app, the kind you now see on newspaper websites. Of course as an Applet it would no longer run, but it was a great way of demonstrating the power of the Java language. (It was a step down from Objective-C and AppKit, but that’s a story for another time.)
After University I got a job at IBM working on Java applications, and shortly
afterwards helped kick off their training courses for Java, including OB-73,
OB-74, their Java training material. At the time, students were converting from
C and writing C-like Java code, including methods taking and returning byte[]
arguments in place of their void*
or char*
arguments. One such student
complained that “Java was crap” because “You could only have 65534 methods” and
that “he had to add a second class.” Yes, dear reader, he had translated an
entire C app into static methods in a pair of classes.
Off the back of that experience, and a contract for developing a Java GUI front end, I set up a Java and training consultancy with another of my ex-IBM friends. This would take me teaching Java around the world, from the Indian subcontinent to the American continent on the other side. I got involved in Java at conferences, teaching J2ME programming for the Sun roadshow, and even had some interaction with open-source projects (including the original Log4J release).
The Java GUI project dried up with the collapse of oil prices in the late ’90s, and the training and consultancy work dried up in 2001 after the airline industry collapsed and the dot-com bubble went with it. In retrospect, I should have focussed more on open-source development at the time, but the world was a different place and there were even concerns that programming would be off-shored to cheaper places.
Instead I shut down the company and went to work for as a Java team lead, followed by moving into the investment banking industry where I was known for both my Java nous and my ties. Sadly, I no longer wear ties (though I still have them) but Java keeps on going.
My work in investment banking involved a variety of different languages and architectures, but when Swift was released, I saw the future of macOS/iOS. I wrote a book on Swift the year it was released, and updated it for the open-source release the following year. I ended up working at Apple for a while, using both my Swift and Objective-C skills for internal use only. The only visible output of what I’ve worked on was the Xcode protobuf colouring support, the first Swift CVE vulnerability, as well as a variety of commits to the Swift Foundation library for Linux.
Today, I work in the cloud but I still keep my hand in with Java, and specifically with Eclipse. I was exposed to Eclipse in the early stages with my IBM Java training courses – at the time, I was teaching WebSphere courses, and at the time web development was a combination of VisualAge for Java, and HTML code was edited in different editors. IBM sponsored Eclipse to be the basis of WebSphere Studio 1.0, which had initially HTML editing but then took over the Java compilation for the applications. I helped do a lot of testing on macOS, and then as time went on, got more involved with the project. Today I’m a platform committer on Eclipse, a Java Champion, and I’ve written books on Eclipse and Swift, with a Java one in the works.
Java has been a key part of my career and my technical life, and will likely to continue be through to my retirement. Thanks Java!
]]>ServiceCaller
which simplifies a number of these issues. I also thought it
was worth looking at what the criticisms were because they made valid points.
The
first observation
is that it’s possible to use both DS and ServiceTracker
to track
ServiceReference
s instead. In this mode, the services aren’t triggered by
default; instead, they only get accessed upon resolving the ServiceTracker
using the getService()
call. This isn’t the default out of the box, because
you have to write a ServiceTrackerCustomizer
adapter that intercepts the
addingService()
call to wrap the ServiceTracker
for future use. In other
words, if you change:
serviceTracker = new ServiceTracker<>(bundleContext, Runnable.class, null);
serviceTracker.open();
to the slightly more verbose:
serviceTracker = new ServiceTracker<>(bundleContext, Runnable.class,
new ServiceTrackerCustomizer<Runnable, Wrapped<Runnable>>() {
public Wrapped<Runnable> addingService(ServiceReference<Runnable> ref) {
return new Wrapped<>(ref, bundleContext);
}
}
}
static class Wrapped<T> {
private ServiceReference<T> ref;
private BundleContext context;
public Wrapped(ServiceReference<T> ref, BundleContext context) {
this.ref = ref;
this.context = context;
}
public T getService() {
try {
return context.getService(ref);
} finally {
context.ungetService(ref);
}
}
}
Obviously, no practical code uses this approach because it’s too verbose, and if you’re in an environment where DS services aren’t widely used, the benefits of the deferred approach are outweighed by the quantity of additional code that needs to be written in order to implement this pattern.
(The code above is also slightly buggy; we’re getting the service, returning it, then ungetting it afterwards. We should really just be using it during that call instead of returning it in that case.)
ServiceCaller
This is where ServiceCaller
comes in.
The approach of the ServiceCaller
is to optimise out the over-eager
dereferencing of the ServiceTracker
approach, and apply a functional approach
to calling the service when required. It also has a mechanism to do single-shot
lookups and calling of services; helpful, for example, when logging an obscure
error condition or other rarely used code path.
This allows us to elegantly call functional interfaces in a single line of code:
Class callerClass = getClass();
ServiceCaller.callOnce(callerClass, Runnable.class, Runnable:run);
This call looks for Runnable
service types, as visible from the caller class,
and then invoke the function getClass()
as lambda. We can use a method
reference (as in the above case) or you can supply a Consumer<T>
which will
be passed the reference that is resolved from the lookup.
Importantly, this call doesn’t acquire the service until the callOnce
call is
made. So, if you have an expensive logging factory, you don’t have to
initialise it until the first time it’s needed – and even better, if the error
condition never occurs, you never need to look it up. This is in direct
contrast to the ServiceTracker
approach (which actually needs more characters
to type) that accesses the services eagerly, and is an order of magnitude
better than having to write a ServiceTrackerCustomiser
for the purposes of
working around a broken API.
However, note that such one-shot calls are not the most efficient way of doing
this, especially if it is to be called frequently. So the ServiceCaller
has
another mode of operation; you can create a ServiceCaller
instance, and hang
onto it for further use. Like its single-shot counterpart, this will defer the
resolution of the service until needed. Furthermore, once resolved, it will
cache that instance so you can repeatedly re-use it, in the same way that you
could do with the service returned from the ServiceTracker
.
private ServiceCaller<Runnable> service;
public void start(BundleContext context) {
this.service = new ServiceCaller<>(getClass(), Runnable.class);
}
public void stop(BundleContext context) {
this.service.unget();
}
public void doSomething() {
service.call(Runnable::run);
}
This doesn’t involve significantly more effort than using the ServiceTracker
that’s widely in use in Eclipse Activators at the moment, yet will defer the
lookup of the service until it’s actually needed. It’s obviously better than
writing many lines of ServiceTrackerCustomiser
and performs better as a
result, and is in most cases a type of drop-in replacement. However, unlike
ServiceTracker
(which returns you a service that you can then do something
with afterwards), this call provides a functional consumer interface that
allows you to pass in the action to take.
We’ve looked at why ServiceTracker
has problems with eager instantiation of
services, and the complexity of code required to do it the right way. A scan
of the Eclipse codebase suggests that outside of Equinox, there are very few
uses of ServiceTrackerCustomiser
and there are several hundred calls to
ServiceTracker(xxx,yyy,null)
– so there’s a lot of improvements that can
be made fairly easily.
This pattern can also be used to push down the acquisition of the service
from a generic Plugin/Activator level call to where it needs to be used.
Instead of standing this up in the BundleActivator
, the ServiceCaller
can be used anywhere in the bundle’s code. This is where the real benefit
comes in; by packaging it up into a simple, functional consumer, we can
use it to incrementally rid ourselves of the various BundleActivator
s that
take up the majority of Eclipse’s start-up.
A final note on the ServiceCaller
– it’s possible that when you run the
callOnce
method (or the call
method if you’re holding on to it) that a
service instance won’t be available. If that’s the case, you get notified by a
false
return call from the call
method. If a service is found and is
processed, you’ll get a true
returned. For some operations, a no-op is a fine
behaviour if the service isn’t present – for example, if there’s no
LogService
then you’re probably going to drop the log event anyway – but it
allows you to take the corrective action you need.
It does mean that if you want to capture return state from the method call then
you’ll need to have an alternative approach. The easiest way is to have an
final Object result[] = new Object[1];
before the call, and then the lambda
can assign the return value to the array. That’s because local state captured
by lambdas needs to be a final reference, but a final reference to a mutable
single element array allows us to poke a single value back. You could of course
use a different class for the array, depending on your requirements.
So, we have seen that ServiceCaller
is better than ServiceTracker
, but can
we do even better than that? We certainly can, and that’s the purpose of the
next post.
ServiceTracker
and on slide 37 of my presentation noted that:
ServiceTracker.open()
is a blocking callServiceTracker.open()
results in DS activating servicesUnfortunately, not everyone agrees because it seems insane that ServiceTracker
should do this.
Unfortunately, ServiceTracker
is insane.
The advantage of Declarative Services (aka SCR, although no-one calls it that) is that you can register services declaratively, but more importantly, the DS runtime will present the existence of the service but defer instantiation of the component until it’s first requested.
The great thing about this is that you can have a service which does many class loads or timely actions and defer its use until the service is actually needed. If your service isn’t required, then you don’t pay the cost for instantiating that service. I don’t think there’s any debate that this is a Good Thing and everyone, so far, is happy.
The problem, specifically when using ServiceTracker
, is that you have to do a two-step process to use it:
ServiceTracker
for your particular service classopen()
on it to start looking for servicesServiceTracker
to do something with itThere is a generally held mistaken belief that the DS component is not
instantiated until you hit step 4 in the above. After all, if you’re calling
the service from another component – or even looking up the ServiceReference
yourself – that’s what would happen.
What actually happens is that the DS component is instantiated in step 2
above. That’s because the open()
call – which is nicely thread-safe by the
way, in the way that getService()
isn’t – starts looking for services, and
then caches the InitialTracked
service, which causes DS to instantiate the
component for you. Since most DS components often have a default, no-arg
constructor, this generally misses most people’s attention.
If your component’s constructor – or more importantly, the fields therein,
cause many classes to be loaded or perform substantial work or calculation, the
fact that you’re hitting a ServiceTracker.open()
synchronized call can take
some non-trivial amount of time. And since this is typically in an
Activator.start()
method, it means that your nicely delay-until-its-needed
component is now on the critical path of this bundle’s start-up, despite not
actually needing the service right now.
This is one of the main problems in Eclipse’s start-up; many, many thousands of
classes are loaded too eagerly. I’ve been working over the years to try and
reduce the problem but it’s an uphill struggle and bad patterns (particularly
the use of Activator
) are endemic in a non-trivial subset of the Eclipse
ecosystem. Of course, there are many fine and historical reasons why this is
the case, not the least of which is that we didn’t start shipping DS in the
Eclipse runtime until fairly recently.
Of course, when you point this out, not everyone is aware of this subtle behaviour. And while opinions may differ, code does not. I have put together a sample project which has two bundles:
Activator
(yeah I know, I’m using it to make a point) that uses a ServiceTracker
to look for Runnable
instancesRunnable
interfaceWhen launched together, as soon as the ServiceTracker.open()
method is called, you can see the console printing "Component has been instantiated"
message. This is despite the Client
bundle never actually using the service that the ServiceTracker
causes to be obtained.
If you run it with the system property -DdisableOpen=true
, the
ServiceTracker.open()
statement is not called, and the component is not
instantiated.
This is a non-trivial reason as to why Eclipse startup can be slow. There are
many, many uses of ServiceTracker
to reach out to other parts of the system,
and regardless of whether these are lazy DS components or have been actively
instantiated, the use of ServiceTracker.open()
causes them to all be eagerly
activated, even before they’re needed. We can migrate Eclipse’s services to DS
(and in fact, I’m working on doing just that) but until we eliminate the
ServiceTracker
from various Activators, we won’t see the benefit.
The code in the github repository essentially boils down to:
public void start(BundleContext bundleContext) throws Exception {
serviceTracker = new ServiceTracker<>(bundleContext, Runnable.class, null);
if (!Boolean.getBoolean("disableOpen")) {
serviceTracker.open(); // This will cause a DS component to be instantiated even though we don't use it
}
}
Unfortunately, there’s no way to use ServiceTracker
to listen to lazily activated services, and as an OSGi standard, the behaviour is baked in to it.
Fortunately, there’s a lighter-weight tracker you can use called
ServiceCaller
– but that’s a topic for another blog post.
Using ServiceTracker.open()
will cause lazily instantiated DS components to
be activated eagerly, before the service is used. Instead of using
ServiceTracker
, try moving your service out to a DS component, and then DS
will do the right thing.