This issue was originally marked as duplicate of issue 171713, that is already resolved. This issue is still valid, so this seems to be another issue, but it might be related.
Build: NetBeans IDE Dev (Build 200911091156)
VM: Java HotSpot(TM) Client VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01
OS: Linux, 2.6.31-14-generic, i386
aldobrucale: Starting nb
Maximum slowness yet reported was 3299 ms, average is 3299
Created attachment 90785 [details]
This issue already has 5 duplicates
Created attachment 90861 [details]
This issue already has 7 duplicates
Created attachment 91012 [details]
This issue already has 20 duplicates
Different issues mostly caused by calling EditorCookie.getOpenedPanes or CloneableEditor.getEditorPane. Honzo is anywhere complete example how to use NbDocument.findRecentEditorPane?
One case is from
Another case is from
I don't think this is a P2 and I agree this will be fixed post 6.8.
Created attachment 91194 [details]
This bug already has 50 duplicates
Created attachment 91448 [details]
Created attachment 91743 [details]
Created attachment 91906 [details]
Created attachment 92319 [details]
Starting up Netbeans, with 3 files currently open in the workspace - 2 java files and 1 jsp
Created attachment 92537 [details]
Created attachment 92721 [details]
Created attachment 92738 [details]
NetBeans starting up and opening projects
Created attachment 93098 [details]
I was opening the IDE when this occured. I have two projects that were in the project tree. One large web project with several thousand files. The other is a small java app with only 6 source files.
This issue has over 200 duplicates, some of them spent waiting over 30s in org.openide.text.CloneableEditor$DoInitialize.initDocument method. It would be good to look at it as soon as possible.
I looked at the few latest snapshots and it seems that this issue is mixing up several problems in different areas. The stacktraces end up in CloneableEditor$DoInitialize.initVisual(), but the call comes from different code, which tries to CE.getEditorPane() for whatever reason. The initialization code in CE is so complicated that I refuse to make any changes in it unless there is a P1 functionality problem. In this particular case, however, there is a possibility that the upper level code does not have to call CE.getEditorPane at all. This will require evaluating the snapshots one by one and analyzing the code in various modules that call CE.getEditorPane.
I have looked at several (the most recent ones from the dev build) and they all involve
calling getEditorPane(). Who is taking care of gototest module nowadays?
GotoOppositeAction is covered by issue #180595.
I will try to evaluate some of the cases.
I have tried to separate the recent reports into different issues (182013, 182017) and then asked Jindra Sedek to update the reporting to better search for duplicates. He adjusted the duplication detection to ignore the CloneableEditorSupport and report the more interesting cases separately.
I am closing this issue as it mixes different issues due to automatic duplicate detection. The new reports should be better searched for duplicates now.