Community
Participate
Working Groups
Build 3.1m6 In order to better initialize lazy structures, and provide an opportunity for UI to avoid penalty for lazy inits on user action; JDT/Core should provide a hook for performing reasonable initializations. This hook would be invoked from JDT/UI post startup sequence, in background. JDT/Core would not require this API to be called, it would only be some hint for precaching information ahead of time. Naming should be improved, but it has good reminescences for Envy/Smalltalk users.
approved - The spec should probably say that the initialization would be across all projects, and explain whether the call, which is long-running, is blocking or non-blocking.
It would like take a progress monitor as well; and likely should be allowed to grab the workspace lock (would be nice to remove this requirement though). So far it should do: 1. cause CP initialization 2. dummy workspace search query (could induce 1 already + ensure index rebuild occurs if necessary). 3. load build states ? unsure
Philippe, before we add this API we should discuss it in the polish team to double check if this is the way to go.
Dirk - I even believe you should pioneer on this, and if you figure some set of actions, we can encapsulate it in our land (now we provisionned an API addition for it).
There is no need to load build states. If the user does not do a build then he does not need them.
I am only worried about the one scenario where user doesn't know his classpath did change until he does a one method edit (think of container init consequence), and he gets a huge fullbuild then; even though his machine was idle for the past 30 minutes after startup.
Actually 2 cases: 1. noticing that build states got obsoleted: this is more of a migration issue (which is a separate issue). So I agree that loading build states will have no effect. 2. checking early on possible CP change which could invalidate entire build state.
You're basically asking for an incremental build to happen on startup, or shortly after. Even in the migration case, I'm not sure that is a good idea. I would prefer we add a call on JavaProject... something needsToBeBuilt(). We could ask one project on startup & if returns true, then cause an incremental build to happen. But it should still be an option 'Detect workspace migration'.
This is exactly what I had in mind. Note that in migration story, it would be triggered by platform, and could be imposed as a one time effort.
Dirk - do you need anything from us ? If so, pls reopen.
We should discuss this tomorrow on the architectur call again. I still don't know what the overall opinion is.
Will add JavaCore#initializeAfterLoad() which will do a dummy search query on a workspace scope (this will also cause CP initialization to occur).
Added the following API: /** * Initializes JavaCore internal structures to allow subsequent operations (such * as the ones that need a resolved classpath) to run full speed. A client may * choose to call this method in a background thread early after the workspace * has started so that the initialization is transparent to the user. * <p> * This initialization runs accross all Java projects in the workspace. * </p><p> * This method doesn't return until the initialization is complete. * </p> * * @param monitor a progress monitor, or <code>null</code> if progress * reporting and cancellation are not desired * @exception CoreException if the initialization fails, * the status of the exception indicates the reason of the failure * @since 3.1 */ public static void initializeAfterLoad(IProgressMonitor monitor) throws CoreException Added test JavaModelTests#testInitializeAfterLoad()
It should also say: - calling it is optional. Services will lazily perform initialization when invoked. This is only a way to reduce initialization overhead on user actions, if it can be performed before at some appropriate moment. - calling it concurrently is allowed - what scheduling rule is required ?
Improved spec: /** * Initializes JavaCore internal structures to allow subsequent operations (such * as the ones that need a resolved classpath) to run full speed. A client may * choose to call this method in a background thread early after the workspace * has started so that the initialization is transparent to the user. * <p> * However calling this method is optional. Services will lazily perform * initialization when invoked. This is only a way to reduce initialization * overhead on user actions, if it can be performed before at some * appropriate moment. * </p><p> * This initialization runs accross all Java projects in the workspace. Thus the * workspace root scheduling rule is used during this operation. * </p><p> * This method doesn't return until the initialization is complete. * </p><p> * This method can be called concurrently. * </p> * * @param monitor a progress monitor, or <code>null</code> if progress * reporting and cancellation are not desired * @exception CoreException if the initialization fails, * the status of the exception indicates the reason of the failure * @since 3.1 */ public static void initializeAfterLoad(IProgressMonitor monitor) throws CoreException
Jerome, I looked at the code of the method and noticed that it reuses the progress monitor for both calls instead of creating sub progress monitors
Thanks Dirk. Fixed initializeAfterLoad(...) to use SubProgressMonitors.
After discussion with Dirk, it was decided to change the API to be non-bloking. It now looks like: /** * Initializes JavaCore internal structures to allow subsequent operations (such * as the ones that need a resolved classpath) to run full speed. A client may * choose to call this method in a background thread early after the workspace * has started so that the initialization is transparent to the user. * <p> * However calling this method is optional. Services will lazily perform * initialization when invoked. This is only a way to reduce initialization * overhead on user actions, if it can be performed before at some * appropriate moment. * </p><p> * This initialization runs accross all Java projects in the workspace. Thus the * workspace root scheduling rule is used during this operation. * </p><p> * This method may return before the initialization is complete. The * initialization will then continue in a background thread. * </p><p> * This method can be called concurrently. * </p> * * @param monitor a progress monitor, or <code>null</code> if progress * reporting and cancellation are not desired * @exception CoreException if the initialization fails, * the status of the exception indicates the reason of the failure * @since 3.1 */ public static void initializeAfterLoad(IProgressMonitor monitor) throws CoreException
Verified in i20050527-0010
