All Implemented Interfaces:
public abstract class WorkspaceJob
- extends org.eclipse.core.internal.resources.InternalWorkspaceJob
A job that makes an atomic modification to the workspace. Clients must
implement the abstract method
of the usual
After running a method that modifies resources in the workspace,
registered listeners receive after-the-fact notification of
what just transpired, in the form of a resource change event.
This method allows clients to call a number of
methods that modify resources and only have resource
change event notifications reported at the end of the entire
batch. This mechanism is used to avoid unnecessary builds
Platform may decide to perform notifications during the operation.
The reason for this is that it is possible for multiple threads
to be modifying the workspace concurrently. When one thread finishes modifying
the workspace, a notification is required to prevent responsiveness problems,
even if the other operation has not yet completed.
A WorkspaceJob is the asynchronous equivalent of IWorkspaceRunnable
Note that the workspace is not locked against other threads during the execution
of a workspace job. Other threads can be modifying the workspace concurrently
with a workspace job. To obtain exclusive access to a portion of the workspace,
set the scheduling rule on the job to be a resource scheduling rule. The
interface IResourceRuleFactory is used to create a scheduling rule
for a particular workspace modification operation.
IWorkspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor)
Fields inherited from class org.eclipse.core.internal.jobs.InternalJob
Methods inherited from class org.eclipse.core.internal.resources.InternalWorkspaceJob
Methods inherited from class org.eclipse.core.runtime.jobs.
Methods inherited from class org.eclipse.core.internal.jobs.InternalJob
- Creates a new workspace job.
name - the name of the job
- Runs the operation, reporting progress to and accepting
cancelation requests from the given progress monitor.
Implementors of this method should check the progress monitor
for cancelation when it is safe and appropriate to do so. The cancelation
request should be propagated to the caller by throwing
runInWorkspace in class
monitor - a progress monitor, or
null if progress
reporting and cancelation are not desired
- the result of running the operation
- if this operation fails.
Guidelines for using Eclipse APIs.
Copyright (c) Eclipse contributors and others 2000, 2008. All rights reserved.