Dan Allen added a comment - 05/Nov/10 12:17 AM Hm, it turns out there may have been some confusion around what makes up a ValueExpression. A ValueExpression may contain any number of inline variable expressions mixed with literal text. So for this case, we don't need an interpolator. It's just a documentation (and test case) issue. Assert.assertEquals("Cheetahs are fast", expressions.evaluateValueExpression("Cheetahs are # {cheetah.speed} ", String.class)); Assert.assertEquals((Integer) 2, expressions.evaluateValueExpression("# {1 + 1} ", Integer.class)); However, there are still reasons to provide an interpolator. An interpolator would additionally handle replacing positional and named parameters. Positional parameters can be handled by passing the result through MessageFormat: Assert.assertEquals("Jon has a score of 97", MessageFormat.format(expressions.evaluateValueExpression("# {person.name} has a score of {0}", String.class), 97)); In addition to encapsulating the MessageFormat usage, the interpolator can hides the cast of the evaluation result to a String. With the interpolator, this assertion simplifies to: Assert.assertEquals("Jon has a score of 97", interpolator.interpolate("#{person.name} has a score of {0} ", 97)); I'm unsure whether there is value in named parameters. Though for developers familiar with JPQL and Bean Validation, the experience would be similar: Assert.assertEquals("Jon has a score of 97", InterpolatedStringBuilder.expressionString("# {person.name} has a score of {score} ").setParameter("score", 97).interpolate()); This builder concept has already been prototyped in the international module, though with a slightly different focus. It's important to align.