Doorgaan naar hoofdcontent

Java sux with regexes

 Java supports regexes right? Nothing to it! that is so nice about it

Only after 15 years, I find out that it does have performance problems.

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5050507

 Is a bug for regexes in java. Of course, they're rare. But how did I hit it?

Well, doing stuff you shouldn't of course. In this case, parsing Json, by searching for a value of a certain key.

That's straightforward, right? "key"\s:\s"([^"]+)"

Well, it would be nice like that, but there's this tiny exception... the value can contain quotes as well. Okay, so we exclude them. Numerous posts tell you how to do it. The trick is to use an or, in essence saying: 'the string \" OR any character which is not a "` 

We can see that in action here

All languages support it.  

but.... not java.

No, it has problems with these groups. It gives stack overflows. And it's a known fact.

So, is this the end?

I thought so. But then, I started digging a little deeper... 

"key"\s:\s"((\\"|[^"])+)" Gives stack overflows... so what about

"key"\s:\s"((\\"|[^"]+)+)" that should be greedyer, maybe that helps? But it was too greedy.

"key"\s:\s"((\\"|[^"\\]+|\\)+)" Wait, what that actually works!?!?

So, our query then becomes: 'the string \" OR any string of characters which are not " or \ OR the string \`

Well, that makes a little bit of sense, but not a lot. 

For now, we'll take it.  

Reacties

Populaire posts van deze blog

Spring's conditional annotation with properties

Spring has a nice @Conditional annotation, to have the option to have beans be available in the context depending a specific condition (Of course, this can also be realized by using @Configuration objects, but that's a different post). Ideally, we'd have the option to have a condition evaluate to true or false depending on a property. Sadly, Spring does not support that out of the box. Googling and looking around gives a partial solution, but the complete one here, so we won't forget: /** * Components annotated with ConditionalOnProperty will be registered in the spring context depending on the value of a * property defined in the propertiesBeanName properties Bean. */ @Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Conditional(OnPropertyCondition.class) public @interface ConditionalOnProperty { /** * The name of the property. If not found, it will evaluate to false. */ String value(); /** * if the p...

OSGI insights without sonar

So I was on a project without sonar. Oh my. Well, it was an OSGI project, so the problems couldn't be that bad, right? But how good were they (and what things were bad?) I found Stan4j , a code analysis tool for eclipse, which draws nice graphs and can handle osgi pretty well it seems. Now I can see that dependencies/bundle names aren't properly aligned (even though OSGI doesn't complain), etc.

JPA and transactions

So I was working with JPA and transactions. Consider the following: In bean 1, with implicit TX 1, managed entities are loaded/created,and returned in bean 2, with implicit TX 2, entities are modified in bean 3, with NO TX, bean 1 is called, and the results are passed to bean 2. and bean 4 is similar to bean 3, but with it's own transaction, TX3 What happens when bean 3 finishes: are the entities updated? What happens when bean 4 finishes, are the entities updated? The answer to this is simple; entities are managed through a persistance context. That context is tied to the transaction. So in bean 2, there is a difference. When called from bean 3, it runs in a different transaction then bean 1, and thus a different persistance context, and thus the entities are not managed 'by this transaction'.When called from bean 4, it all runs in the same transaction, TX3, and the results are persisted.