Mar 01 2009

Defining a background Job to run periodically

Published by at 12:47 pm under Eclipse,IT,Java

One may need to run some task periodically in the background in Eclipse. This background task should run automatically and shouldn’t block user from regular usage of the application. My proposal for accomplishing this is using Eclipse Jobs API and org.eclipse.ui.startup extension-point.

  1. Adding org.eclipse.ui.startup extension:
    • Dependencies:
      • org.eclipse.ui
      • org.eclipse.core.runtime
    • Extension:
      <?xml version="1.0" encoding="UTF-8"?>
      <?eclipse version="3.2"?>
         <extension point="org.eclipse.ui.startup">
            <startup class="tk.urbas.eclipse.urbanlife.Startup"></startup>
  2. Implementing Job:
    package tk.urbas.eclipse.urbanlife;
    import org.eclipse.core.runtime.IProgressMonitor;
    import org.eclipse.core.runtime.IStatus;
    import org.eclipse.core.runtime.Status;
    public class RefreshDataJob extends Job {
        public RefreshDataJob(String name) {
        protected IStatus run(IProgressMonitor monitor) {
            // Work to do in the background
            return Status.OK_STATUS;
  3. Scheduling Job to run periodically:
    package tk.urbas.eclipse.urbanlife;
    import org.eclipse.ui.IStartup;
    public class Startup implements IStartup {
        private static final long STARTUP_DELAY = 5000; // 5 seconds delay for first run
        protected static final long JOB_INTERVAL = 60000; // Job should run every 60 seconds
        public void earlyStartup() {
            final Job updateJob = new RefreshDataJob("Refreshing data in the background");
            updateJob.addJobChangeListener(new JobChangeAdapter() {
                public void done(IJobChangeEvent event) {

Let me know if you have any better solution for implementing this. All improvements, suggestions and comments will be greatly appreciated.

10 responses so far

10 Responses to “Defining a background Job to run periodically”

  1. Fredericon 01 Mar 2009 at 2:49 pm

    Could be an option for simple task scheduling. For more complex job schedules, use

  2. Robert Konigsbergon 01 Mar 2009 at 4:09 pm

    I would strongly discourage using (and at work, be discouraged to use) early startup for this purpose for four reasons: one, because it delays the IDE startup, a solution that does not scale when implemented by a large number if plug-ins; two, because you can’t stop the job when the IDE shuts down; and three, you can’t reference your plug-in or any other plug-in until it too has started

    Instead I would use the plug-in’s lifecycle methods start() and stop() to control when the job starts and stops. Make the job a private member of the plug-in and everything plays well together.

  3. Radoslaw Urbason 01 Mar 2009 at 4:23 pm

    Robert – that’s very good suggestion, thanks! The job lifecycle should be mantained by start()/stop() methods of plug-in’s Activator. But I still want this bundle to activate automatically (it is supposed to be independent, no one other bundle is supposed to reference it) – is there any better option than org.eclipse.ui.startup extension-point for this?

  4. Antoine Toulmeon 01 Mar 2009 at 4:46 pm

    I second what Robert said, and you should just make the bundle non-lazy, so it will start without being required by another bundle.

  5. Robert Konigsbergon 01 Mar 2009 at 7:30 pm

    @Radoslaw, @Antoine’s suggestion is a good one. One wrinkle to consider: if starting your plug-in incurs a long time cost either because it has to start other bundles (that take a long time to start) or because it loads a lot of information, consider splitting your job’s plug-in from the rest of your plug-in.

    My concern is that making your plug-in non-lazy per @Antoine’s suggestion also suffers from being not scalable. If you plan to publish your plug-in for other people to use, while you may think your plug-in is important enough to start early, your user may disagree.

  6. Radoslaw Urbason 01 Mar 2009 at 7:56 pm

    @Robert – basically I was looking for Eclipse way of running some background task periodically.
    All concerns regarding startup time are extremely important, but if the requirement is to do something at startup (or pretty close to startup) I don’t see the obvious effective solution for this. The suggestion regarding making the plug-in defining the job as tiny (including declared dependencies – direct ones and transitive) as possible to minimize the delay is good one. There is still one open question for me: what’s the advantage or disadvantage of using org.eclipse.ui.startup extension comparing to defining non-lazy bundle?

  7. Jens Goldhammeron 01 Mar 2009 at 8:12 pm

    To reschedule the job, it is possible to do that in the run-method.

    protected IStatus run(IProgressMonitor monitor) {
    // Work to do in the background

    return Status.OK_STATUS;

    So in my eyes, you don´t need the jobchangelistener…

  8. Min Idzelison 01 Mar 2009 at 8:18 pm

    Implementing IStartup no longer slows down IDE startup. In fact, the workbench is visible before the IStartups begin to run. In fact, the IStartups are actually run within a Job. (Jobs do not run until after the workbench has been restored. The JobManager is suspended until that time)

    If you scheduled your job within your Plugin.start() method, it will only run when your plugin is activated. This can be far too late in some cases (depending on what your background job does.) That is why the IStartup extension point exists. One caveat on IStartup. Your IStartup extension is *not* guaranteed to run, because the user could have disabled it in the preferences. So you should take care that proper functioning of your plugin is not dependent on that IStartup extension.

    Last note. You do not need a IJobChangedListener for periodic rescheduling. You can just call “schedule()” from within your job. This will cause your job to automatically reschedule itself after it runs.

    However, if a user “cancels” the sleeping job, you will not get a chance to run (or to reschedule) yourself. In that case, you would still need a IJobChangedListener.

  9. Matthiason 02 Mar 2009 at 12:37 pm


    I like the idea of using a bundle’s lifecycle methods start() and stop() for starting and stopping a “job” controlled by some other bundle.
    But a bundle can only be started once in a time. So if I have the use case that a job can be run any number of times this solution won’t work, because a bundle can only be started once until it is stopped, right?!

    Which possibilities would I have for such an use-case?!?

  10. Robert Konigsbergon 03 Mar 2009 at 4:10 pm

    I sent Min’s comment about IStartup to some colleagues and here was a reply:

    The point is that enabling your module to run it early during startup
    will also enable all its dependencies and it does not scale well. The
    push is to make everything turned on on demand. A couple of (3rd
    party) plugins with their IStartups may effectively ruin the effort to
    make the product lazily initialized.

    This comment does not bring any convincing argument. If UI is displayed but there is a couple of threads running on background it is likely that the application will be unresponsive (thread priorities do
    not help much).

Trackback URI | Comments RSS

Leave a Reply

You must be logged in to post a comment.