I mentioned this on nbdev a while ago but some more users have reported this
as a problem:

When you bring up the Add Breakpoint dialog, the list of breakpoints appear
in random order. This is problematic because in our case, we have something
like 20 breakpoints, which forces the user to scroll the list to get to a common
type of breakpoint like "Method" or "Line".

The problem is delegator/DelegatingDebuggerImpl. In its updateEventSet method
it uses a HashMap to remove duplicate typename() events.

The following patch fixes this problem. After the hashmap has been built,
instead of just iterating over the hashmap and appending each to our result
array, we iterate over the debuggerimpl's instead and add each event if that
event is in the hashmap. Thus we get the debuggerimpl order instead of the
hashfunction order. This does not significantly slow down the updateEventSet
method - the additional code is O(n) just like the original code.

Index: src/org/netbeans/modules/debugger/delegator/DelegatingDebuggerImpl.java
===================================================================
RCS file:
/cvs/debuggercore/src/org/netbeans/modules/debugger/delegator/DelegatingDebuggerImpl.java,v
retrieving revision 1.11
diff -c -r1.11 DelegatingDebuggerImpl.java
*** src/org/netbeans/modules/debugger/delegator/DelegatingDebuggerImpl.java	16 Oct 2001 12:13:11 -0000	1.11
--- src/org/netbeans/modules/debugger/delegator/DelegatingDebuggerImpl.java	30 Oct 2001 00:50:33 -0000
***************
*** 318,327 ****
--- 318,364 ----
          }
          k = breakpointEventsRegister.size ();
          breakpointEvents = new CoreBreakpoint.Event [k];
+ 
+ 	/*
+ 	  We'd like to preserve the order of the breakpoints as specified
+ 	  by each debugger impl. So instead of just doing
+ 
          Iterator it = breakpointEventsRegister.values ().iterator ();
          for (i = 0; i < k; i++)
              breakpointEvents [i] = (CoreBreakpoint.Event) it.next ();
          
+ 	  (where we essentially pick up a random order from the hash
+ 	  function) we iterate over the implementations again, and for
+ 	  each event, we ask the hashmap if the event is a member, and
+ 	  if so, we add it to the array.  Each lookup is O(1) so this
+ 	  is just an O(n) addition to the above code (which is also O(n).)
+ 	*/
+ 	int ins = 0;
+         int i2, k2 = globalEvents.size ();
+         for (i2 = 0; i2 < k2; i2++) {
+ 	    CoreBreakpoint.Event c = (CoreBreakpoint.Event)globalEvents.get(i2);
+ 	    CoreBreakpoint.Event c2 = (CoreBreakpoint.Event)
+ 		breakpointEventsRegister.get(c.getTypeName());
+ 	    if (c2 == c) {
+ 		breakpointEvents[ins++] = c2;
+ 	    }
+ 	}
+         for (i2 = debuggerImpls.size () - 1; i2 >= 0; i2--) {
+             DebuggerImpl impl = (DebuggerImpl) debuggerImpls.get(i2);
+             if (!(impl instanceof EventsProducer)) {
+                 continue;
+ 	    }
+             CoreBreakpoint.Event[] br = ((EventsProducer)impl).getEvents();
+             int j, jj = br.length;
+             for (j = 0; j < jj; j++) {
+ 		CoreBreakpoint.Event c2 = (CoreBreakpoint.Event)
+ 		    breakpointEventsRegister.get(br[j].getTypeName());
+ 		if (c2 == br[j]) {
+ 		    breakpointEvents[ins++] = c2;
+ 		}
+             }
+ 	}
+ 
          AddBreakpointAction aba = (AddBreakpointAction) AddBreakpointAction.
              get (AddBreakpointAction.class);
          aba.setEnabled (k > 0);

After the patch I noticed that the "Class" breakpoint now shows up first
for the JPDA debugger. If you want this to be Line, you may want to tweak
the order of your getEvents() array in your debugger impl.