The εοs-toolkit is also a playground project. With the project I'll test out some new ideas of my software mindset. The generic interfaces of Function, Predicate and Supplier should be the nucleus of a simple to use configuration language. Function itself is the core of all. The user should compose functions of functions, combined with Suppliers and Predicates (rules). A Function doesn't mean a function in the case of a functional programming language like Scala. Functional programming constructs are not first class citizen of Java (the εοs-toolkit core technology) and should it never be. But for simple workflows these three bricks are perfect.

In the last few days I'll play with ANTLR. ANTLR is an amazing project and a very simple to understand and use parser generator. With ANTLRworks there is a nice tool to support grammar development. The Maven 2 support comes with the mojo ANTLRv3 plugin which is also easy to use.

The main problem of the ANTLR development seems to me effective testing. ANTLRworks has a mighty interpreter for gramar testing. But the testvalues are not writable for reuse and/or automatic testing. To solve this problem there are two frameworks for automatic testing: gUnit and ANTLR Testing.

My experience with gUnit are funny. With ANTLRWorks interpreter the defined rules are valid. gUnit returns says: the same tests all fails. Oops… Also handling with gUnit artifacts with Maven isn't really nice. The gUnit interpreter returns nothing from its main method to check if the test fails or not fails. Only visual testing works - ugly. The transformation into JUnit also doesn't work.

ANTLR Testing looks ambivalent for me. The use for simple token testing seems easy. But the AST testing looks quite tricky cause defining the AST result for test. But the framework is more Java developer like. So I use it for token testing. For complex AST expressions I developed an own JUnit test environment. It works but I think I must invest a few more time for ANTLR grammar testing.