Created attachment 66700 [details]
Stacktrace

SQL history issue.

enabled is overridden

removed enable()

10577167a600

Integrated into 'main-golden', available in build *200808120201* on http://bits.netbeans.org/dev/nightly/
Changeset: http://hg.netbeans.org/main/rev/10577167a600
User: John Baker <jbaker@netbeans.org>
Log: #143060 Startup regression: org.netbeans.modules.db.sql.editor.ui.actions.SQLHistoryAction

mrkam, please verify that this issue is really fixed.

According to 080819 Dev build test results this class is still being loaded.

Created attachment 67796 [details]
Stacktrace

SQLHistoryAction is no longer enabled so I don't see how it could be loaded at startup.

Are you sure you used the Aug 19 build ?

Why is the latest attachment named mysql2.txt ?

Yes, this is fresh build of trunk I made today, the name of the attachment is quite random, please don't pay attention
to the name of this file.

If you would like to reproduce test results, edit ide.kit/build.xml to add the following line: 
    <property name="test.run.args" value="-ea -XX:PermSize=32m -XX:MaxPermSize=200m -Xmx256m -Xverify:none"/>
open ide.kit project in IDE and invoke Run File over WhitelistTest in functional test packages.

Regression? Not sure how a loading class with no instance fields can have a significant performance overhead and be
considered a regression. The complex registration of Actions.alwaysEnabled() does not pay off IMHO. Sorry.

I have to reopen this bug, as the resolution seems to be one of "my feature is the most important one in the IDE and I 
want to feed it to every user of NetBeans regardless of the fact that they do not touch SQL at all" attitude. I am 
sorry, but performance team has to fight with this attitude widely spread among our development team.

If you are still not convinced, the performance team is ready to have a teaching session when we can explain you and 
your team why fighting with "my feature is the most important one" attitude is essential to success of NetBeans in 
supporting enormous range of less and less related technologies.

> my feature is the most important one in the IDE and I want to feed it
> to every user of NetBeans regardless of the fact that they do not touch SQL at all

Irrelevant. Let's keep this discussion technical. Please provide data proving that instantiating SQLHistoryAction slows
down startup. 

Also, please explain the stack trace in desc9. I don't see a trace of the SQL editor there, just core loading
SQLHistoryAction. Please make core not load the action, or load it lazily instead.

Another thing: SQLHistoryAction is registered in the toolbar of the SQL editor, just other action, such as RunSQLAction.
Both these actions have shortcuts. How come you care about SQLHistoryAction, but not RunSQLAction?

1. Obviously it occupies permanent memory.
2. Fix both actions if you are able.

> Let's keep this discussion technical.

I would love to, so please stop playing games with reassigning, stop looking for reasons why you do not want to help 
us improve the IDE and try a least a bit to fix the issue. It is not hard, if you find at least a bit of will.

Again:

> Also, please explain the stack trace in desc9. I don't see a trace of the SQL editor there, 
> just core loading SQLHistoryAction. Please make core not load the action, or load it lazily instead.

Somewhere above you say "feed it [...] regardless of the fact that they do not touch SQL". Well, the SQL editor doesn't
do anything apart from giving the action a shortcut. I don't know why that should cause the action to be initialized.
Please consider not loading the action until you actually need it. If that is not possible, then please consider
accepting the burden that it has on the permgen. I believe the burden is not high (correct me with numbers), and that
actions are such a basic IDE concept (connected to shortcuts, etc.), that they can be loaded at startup if necessary.

Is there any more documentation than the API docs to fix this ?

> Well, the SQL editor doesn't do anything apart from giving the action a shortcut. 
> I don't know why that should cause the action to be initialized.

I tried! There is a patch in issue 133009 which basically does this:
http://www.netbeans.org/nonav/issues/showattachment.cgi/67930/X.diff
but it does not work. Looks like the only way to go is to use the declarative actions like alwaysEnabled more.

