Java Regular Expressions

Simon P. Chappell writes "Regular expressions (regex to their friends) are an incredibly powerful addition to most programmer's personal toolkit of techniques. Programming using a language that doesn't support them can be frustrating if you need to do any amount of non-trivial string handling. Java was just such a language until the release of the 1.4.x series. Sure, there were libraries like ORO that would provide regex support, but it wasn't built in and not many companies allow the use of 3rd party libraries. With version 1.4.x, the corporate Java developer in the trench, received the power of regular expression pattern matching." Read the rest of Simon's review. Java Regular Expressions author Mehran Habibi pages 255 (7 page index) publisher Apress rating 8/10 reviewer Simon P. Chappell ISBN 1590591070 summary A great starter for using regular expressions in Java

The book seems targeted towards those who have a solid level of Java programming skills, but who have not yet used the java.util.regex package. I see two types of Java programmers who might not have used the regex package, those who do not know about regular expressions and those who know them, but have not yet used them within Java. This book should satisfy both sets of users. The first group will be benefited by the general introduction to regular expressions and the gentle introduction to using them within Java. The later group will benefit from the more advanced material in the book.

The book is nicely structured and progresses easily through its subject matter. The first chapter is an introduction to regular expressions. While this is most obviously for the readers new to the subject, it will be useful for those more experienced, because not all regex engines are created equal and this chapter lays out the particular dialect of regular expressions used by the Java 1.4.x regex engine. The second chapter introduces the object model used by java.util.regex. This gives detailed explanations of the Pattern and Matcher objects as well as the new regular expression methods added to the standard String class.

The third chapter takes the reader into advanced Regular expressions. While there is much that can be done using just the Pattern and Matcher objects, the path to the full power of regex travels through an understanding of groups (and subgroups) and qualifiers. Regex groups are hard to explain until you've seen them in action, whereupon you may find yourself wondering how you'd ever managed without them before. Mr. Habibi does an excellent job, both explaining them and introducing us to the unusual noncapturing subgroups. (I'd never heard of these before.) Qualifiers are the other side of the same coin with groups. While it's one thing to define a group and whether it's expected and to be captured, it's equally important to be able to describe the expected occurrence of those groups using qualifiers.

Chapter four tackles the interesting challenges of using regex in an object-oriented language. Mr. Habibi describes the general principles of use of regex as similar to those used with SQL through the JDBC interface. These principles are the optimisimg of connections, batching reads and writes, storing patterns externally, Just In Time compilation of patterns and remembering that not every piece of String handling code needs to be written as a regex. All very useful advice.

Chapter five is the big examples chapter. All of the examples are intended to be practical; the kind of thing you might have to address at the day job. With examples covering Zip codes, telephone numbers, dates, searching text files and even validating an EDI document, he seems to have delivered on that assertion. There are further examples in Appendix C, if the afore-mentioned patterns aren't enough.

The writing and progression of material are good. The examples are very well thought out and explained. Many of the examples are built from first principles. Mr. Habibi seems to want to not only teach you how to use regular expressions, but also how to design them. He does this by working up from an understanding of the data until he has a working regex.

While it doesn't make any promises about being an encyclopedia of regex patterns, this book does contain enough of the normal business patterns to be a useful initial reference work, before turning to the Internet to search for patterns.

If you want an encyclopedic reference work on regex, then buy Jeffery Friedl's Mastering Regular Expressions which is published by O'Reilly. This is not that book, preferring to stick with the practical usage of regex.

This is a great starter book, for developers who are new to using regular expressions in Java."

You can purchase Java Regular Expressions from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

When speed matters

[SIGALRM]

there were libraries like ORO that would provide regex support, but it wasn't built in and not many companies allow the use of 3rd party libraries

For those who can utilize third-party libs, consider evaluating this DFA/NFA automaton, a regexp package that is significantly faster than java.util.regex.

However, like many things in computer science, speed gains come at a price. In this case, the regular expression language supported is not quite as rich as the JDK implementation.

Re:When speed matters

[The Snowman]

Here is the class I assume the parent is referencing: Formatter class.

Essentially what happens is you don't have C-style varargs, the JRE silently creates an array for you when you pass the arguments. This doesn't waste "gobs of heap space" like the parent says, it uses the same amount as it would using the stack. Remember, these are objects, and Java never passes objects by value -- always by refence. So each argument wastes one machine word (usually 32 bits). Whoop de fucking doo. And, since it uses references, the only allocation/deallocation is the temporary array. And in 1.5 if not previous versions, this is very very fast. With a JIT compiler you'll hardly notice it. I do agree that the decision to make the class "final" is shitty, but honestly, I don't see how subclassing it would be a huge advantage. It would be like subclassing the java.lang.String class. Sure, you could add some nifty stuff, but it's not a big deal.

As a person who earns his living off of J2EE, I know its strengths and weaknesses. I am not a fanboy, however. I am more than willing to give Java hell when it deserves it. I think string handling in general is not as well-organized or easy to use as it could be, but it is certainly capable. I rarely use sprintf() style string formatting anyway, even in C++. I find it much easier to use iostreams, which are typesafe and almost as fast as sprintf(). In Java I just use string concatenation, and the formatting classes when I need it. It isn't perfect, but it works well enough and sure isn't slow.

Re:When speed matters

[CompSciStud4U]

I'll take the bait. When Java was introduced in 1995 almost all compiler research had been on static compilation, such as in C or Fortran. When the popularity of Java started to rise a lot of research effort, such as at IBM, was switched over to Just In Time (JIT) compilers. This was a pretty raw field at the time so the Java was horribly slow compared to C.

Fast forward 11 years and the situation is quite different. I'm not sure about the Java compiler that comes distributed with the SDK, but a JIT compiler and virtual machine from another commerical sourse (I'll just stick with IBM) is now incredibly optimized compared to 1995. Large amounts of research have been done to catch up with the fact that statically compiled languages had a 30+ year headstart. And JIT compiled languages could one day be faster than a statically compiled one due to new dynamic compilation techniques that use system resource data, such as cache misses, collected by the VM to continuously reoptimize portions of the byte code.

