*** Issue 172547 has been marked as a duplicate of this issue. ***

In both methods ResultView.closeAll(ResultView.java:557) and ResultView.closeAllButCurrent(ResultView.java:544)
the same the problematic casting:
----
JTabbedPane tabs = ...
...
Component[] c =  tabs.getComponents();
...
removePanel((ResultViewPanel) c[i]); // ClassCastException
...
private void removePanel(JPanel panel)
---

Seems code of both  methods mentioned above have been copy-pasted.
One method void closeAll(boolean butCurrent) should be implemented (correctly!) instead of both methods.

*** Issue 172547 has been marked as a duplicate of this issue. ***

Build: NetBeans IDE Dev (Build 200909201401)
VM: Java HotSpot(TM) Client VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01
OS: Linux, 2.6.28-15-generic, i386

User Comments: 
"Close others" on search results tab

Stacktrace: 
java.lang.ClassCastException: javax.swing.plaf.synth.SynthTabbedPaneUI$SynthScrollableTabButton cannot be cast to org.netbeans.modules.search.ResultViewPanel
        at org.netbeans.modules.search.ResultView.closeAllButCurrent(ResultView.java:544)
        at org.netbeans.modules.search.ResultView.access$500(ResultView.java:81)
        at org.netbeans.modules.search.ResultView$CloseAllButCurrent.actionPerformed(ResultView.java:599)
        at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
        at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
        at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)

Created attachment 88019 [details]
stacktrace

This issue already has 5 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=158732

Behavior of the JTabbedPane has been changed since Java 1.6.
In Java 1.5 the method jTabbedPane..getComponents() returns only previously added tab components, since Java 1.6 it also
returns various internal components like javax.swing.plaf.basic.BasicTabbedPaneUI$ScrollableTabButton,
javax.swing.plaf.basic.BasicTabbedPaneUI$ScrollableTabViewport. 
A set of returned internal components depends on L&F. 

Since Java 1.6 API of the JTabbedPane has also been extended by the methods for processing the tab components, but we
must not use it until the Java 1.6 is lowest demonstrator for the NetBeans.

Hence, I'll provide a primitive solution:

if(c[i] instanceof ResultViewPanel) {
    removePanel((ResultViewPanel) c[i]);
}

I've tested it on Java: 1.6.0_13; Java HotSpot(TM) Client VM 11.3-b02, and it works well.

Fixed in the main trunk
http://hg.netbeans.org/main/rev/5175e1f10fb9

You are allowed to use JDK 6 API, but only via reflection (such that compilation does not fail) and only on the
condition that IDE is running on JDK/JRE 6 (or later). So you must implement two branches of code - one for JDK/JRE 6
(or later) and one for JDK 1.5.

Integrated into 'main-golden', will be available in build *200909220201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/821c957b01da
User: Victor G. Vasilyev <vvg@netbeans.org>
Log: Refactoring to avoid duplication of code and issues (see #172546 and duplicate #172547)

Marian,

I've considered implementation via reflection as a fix for this issue, but I didn't do so, because:
1. the result contains redundant and unclear code;
2. I've not found any reasons to use new Java functionality under version 1.6 and later in this case.

Anyway all pieces of code where the reflection is used as the bugs fixing for the issues Java 1.5/1.6 must be rewritten
when Java 1.6 will be lowest demonstrator for the NetBeans. But, note, there are no needs to rewrite this fix, of
course, if all is OK.

Do you guess this fix won't work correctly in future? 
May be exists an unknown to me policy of the NetBeans that says "approach with reflection must be used"?

Sorry, my note was not meant to be a command. The sentence "So you must implement two branches of code - one for JDK/JRE
6 (or later) and one for JDK 1.5." should actually begin with "So if you decide to use JDK 6 API, you must implement
two...".

Of course, if your fix works and it is not a mess of hacks, there is no reason for changes.

No problems, and don't worry about your sentence. 
I've interpreted the "must" according to the http://www.ietf.org/rfc/rfc2119.txt :-) not more.

OK I'll keep the code "as is".

v/c