Jnario is a new test framework for Java focusing on the design and documentation aspects of testing. Jnario consists of two domain-specific languages, one for writing readable acceptance specifications, the other for succinct unit specifications. Together they are well suited for behavior driven development (BDD) of Java programs.
Building Domain-Specific Languages (DSLs) has been a great success in the software engineering community. Indeed, frameworks like EMF, Xtext, GMF, and Graphiti enable DSL developers to create or generate complex metamodels, complete language interpreters and full-blown editors (textual or graphical), sometimes with only a few clicks. However, in real-world systems development, applications need to be modeled through multiple orthogonal but interdependent views, each of which is focused on a specific aspect of the system.
An EMF model can be enriched with structural constraints and definitions of operations bodies and derived features. While these extensions can be implemented in plain Java, the lack of lambda expressions results in a code that is usually far from clean and concise with the expressed concern being lost among Java constructs. A common approach is to use OCL (Object Constraint Language) with the appealing short “to-the-point” expressions. Based on our experience, however, we found that using OCL in larger EMF models brings a number of shortcomings that eventually led us to look for alternatives. Some of the encountered problems are related to OCL itself and its tool support, but also to the way structural invariants are organized.
In this presentation we will show an alternative approach based on an internal DSL in Scala. By using this modern multi-paradigm programing language we can realize an internal DSL with similar features found in OCL while taking full advantage of the host language including state-of-the-art tool support.
This talk is about the feedback of a large french insurance company with 2.8 millions of insured members. They needed a tool to get a structured, centralized and unified vision of the P&C (property and casualty) products for Fire, accident and miscellaneous risks. The goal was to provide to insurance business experts a dictionary to specify their marketing offers and the characteristics of their products. The solution allows the users to directly configure the business part of the Information System (mainframe, intranet and new web apps).
“Groovy is an agile dynamic language for the Java Platform with many features that are inspired by languages like Python, Ruby and Smalltalk, making them available to Java developers using a Java-like syntax.” *
One of the big benefits of Groovy is how its dynamic features support the development of Domain-Specific Languages which we can run directly on the JVM alongside your existing Java code.
Xtext has spread at an amazing speed throughout the community and has revolutionized the work with DSLs and compilers for many of us. We use our own DSL SDK built upon Xtext to efficiently implement and automatically test large scale solutions comprising more than 50 DSLs used in 50'000 sources. We employ this framework in our Eclipse based IDE used in the development and customization of our banking system.
Java EE 6 has eliminated many of the drawbacks of previous Java Enterprise Editions, and is a strong choice regarding Standardization, Performance and Scalability. On the other hand, OSGi as emerging Enterprise standard provides modularization, service-orientation and flexible deployment. Both standards symbiotically complete each other. How could a possible marriage look between the two? And how can the marriage preparations be handled efficiently?
Eclipse Ecosystem provides several ways to implement your own Domain Specific Language (DSL), which could be a Textual DSL, a Graphic DSL or even a combination of these.
While attending various Eclipse events, I had the opportunity to watch several demos showing different kinds of DSL, based on Eclipse technologies.
The goal of this talk is to provide an overview of DSL definition possibilities @Eclipse, to enable you to choose which Eclipse technologies (or a combination of them), is most adapted to your specific use case.