And even the overhead of garbage collection may soon be lowered dramatically due to research at the University of Massachusetts http://www.cs.umass.edu/~emery/pubs/f034-hertz.pdf

I'm not going to say that Java is faster than C (or in this case Perl, a language specifically designed for parsing regular expressions), but the speed gap between the two is constantly closing to the point where it doesn't really matter that much anymore.

My main complaint

[kbielefe]

My main complaint about java regexps is that all the backslashes have to be quoted with a backslash, making them completely unreadable compared to a language that supports regular expressions natively, like perl (no, a standard library is not technically native support). "\d" becomes "\\d" and so forth. Does anyone know a simple way around this? We just started using java regexp's at work, so the extra backslashes don't bother most people, but they are extremely annoying to those of us with a lot of perl experience.

P.S. How many slashdotters thought they'd be rolling in their graves by the time they heard an example of where perl is more readable than java?

Re:My main complaint

[masklinn]

Actually, Python's literal strings are NOT """

.

""" is for multiline strings (' and " only accept one-line strings or antislash linebreak escapers), literal python strings are rawstrings and created by prefixing any string (be it ', " or """) by the "r" character (as in r"this is a raw strings" "but this is not).

Re:My main complaint

[_xeno_]

Backslashes in a .properties file have to be escaped with (guess what?) a backslash.

So it, unfortunately, solves nothing.

If you don't mind XML, you can use the XML properties format, but you're still adding a lot of extra code just so you don't have to deal with escape characters. There's, unfortunately, no good solution in Java. (There are no raw strings in Java.)

Re:Recursion?

[addaon]

Of course, things like those presented are not regular expressions, no matter how loose perl might be with the term.

Re:Recursion?

[Anonymous Coward]

Regular expressions are only for regular languages. They are the simplest type of language and use a simple state machine (automaton) to do their language recognition.
Context free languages may have recursion. They use a state machine (pushdown automaton) and a stack to recognize thier languages.
http://en.wikipedia.org/wiki/Context-free_language
This also contains links to other families of language and info on the automaton that can recognize them.
Welcome to Theory of Computing!

regex coach

[mgkimsal2]

I spoke about the "regex coach" tool from http://weitz.de/regex-coach/ on my podcast (shameless plug!) http://webdevradio.com/ - it's a great tool for helping visually walk through the regex creation process, especially for complex needs.

Re:Java sucks

[Derkec]

You don't have to throw anything there, you should just have one clear return in your method. You also probably should't be compiling your pattern every time.

Try:

private static final Pattern pattern = null;
 
static {
  try { pattern = Pattern.compile("Java"); } catch (PatternSytaxException pse) {;}
}
 
public String theTruth(String string) {
  Matcher matcher = pattern.matcher(string);
  return matcher.replaceAll("something I don't know jack shit about");
}

Still not as compact but at least there aren't any tildes in there. I wonder if there would be a more compact way to do it. This seems terribly heavy weight for such a simple example. Oh, wait! There is!

public String theTruth(String string) {
  return string.replaceAll("Java", "this is really easy");
}

So now we compare:

public String theTruth(String s) { return s.replaceAll("Java", "this is easy") };

To:

sub theTruth($) { shift; $_ =~ s/Java/Bloated piece of shit/; return $_; }

So the Java code ends up being a handful of characters longer and much easier to read. I'm not saying that Java is the ideal Regex language, but your example sucked.