>>202
イベントが起こった中で長い処理(test()メソッドの中の)をやっているから他のイベントが処理できなくなっている
なのでその処理(test()メソッドの中の)が終わるまでバーの表示も更新されない
(比べてみれば判ると思うけど実行ボタンはその処理が終わるまで押されたままの表示)

ボタンが押されたイベントは処理(test()メソッドの中の)を起動するトリガとして捉えて
スレッドを起こしてtest()メソッドの中の処理を実行してやるようにすればいいです
そこまでは>>214も挙げているようなところ

SwingUtilities#invokeLaterは必要ないと思う
例えばJProgressBar#setValueとかの中の奥底の方でやっているようなところ

test()メソッドをそのままスレッドを起こして遅いというのは
JProgressBar#setValueを10000000+1も呼んでいるのと
その処理の殆どがJProgressBar#setValueで費やされているから(検証の仕方の問題)

例えば
jProgressBar.setMaximum(100);
とし
if (i%100000 == 0) {
jProgressBar.setValue(i/100000);
}
とかするのでもいいと思うし
実際に進捗モニタとして使われる場合には
JProgressBar#setValueが一連の処理の中で占める割合は僅かなものになるでしょうから
"遅い"というようなことにはならないと思いますよ