Community
Participate
Working Groups
This bug is created to support bug 249593. JDT launching sets compiler options to match the default JRE on initial (fist time) workspace startup. We only overwrite preference settings if they match default settings. However, if a client uses the preference override mechanism to override default settings, we cannot detect that the JDT defaults have been overridden (we just see that the settings are default, and go ahead and overwrite them). To fix this issue, we need API from JCore that tells us if compiler settings should be modified to match the default JRE (i.e. have they been modified from JDT's default settings?).
Hello, can you give a time estimate of this bug? Are you planning to provide the mentioned APIs? (to allow the depending bugs to be addressed)?
(In reply to comment #1) > Hello, > can you give a time estimate of this bug? > Are you planning to provide the mentioned APIs? (to allow the depending bugs to > be addressed)? > Unfortunately I have no clue for now what will be the 3.6 dvpt plan for JDT/Core. So, I put back this bug in the JDT/Core inbox waiting for the next release plan...
DJ, is there any way to determine where default preference settings originate from (i.e. from a bundle's preference initializer vs. product overrides)?
Nope.
DJ, how/when are product overrides applied to preference stores? Would a preference change listener be able to tell that defaults are being modified? (or does this happen before listeners are in the loop?)
Unfortunately the listeners are registered after the creation of the node, which is too late... the defaults have already been applied. DefaultPreferences#loadDefaults shows the order that the defaults are applied. Also, this doc here is a summary doc with the same info: http://eclipse.org/eclipse/platform-core/documents/user_settings/plugin_customization.html Off the top of my head I can't think of anything here... it is too late for listeners and it doesn't sound like you could use the presence of a particular value to indicate state.
DJ, in bug 249593 there is a patch that checks if any preferences are different from default. JavaCore.getDefaultOptions() returns default options, while new CompilerOptions().getMap() returns compiler options with applied preferences. I really do not remember if this is just a bit better heuristic or if it always work, but the patch attached to 249593 allowed for using plugin_customization.ini.
What I don't like too much with this api is that it is limited to some specific options only. What you really want is an immutable default options from JDT/Core and then the code you put inside the new method in JavaCore could be used in the client code without being API. The problem you are having is that the JavaCore.getDefaultOptions() is affected by the usage of the plugin_customization.ini file. Having this could let you query any option vs the default options in order to find out if it has changed. How does this sound ?
Created attachment 150270 [details] Proposed fix First draft. Please provide feedback. jdt.launching patch should be updated to use this new method.
(In reply to comment #9) > Created an attachment (id=150270) [details] > Proposed fix > > First draft. Please provide feedback. > jdt.launching patch should be updated to use this new method. Looks good to me except the added private method in JavaCore. I'd rather prefer: public static Map getOriginalDefaultOptions(){ return Collections.unmodifiableMap(Util.getOriginalDefaultOptions(null)); }
Created attachment 150272 [details] Updated patch based on Frédéric's comment
Looks good to me. The Javadoc might be more explicit on the meaning of "original" - i.e. these are the default settings as defined by JDT core, and the "default" options are the settings defined by an installation/product/configuration (i.e. could be different).
I'll make the documentation clearer about what default means in the context of this new API. Once the API is defined, client code can check the set of compiler options they are interested in like this: public static boolean isCompilerOptionsOverriden(){ Map defaultOptions = JavaCore.getDefaultOptions(); Map originalDefaultOptions = JavaCore.getOriginalDefaultOptions(); Set compilerSettings = new HashSet(5); compilerSettings.add(JavaCore.COMPILER_COMPLIANCE); compilerSettings.add(JavaCore.COMPILER_SOURCE); compilerSettings.add(JavaCore.COMPILER_CODEGEN_TARGET_PLATFORM); compilerSettings.add(JavaCore.COMPILER_PB_ASSERT_IDENTIFIER); compilerSettings.add(JavaCore.COMPILER_PB_ENUM_IDENTIFIER); for (Iterator iterator = compilerSettings.iterator(); iterator.hasNext();) { String optionName = (String) iterator.next(); if (!equals(optionName, originalDefaultOptions, defaultOptions)) { return false; } } return true; } private static boolean equals(String optionName, Map defaultOptions, Map options) { if (defaultOptions.containsKey(optionName)) { return options.containsKey(optionName) && equals(defaultOptions.get(optionName), options.get(optionName)); } return !options.containsKey(optionName); } private static boolean equals(Object o1, Object o2) { if (o1 == null) { return o2 == null; } return o1.equals(o2); }
Created attachment 150297 [details] Updated patch based on Darin's comment
Released for 3.6M3.
I think we should re-open this bug, based on bug 293331. A new "override" scope could be used in place of this new JDT API - and avoid any API on JDT's part.
Agree with comment 16.
I backed out the changes in JDT launching that use the new JCore API, so it can be removed when ready. JDT UI has not released any changes yet, so there are no more depedencies on the API.
Reopen to revert.
Closing as INVALID. We won't add new API on JDT/Core to fix this.
