Certainly! I think at this point, I just
need to dig in and start the conversion. That may raise some additional questions.
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On
Behalf Of Craig Setera
Sent: Tuesday, November 03, 2009
9:53 AM
To: dsdp-mtj-dev@xxxxxxxxxxx
Subject: Re: [dsdp-mtj-dev] Bug
285699 - [fiximprove]: The type Preferences is deprecated
What more can I help with at this point? Did my
comments help?
On 11/3/09 8:41 AM, Jon Dearden wrote:
Thanks Craig. I appreciate the help.
Regards,
Jon
Jon,
I apologize for not getting to this. My parents showed up for the
weekend, so I didn't have any time to look too far into this. I did,
however, want to see if I could answer any of your questions without too much
digging tonight... my comments are inline with the questions. Let
me know if this helps and how much more detail you need me to dig into when I
actually get a bit of time.
Thanks,
Craig
Jon Dearden wrote:
Hi
folks,
I have been looking into the use of the deprecated Preferences for Bug 285699 - [fiximprove]: The type Preferences is deprecated. The goal of the fix is to replace the use of Preferences with IEclipsePreferences. I could
use a few pointers from those more familiar with the code. Below is simplified
summary of where preferences are being used followed by a few questions.
MTJ Core
The deprecated Preferences are
obtained from MTJCore via getPluginPreferences(). Preferences are used by:
- MTJCore
- AntennaBuildExport
- OTAServer
- EmulatorRunner
- MidletSuiteFactory
- MTJCorePreferenceInitializer
- PreferenceAccessor
PreferenceAccessor is a helper
wrapper around preferences. In PreferenceAccessor, the
proper IEclipsePreferences appear to
be used only for project preferences while Preferences are used
elsewhere. PreferenceAccessor is called
by:
- PackageBuilder
- PreprocessorBuilder
- StandardPreverifier
- ObfuscatorTool
- MidletSuiteProject
MTJ UI
Preferences are used by:
- AntennaBuildExportAction
- NewMidletProjectWizardPageJavaSettings
- SymbolDefinitionsImportWizardPage
- DeviceManagementPreferencePage
- J2MEOTAPreferencePage
- J2MEPreferencePage
- NewJ2MEProjectPreferencePage
- ObfuscationPreferencePage
- PackagingPreferencePage
- PreprocessPreferencePage
- PreverificationPreferencePage
- SymbolDefinitionsImportWizard
- MTJUIPreferenceInitializer
Preferences from JavaCore are used by:
- SourceViewerInformationControl
Questions:
In MTJUIPreferenceInitializer, there is a
method initializeDefaultPreferences() with the
comment “Synchronize the preferences between
the core and UI plug-ins”. It appears that this method will cause MTJCorePreferenceInitializer.initializeDefaultPreferences(prefs) to be
called twice. What is the purpose of this synchronization?
I don't know about calling it twice, but this was the
standard way to initialize default preferences in the earlier Eclipse support
before IEclipsePreferences came along. An "initializer" was
called by the platform to set the default values into the Preferences
objects. This is now handled by the "default scope" preferences
as you've been seeing.
IEclipsePreferences Default
scope should apply to defaults. Are Instance scopes most appropriate for
project settings and Configuration scopes most appropriate for MTJ preferences
settings?
In fact, there is actually a project-scope as
well. There are multiple implementations of the IScopeContext interface:
- org.eclipse.core.runtime.preferences.DefaultScope - For default values.
Searched if there isn't a definition in another scope.
- org.eclipse.core.resources.ProjectScope - Preferences that are tied to a
specific project
- org.eclipse.core.runtime.preferences.InstanceScope - This is the same as a
workspace-scoped preference
- org.eclipse.core.runtime.preferences.ConfigurationScope - These preferences
apply to *all* instances
In our existing code, are we using the deprecated Preferences for all MTJ
workspace-level preferences and IEclipsePreferences for
project-level preferences? Is it a simple case of replacing the use of Preferences with
Configuration scope IEclipsePreferences?
At least in EclipseME days, there were two levels of
preference storage. Project-level and Workspace (instance) level. I
don't know that there were many (any?) configuration-scoped values. So...
In the end, the mapping should be pretty straightforward... Anything at
project-scope should be mapped to ProjectScope and everything else should be at
InstanceScope. Any default values in the initializer should to into
DefaultScope.
Regards,
Jon
---
Senior Software Developer, Eclipse Tools
Research In Motion
905-629-4746 x15333 / Mobile:
519 500-23167
jdearden@xxxxxxx
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
---------------------------------------------------------------------