I have been taking a Java class recently, but thus far had not really taken the step of rolling up my sleeves and doing some real coding other than the standard Hello world, Hanoi towers, Fibonacci sequence stuff. I finally settled on trying to take a wack at a bug in jEdit. Much of the problem was solved by the people posting in the thread, especially Denis Dzenskevich. This combined with a little bit of digging in Sun documents on the Pattern and Matcher classes and a good Javaworld article by Cristian Mocanu on regular expressions in Java pointed to the problem. First, I converted the long in-the-wild file this was freezing on to a simple and legal five line Perl program. After doing this, I saw the problem. jEdit was using a greedy quantifier in the regular expression where it should have been using a reluctant quantifier. I sent in a patch, notified the original bug poster and he mailed me that it fixes the jEdit freezing problem for him.
The problem still exists if the Perl code has malformed backslashes in the second field of a tr statement using curly brackets. However, the fixed bug is rare enough that it wasn't discovered until June, and unimportant enough that my patch hasn't been committed over the past week, so this rarer case is an even lower priority to look at. Which brings to mind a jEdit bug "FindBugs" brought to light - two uses of "Math.abs(new Random().nextInt())". Now on the 1 in 4 billion chance the random number is the absolute minimum possible, will Math.abs return a positive number? The answer is no (I tested it). Again, the odds of this happening are low enough that a patch is low priority.