Pros and cons of Java rules engines

What are the pros and cons to adopting the Java rules engines JESS and Drools?

Use a rule engine if you need to separate the business rules from the application logic. The Does Your Project Need a Rule Engine article has a good example:

For example, a typical storefront system might involve code to calculate a discount:

if (product.quantity > 100 && product.quantity < 500) {
  product.discount = 2;
} else if (product.quantity >= 500 && product.quantity < 2000) {
  product.discount = 5;
} else if (product.quantity >= 2000) {
  product.discount = 10;
}

A rule engine replaces the above with code that looks like this:

ruleEngine.applyRules(product);

Up to you to decide whether putting a rule admin console in the hands of non-technical people is a good thing or not :)

More details in Should I use a Rules Engine?, Why use a Rule Engine?, Some Guidelines For Deciding Whether To Use A Rules Engine and on Google.

Are there any other players?

Other players include JRules, Corticon (JRules is the most famous IMO - which doesn't mean the best).

how do they compare in other areas like ease of use, performance, level of integration with your code?

Can't tell you precisely, I only have a little (positive) experience with Drools. But you'll get some feedback from blog posts like JBoss Drools vs ILog JRules - an anecdotal story (be sure to read it) or Working with Drools from a JRules perspective. I'm sure you can find more of them on Google (but I would give Drools a try).

We are evaluating rules now for use with our application server. We have come across OpenRules, which is easy to integrate with Java and, as far as our testing has shown, fast enough. The main advantage of OpenRules above the others is the way the rules are modified and handled. It all happens in Excel tables, which is the easiest way for non-programmers. Everybody involved, even the non-technical people, understood everything perfectly :-)

We also have drools integrated, but the rules are way more complicated to understand as it is a more programmatic approach. That's why we - most likely - will stick to OpenRules.

When we needed a rules engine, we decided to roll our own, because the available ones were far too complicated for our simple tasks. If you are even remotely experienced with parsing expressions users may put in, this is not very hard to do. In our case, most of the spec is handled by an XSD and only a few of the fields are parsed further.