|
|
Perl is probably the most popular language to offer regular expression support. As such, it makes sense to put Java's regex support in context by comparing it to that of Perl. The distinctions you should be aware of are highlighted in the sections that follow. Generally speaking, J2SE doesn't include some Perl constructs, because Java is a full-featured programming language that offers sophisticated condition and logical paths of execution that are reasonable alternatives to the constructs offered by Perl.
There are several constructs and concepts you might be familiar with from your Perl experience that you won't be able to use in the current implementation of Java. Because these are parts of Perl and not Java, I mention them only briefly here.
Regex String modification isn't supported in Java. This means that you can't modify a String with regex. Strings are immutable objects in Java, so you'll have to use methods that return a new String with the modifications you need. In addition, you'll have to modify your String manually, as opposed to using regex patterns to do so. The earlier search and replace example shows how this works. The original String isn't modified—it simply returns a new String that represents the modification.
Perl's conditional constructs, (?{X}) and (?(condition)X|Y), aren't supported by J2SE's regex. Because Java offers robust if-then-else support as a language feature, there's no need for conditional constructs. Chapter 4 provides examples of how this works.
Java doesn't support the embedded code constructs (?(code)) and (??(code)). Again, these are the sorts of things that can be handled more intuitively, by Java standards, by using Java's built-in language features.
Java doesn't support embedded comments by default, because your patterns can be so easily commented when you create them as Strings. However, you can use the Pattern.COMMENT flag to compile your regex with comments if you really need to. For more on this, please see Chapter 2.
Java doesn't support the preprocessing operations \l \u, \L, and \U.
Possessive qualifiers are unique to Java, but they're very likely to be adopted by other regex implementations soon, because they're such a good idea. Possessive qualifiers continue to retain any qualifying greedy match. That means that once a possessive match is achieved, it isn't relinquished. I discuss possessive qualifiers in depth in Chapter 3.
|
|