This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 142723

Summary: preference change events when nothing changes
Product: editor Reporter: err <err>
Component: SettingsAssignee: David Strupl <dstrupl>
Severity: blocker CC: vstejskal
Priority: P3 Keywords: SIMPLEFIX
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Attachments: simple patch as outlined
simple patch as outlined

Description err 2008-08-03 21:41:08 UTC
jVi monitors preferences to detect changes that jVi will ignore/override, so
that it can put up a dialog if the user changes something that will be
ignored.  But simply opening Tools>Options and an immediate OK generates lots
of change events (assuming editor-options are the last selected in options
dialog), including the few tab/shift related ones that jVi cares about. This
results in jVi putting up a warning dialog, even though there is nothing to
warn about.  (FYI jVi maintains these options per Document).

(It looks like the change events of interest are only generated for options
that had been chagned in the past.)

(Many events come from FmtOptions$PreviewPreferences (and do not affect jVi
operation), and this discussion and the experimental test patch below does not
affect those.)

As an experiment, the following checks if the value is the same and simply
returns without doing the put if it is. Since the EditorPref's implementation
also keeps track of javaType, this would not necessarily work if the same key
was saved as a different type. The patch fixes the problem that jvi has. If
there is interest, I can fixup the patch as discussed below along with any
further suggestions and attach it to this issue.

In's PreferencesImpl's method

    public @Override void put(String key, String value) {

the following simplistic change takes care of the main issue.

@@ -137,6 +137,10 @@
         try {
+            synchronized(lock) {
+                if(value != null && getSpi(key).equals(value))
+                    return;
+            }
             super.put(key, value);
         } finally {
             if (putValueJavaType.get().equals(String.class.getName())) {

===== The following is a better patch. It has the super.put inside the lock
===== to avoid taking the lock twice.
===== Also, adding the check for a null key as well is needed.

         try {
             synchronized(lock) {
                 if(key != null && value != null && getSpi(key).equals(value))
                 super.put(key, value);
         } finally {
Comment 1 Vitezslav Stejskal 2008-08-04 10:10:25 UTC
Thanks for the patch.
Comment 2 err 2008-08-05 05:51:02 UTC
Created attachment 66550 [details]
simple patch as outlined
Comment 3 err 2008-08-05 05:56:21 UTC
Created attachment 66551 [details]
simple patch as outlined
Comment 4 err 2008-08-05 06:16:40 UTC
Attached the patch as described, does the equals to guarantee no NPE.

(got a time out during the attach, reposted; that's why there are two of them)
Comment 5 Vitezslav Stejskal 2008-08-07 18:18:17 UTC
Comment 6 Quality Engineering 2008-08-08 04:30:52 UTC
Integrated into 'main-golden', available in build *200808080201* on
User: Vita Stejskal <>
Log: #142723 (fixed): applying Ernie's patch for preference change events when nothing changes
Comment 7 err 2008-10-27 00:02:58 UTC
jVi uses the following
    private static class TabSetListener implements PreferenceChangeListener {
        public void preferenceChange(PreferenceChangeEvent evt) {
                   || SimpleValueNames.SPACES_PER_TAB.equals(settingName)
                   || SimpleValueNames.INDENT_SHIFT_WIDTH.equals(settingName)
                   || SimpleValueNames.EXPAND_TABS.equals(settingName)
                   || SimpleValueNames.TAB_SIZE.equals(settingName))
to detect changes made in the editor options panel and put up a dialog if these are changed which warns that jVi will
override these changes.

The patch with this issue is now part of's This used to fix the problem
but no longer does. I have not determined exactly where the event to fire is getting added (I'm seeing all 4 of these
events) but I'm wondering if perhaps FormattingPanelController/ProxyPreferences is relatively new or has been
substantially reworked. I have verified that the code in the patch is not invoked when I hit the OK button; and also
that it is invoked when jVi sets one of the options by doing "prefs.putInt(...)" for example.
Comment 8 Vitezslav Stejskal 2008-10-29 12:07:06 UTC
You could be right. A lot of code around formatting settings panels was added/rewritten.
Comment 9 err 2008-11-05 20:34:24 UTC
The events in question (see below for the precise source) have a "newValue" of null. I'm thinking that for now I can
just ignore the events with null newValue. What do you think?

Additional question. What is the following (probably about those per project settings)? Does jVi care about this?
BTW, should I file an issue about the new per project settings interfering with per file settings that jVi wants to

Product Version: NetBeans IDE 6.5 RC1 (Build 200810171318)
Java: 1.6.0_07; Java HotSpot(TM) Client VM 10.0-b23
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
Userdir: C:\Documents and Settings\erra\.netbeans\6.5rc1

=== Precise source of events

The source of the events can be traced to

    public final class FormattingPanelController extends OptionsPanelController {
        public void applyChanges() {

                // and make sure that they do NOT override basic settings from All Languages
                for(String mimeType : mimeTypes) {
                    Preferences prefs = MimeLookup.getLookup(mimeType).lookup(Preferences.class);

arrived at as shown in the following stack trace

Comment 10 err 2008-11-05 22:30:57 UTC
BTW, in the loop
        for(String mimeType : mimeTypes) {
there were around 24 mimeTypes in the situation I observed.
Comment 11 Vitezslav Stejskal 2008-11-06 10:00:42 UTC
I fixed, could you please try it again? Thanks

> I'm thinking that for now I can just ignore the events with null newValue. What do you think?
This should be fixed with the above changeset.

You can ignore this one.

> BTW, should I file an issue about the new per project settings interfering with per file settings
> that jVi wants to maintain?
Umm, I'm not sure. In general, Netbeans does not support per-file formatting settings and there no plans to do so. I
think the approach jVi uses is a reasonable compromise. I think jVi should listen on per-project formatting settings the
same way as it listens on MimeLookup and display the same warning.
Comment 12 Quality Engineering 2008-11-06 16:29:31 UTC
Integrated into 'main-golden', will be available in build *200811061401* on (upload may still be in progress)
User: Vita Stejskal <>
Log: #142723 - don't fire unneccessary events
Comment 13 David Strupl 2009-04-23 15:50:01 UTC
I guess we can close this one? Or is there anything left unapplied?
Comment 14 David Strupl 2009-05-05 09:29:35 UTC
This was fixed by Vita some time ago. No new information so closing for now as fixed.