Re: documentation. We have 
http://bits.netbeans.org/dev/javadoc/org-openide-awt/org/openide/awt/Actions.html#alwaysEnabled(java.awt.event.ActionListener, 
java.lang.String, java.lang.String, boolean) or you can use the actions wizard in apisupport.

I think that this issue should be waived for 6.5 until Actions can be loaded without using enabledAction

It still doesn't make sense to me that some actions are not whitelisted when they don't use enabledAction.

Good to know. Suggest postponing this issue until issue 133009 is resolved. However, even in case issue 133009 is not
fixed I do not see it a big problem if the actions which have a shortcut are loaded. I simply do not believe that 2% of
startup time (5% before LazyAction, 3% with it) make a big difference.

I also realized that alwaysEnabled() would require me to duplicate the display name bundle label and the icon path in
both layer.xml and the class. This breaks the DRY principle

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

and I see it as another reason to avoid alwaysEnabled(). It also requires a factory method! Too much complexity, too
little gain.

Is there still any missing information? If not, I would remove INCOMPLETE keyword.

If there's agreement to postpone this until issue 133009 is resolved then I presume this class needs to be added to the
blacklist ?

Fix the action registration for 6.5 by using Actions.alwaysEnabled, please. Issue 133009 is unrelated. My reference to 
it just explains why shortcut needs to be initialized on start. Use Actions.alwaysEnabled as much as you can. If you 
need help writing the registration, please use the Action wizard in apisupport from NetBeans 6.5 and generate new 
action.

> please use the Action wizard in apisupport from NetBeans 6.5 and generate new action.

The Action wizard can't be used for the SQL Editor.  There is no "Global toolbar"   
And I have no idea which category the action would fall under.

Why not basically describe what is needed to create an action in a NetBeans tutorial or as part of the help topic?
The wizard doesn't create actions for all places to use an action.

I am not sure I am qualified to write tutorial just for you, but you can try to:
1. create the action using wizard
2. tweak the layer file the way you want to in editor
2a. create a shadow that links to newly create action from the place of the original action
This fix is quite straightforward. It is build around just two concepts: usage of wizard, editing of layer file. 
Simple task for any NetBeans Certified Engineer.

These have been done:
> 2. tweak the layer file the way you want to in editor
> 2a. create a shadow that links to newly create action from the place of the original action

The problem is the wizard is not suitable for adding an action to a non-Global toolbar.  The section in the Wizard says
"Global toolbar"

My complaint  that the Wizard is not intuitive and documentation is lacking.  For a new feature there should be better
documentation.  I can file an issue.

ca286d806605
WhitelistTest no longer lists SQLHistoryAction, so I guess it's fixed now after this change

Integrated into 'main-golden', available in build *200808301401* on http://bits.netbeans.org/dev/nightly/
Changeset: http://hg.netbeans.org/main/rev/ca286d806605
User: John Baker <jbaker@netbeans.org>
Log: #143060 Startup regression: org.netbeans.modules.db.sql.editor.ui.actions.SQLHistoryAction

Fix was incomplete

When I wrapped the alwaysEnabled action in the layer file, at runtime when right-clicking, there was a Mnemonic exception.
So, it appears I need to set the mnemonics again even though mnemonics are set in the layer file.

java.lang.NullPointerException
	at org.openide.awt.Mnemonics.findMnemonicAmpersand(Mnemonics.java:169)
	at org.openide.awt.AlwaysEnabledAction.extractCommonAttribute(AlwaysEnabledAction.java:91)
	at org.openide.awt.AlwaysEnabledAction.getValue(AlwaysEnabledAction.java:78)
	at javax.swing.AbstractButton.setMnemonicFromAction(AbstractButton.java:1236)
	at javax.swing.AbstractButton.configurePropertiesFromAction(AbstractButton.java:1140)
	at javax.swing.JMenuItem.configurePropertiesFromAction(JMenuItem.java:359)
	at javax.swing.AbstractButton.setAction(AbstractButton.java:1087)
	at javax.swing.JMenuItem.<init>(JMenuItem.java:122)
	at org.netbeans.modules.editor.NbEditorKit$NbBuildPopupMenuAction.createLocalizedMenuItem(NbEditorKit.java:402)

