Background
On every major Java commercial project I have worked on, I come across numerous Pattern.compile(...) customs, even in code segments that are reused repeatedly, for example.
public String rewriteUrlWhichIsDoneABajillionTimes(final String requestedUrl) { Matcher m = Pattern.compile("^/([^/]+)\\.html$").matcher(requestedUrl); if (!m.matches()) { return null; }
For each project that I found such things on, I told at least one person with whom I worked with this Pattern.compile(...) very slowly and not cached , but the java.util.regex.Pattern class is thread safe. and therefore it can be safely reused, and every time they informed me that they did not know this.
Potential solutions
Proper use of the API
One of the “solutions” could be (try) getting people to read the standard Java library documentation and use the standard library correctly, but prescriptive methods often do not work so well.
Fix previous API usage
Alternatively (or supplementing), it would be possible to “clear” any bad Pattern.compile(...) conditions Pattern.compile(...) , wherever they are, but this will probably be an endless task, because (in my experience) people will continue to use Pattern.compile(...) wrong again and again ...
Fix API
So, why not just just change the Pattern.compile(...) method to combine the objects and return the same instance for equivalent input? - that would instantly apply the fix to the capabilities of billions of lines of code around the world (as long as the corresponding code is run using the JRE, which includes the change). The only possible flaw that I can imagine is that the software will have more memory ... but given how much memory is available on most computers these days, I doubt it will cause problems anywhere other than cases with the edge. On the other hand, a huge number of programs are likely to work much faster. So, why didn't Oracle implement the object pool for Pattern same way they did for strings or for primitives ?
source share