Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] UIJob vs WorkbenchJob - Role/Expectations 
Pat

All a WorkbenchJob is is a job that will not run when the workbench is 
shut down. It is simply a UIJob that has a more restrictive set of run 
conditions.

UIJobs no longer need to have a Display sent to them as there is a 
reliable Display available from the Workbench as a result of the RCP work 
(PlatformUI.getWorkbench().getDisplay()). If you are running UIJobs when 
the Workbench is shut down (I expect that would be very rare) then you 
would need to set the Display.

I suspect many of the UIJobs would be safer as WorkbenchJobs although this 
is not neccessary if there are no worries about running while the 
Workbench is shutdown. I personally use a WorkbenchJob whenever I need a 
UIJob unless there is a good reason not to.

Tod







Pat McCarthy <patmc@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
03/12/2004 12:47 PM
Please respond to platform-ui-dev
 
        To:     platform-ui-dev@xxxxxxxxxxx
        cc: 
        Subject:        [platform-ui-dev] UIJob vs WorkbenchJob - 
Role/Expectations



Trying to make sure I understand the role of each job type with respect to 
classic plug-in development (IDE) vs other types of contributions (RCP and 
so on). 

There were posts about the UIJob way back that seemed to indicate that you 
must provide a display on the constructor or via the setDisplay method (
http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg03293.html). Current 
code base just grabs the display for you if not provided.  I seem to have 
a vague memory where the auto-grab of the PlatformUI display was supposed 
to be done by the WorkbenchJob, but not a UIJob. 

Working backwards, I've got a set of the Eclipse UI oriented plug-ins 
imported (some, not all).  I've been searching for references to see if 
there is a common strategy on when to use UIJob vs WorkbenchJob. 

Given the set I have in my workspace - I see 49 UIJob refs and 28 
WorkbenchJob refs.  I guess I expected a higher percentage of them to be 
WorkbenchJobs.  Even code in the plugin that defines WorkbenchJob seems to 
use UIJob instead. 

Can anyone comment on the strategy for choosing one over the other? 
(Beyond the fact that the WorkbenchJob will ask twice if the platform is 
running (shouldSchedule/shouldRun) and gives you a 'free' done listener 
for the job itself). 

Regards, 

Pat McCarthy

Back to the top