As the owner of the module in question, I oppose to fixing this issue using alwaysEnabled() for reasons explained in
desc18 and desc22. I would also want to get John's agreement to back out changeset #ca286d806605.

BTW the information that is missing in the issue is one that would convince me that this is a real issue.

And I still believe the core problem (if there is a problem at all) is tracked by issue 133009.

#ca286d806605 already reverted by John in issue 145751.

This class was not being loaded in 080831 but is being loaded in 080902 again.

Marking as P4 according to issue 143075 desc7.

Reassigned to new owner.

Fixed by integration of issue 152576. Additional test added as ergonomics#d70f3c8ce2bf

Integrated into 'main-golden', will be available in build *200908061401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/d70f3c8ce2bf
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #143060: Don't load actions just to assign them a shortcut

Thanks for the blacklist addition, though I still think something is fishy here.

From reading the code, it seems that SQLHistoryAction, as a SQLExecutionBaseAction, is not usable as a singleton action
at all; actionPerformed specifically does nothing, and it is marked a ContextAwareAction. In other words, it would be
appropriate in an editor popup, perhaps an editor toolbar, somewhere where a context will always be passed - but not as
a globally registered action (such as in the Shortcuts folder, which triggered this bug report before issue #152576 was
fixed).

If I am wrong and this action really works as a non-CAA, then using Actions.alwaysEnabled as jtulach suggested would be
more appropriate. The fact that it sometimes calls setEnabled(false) is not a big deal - this call will be honored once
the real action is loaded; it just means that the _first_ time the action is invoked in a given IDE session, it is
possible that sqlExecution.isExecuting(), which it should handle gracefully (e.g. do nothing or beep); subsequently it
will enable & disable normally.

abadea's DRY objection to Actions.alwaysEnabled in desc22 is based on a misunderstanding, by the way - any attributes of
the action such as display name, icon, etc. which are defined statically in the layer need not additionally be defined
in the Action subclass, since the proxy Action that is loaded from
Actions/System/org-netbeans-modules-db-sql-editor-ui-actions-SQLHistoryAction.instance will offer these static values as
defaults (which is why it is permitted for the delegate to be a bare ActionListener rather than a full Action).

This smells indeed. All subclasses of SQLExecutionBaseAction are only intended to be used as CAA's -- they need the
SQLExecution context. SQLHistoryAction seems to need a SQLExecution too, but it only uses it to get access to the editor
pane corresponding to the editor toolbar from where the action was invoked, and then it seems to ignore this editor pane
(see SQLHistoryPanel in db.core) and uses EditorRegistry.lastFocusedComponent(). 

While it seems the SQLHistoryAction could be made global, I'm not sure it would be practical. Having access to the
SQLExecution context of the current editor is generally useful. Let's consider SQLHistoryAction non-global and CAA only
for the purpose of this discussion.

Jesse, are you saying that non-global actions such as SQLExecutionBaseAction's subclasses should not be registered in
the Shortcuts folder? I did so because I didn't know another way to assign the action a keyboard shortcut. What's the
right way to do it then?

If you do not need to shortcut to be changable (by user or by different profiles), then you can place your keystroke, 
key and action directly to JComponent.getInputMap() and JComponent.getActionMap(). If you think this would be more 
appropriate in this case then reopen and let new owners fix this.

The user should be able to change the shortcut, just as it is the case for most actions.

As far as I know the Shortcuts folder is intended only for global actions with no context. If you are interested in
registering an action for a particular editor type with a particular default accelerator, you will need to use some
editor-specific registration that I do not know much more about.

http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastStableBuild/artifact/nbbuild/build/generated/layers.txt

shows items such as

Editors/text/x-java/Keybindings/NetBeans/Defaults/o-n-m-editor-java-keybindings.xml

which I presume is the format you would use. But best to ask editor developers if in doubt. There seems to be little
relevant information at

http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor-settings/overview-summary.html