Home » forums » LtU Forum

Writing a DSL for Java

The site java.net has an article on extending Java with Tasks, code blocks executing in a separate thread. This particular extension may not be very exciting, but perhaps it will introduce the idea of DSLs to a new group of programmers.

The article uses a parser generator called VisualLangLab that seems to be "Yacc with a GUI". Since the goal of the article is to extend the Java language, they need a Java grammar to start with. VisualLangLab comes with a Java 1.4 grammar, so that is what is used.

This means that the Task extension cannot be used with a 1.5 compiler; even though the extension only touches parts of the Java grammar that have not changed between 1.4 and 1.5 (I guess). Could this problem be circumvented if the standard libraries provided a representation of the grammar used in the current platform?

By Henrik Arro at 2004-10-10 18:03 | LtU Forum | previous forum topic | next forum topic | other blogs | 14707 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

XML or DOM as a host language

Here is my short story of DSL in Java.

Once I had a small (by a budget) project to automate a functional testing of some simple and generic java API to a data source with a very complicated data model behind (a kind of OODB stored several cross-mapped trees). The API was some stable, but the business logic (constraints and rules) of the data behind was changing even in minor releases. The goal of testing was to cover as much as possible of functionality, including all essential data combinations potentially activating as much as possible of triggers and procedures (hundreds) behind, which implementation was hidden, but the logic was documented in requirements (black-box testing).

I did not had much time to hard-code thousands (!) of test scripts. So, pretty soon I've ended up with a generic wrapper of the test results to DOM following by XSL for some data mining in test results. The test input came to that wrapper also in DOM. All test scripts where written in XML using XSL for automatic generation of them from more generic parameterized test scripts.

At that moment I've realized that the complexity of the data model was reflected in XSL - in test generators and in data miners. And I did not have time to create most of that XSL either. So, I've used RDF to describe the functionality of the business logic behind the target API being tested. Each RDF module responsible for one atomic piece of model was used to generate XSL generators, which were generating test input, and to generate XSL miners, which were parsing test output.

That RDF was a DSL to model a business logic. Several Java classes generating XSL from RDF were DSL programming such RDF-to-XSL generators. XSL for input generators were DSL for test scripting. XSL for output parsing was DSL for test reporting. The API wrapper classes was a DSL wrapping CORBA to/from DOM. I've almost forgot to mention one more DSL - exception-to-DOM wrapper classes were used to do own self-diagnostics of all my wrappers, transformers and parsers.

By axxackall at Sun, 2004-10-10 23:28 | login or register to post comments