Sessions at Jazoon 2010 on Thursday 3rd June

In many business applications, the calculation of certain key values varies from user to user, and over time. Examples of such values are: prices and shipping rates in order-entry applications, asset valuations in portfolio management solutions, or insurance premiums in sales force applications.

Business analysts, or the users themselves, know best how such key values are calculated and they know - and love - tools like Microsoft Excel or OpenOffice Calc. So let them use these familiar tools to define and update the calculations instead of adding endless and, for many users, incomprehensible configuration options to your code.

Then make your application compile these spreadsheets directly to parametrized, high-performance Java classes for use in your business logic. No more hand-coding of changing calculation models. And, since changes in spreadsheets can be incorporated at run-time, no more waiting for the next code release, either!

I will show this in action in the Abacus Financial Applications suite, which uses their GPL/commercial spreadsheet compiler http://formulacompiler.org/ (where I am project lead).

The model supplied by Java Web Frameworks is broken. As software engineers start to break away from the shackles of a Struts-type model, a new model based on object oriented programming and a clean separation of concerns has emerged with Apache Wicket. The framework has a simple component hierarchy allowing for reusability without pain. This session you will work with a real project built with Apache Wicket and we'll concentrate on components, forms, i18n, validation and AJAX support. We'll explore how to get started with Apache Wicket very quickly, and speak to how they differ with other popular Java frameworks. Attend and learn to enjoy web application development again, reduce complexity in your codebase and create more reusable and readable code.

Domain Specific Languages (DSLs) are becoming more and more popular, allowing developers to express their intent more precisely and with less syntactic noise. DSLs can be built on top of a host language (like Java or Ruby), which are referred to as "internal DSLs". External DSLs are far more flexible in terms of language design: you can define any desired grammar, you can define domain specific constraints and error messages, and you can process the DSL in a concise manner because it can either be interpreted or transformed into the code of any language by a generator.

Xtext, which is a part of the Eclipse Galileo release (and the upcoming Helios release), is a framework for developing textual domain-specific languages. Given an EBNF-style grammar, Xtext automatically generates an Ecore meta model and a rich-featured, fully configurable text-based DSL editor including features such as syntax highlighting, hyperlinked reference navigation, reference look-up, code completion, formatting, an outline and so on. The default implementation can easily be customized.

In this session, I will explain what DSLs are and why you should care about using them. After a short introduction, I will show how to develop DSLs with Xtext. You will learn how to define a grammar for a DSL and create a full-blown editor for this DSL, featuring code completion, syntax highlighting, hyperlinking, a semantic outline and more. I will also show how to write a code generator that allows you to transform your DSL scripts into running software.

Unit tests and mocks can only go so far to ensure the accuracy of your code. Eventually, you'll need to validate that your components behave in a real runtime environment, a style of testing referred to as integration testing. This talk showcases Arquillian, a new testing project developed at JBoss.org that empowers the developer to write integration tests for business objects that are executed inside an embedded or remote container--whether it be a servlet container, a Java EE application server or a local CDI environment (Weld SE).

Arquillian builds on familiar testing frameworks (JUnit and TestNG) and allows tests to be run with existing IDE, Ant and Maven test plugins, minimizing the burden on the developer to perform integration testing. And since the environment in which the tests are run is pluggable and easily swapped, the developer is not locked-in to a proprietary testing container.

This brief presentation will cover all the steps to get started with Arquillian, from project setup to your first green bar. Those steps involve:

• Setting up Arquillian in a Maven project
• Writing and running integration tests based on Arquillian
• Using ShrinkWrap to define your deployment
• Configuring a target server
• How test archives are individually deployed and executed
• The RPC (or local) communication that goes on between the test runner and server
• Inspecting the results of the test
• How to test EJB, MDB, CDI, Seam 3 and other EE related technologies

The talk wraps up by giving the audience insights into the future of Arquillian (as the core for Seam 3 Test and the JSR-299 TCK), planned container support and how Arquillian can be extended to suit unanticipated testing needs.

Writing a test for a business object that relies on enterprise services should not create pause. You should be able to write "integration" tests just like you would test a simple calculator class. Arquillian gives you that experience. Attend this talk to learn how to do real Java EE testing.