FOSSLC is a non-profit organization that specializes in technology and know-how to record conferences with excellent quality. Click on the icons below to view great videos from communities we are actively involved with:

Despite all advances in the software field, the most common bug is still the most embarrassing bug that OOP has to offer: NullPointerException.

The main weapon in fighting NPEs is known for quite some time: annotating your types with either @Nullable or @NonNull. It has also been shown how appropriate defaults enable you to omit more than 2/3 of all required annotations without loss of precision. Still, null annotations haven't yet made their way into mainstream development with Java, and so we keep developing new NPEs every day.

This talk will present an initiative to enhance the Eclipse Java Compiler with the capability to perform comprehensive analysis of null problems in your code using null annotations. Current plans state that this support shall be released as part of Juno. The new analysis together with the corresponding new quick assists will allow you to adopt null annotations at any level and gradient: from making a few API contracts explicit and checkable up-to eventually providing guarantees that a fully annotated program will never throw NPE.

Until the Juno release the new functionality is made available as a separate download that has been developed using OT/J as the implementation language. A look behind the scenes will reveal how Object Teams has once again kept the promise of extreme modularity: We need tight integration for extending a complex application (the Eclipse Java Compiler) with a complex new feature (annotation based null analysis). OT/J is a champ for integration. We didn't want to compromise the separation of concerns and again OT/J is our friend: the new feature is a cleanly separated and concise module with all the benefits for development, building and deployment.

During the last couple of months our team had to build quite a large piece of software which is intended to support in-house staff in managing financial data of companies. Our task was to replace a legacy AS/400 system.

With the experiences of the legacy system in mind, we were looking for a technology platform that:
- is future safe
- allows quick addition of new functional parts
- offers powerful UI capabilities in look and function

Eventually Eclipse RCP became the client-side part of our technology stack. The client stores and retrieves its data using a JEE back-end system and a separate proprietary document management system.

All business logic is implemented in our back-end system, with only a subset of validation rules executed on the client-side.

In this talk, I will take the opportunity to speak about using Eclipse RCP as an application platform for business software.

To start, I would like to outline our overall architecture and demonstrate some components of the application.

I will then talk about some of our experiences (the good and the bad) that we gathered along the way, while "standing on the shoulders of giants".

I would especially like to discuss:
- Implementing MVC/MVP architecture for forms and dialogues
- JFace Databinding
- (Headless)UI-Tests and build

Creating an Eclipse Plugin help can be a tedious task. Often Mylyn Wikitext is used but unfortunately, it is not well suited for code centric documentation. That is where Xdoc comes in. Xdoc is a markup language especially designed for Eclipse Plugin documentation. The tooling that comes with Xdoc features generators for Eclipse Help plugins, Eclipse Phoenix framework based websites and printable PDF documents.

The Xdoc language was designed having several goals in mind:

1. Simplicity. Flexibility in languages like Wikitext can be great, but in most cases it is not needed. It can even confuse the writers ("Do I have to use italic or bold font here?")
2. Full separation of the document's layout from its structure. Layout is always a global issue, especially when using corporate designs like the Eclipse Nova theme, for instance.
3. Validation for referenced class files. If class and/or package names change due to refactorings, the documentation has to reflect that change.
4. Support for syntax highlighting of arbitrary code chunks. When documenting DSL projects, the syntax highlighting of documented code chunks has to be definable, so it can be highlighted. Highlighting is done both, in the output files and in the Xdoc editor, so you will always get a feeling how the result will look like.
5. Intuitive language design. Writing documentation is not what software developers do for fun, or do you? So the language and the tooling itself should support the developers by all means.

In this talk the Xdoc language and tooling will be demonstrated, focusing on useful features for code centric documentation. The Xdoc language itself will be shown as well as the generated Eclipse help plugin, the generated website, and the PDF document. This way attendees will get an impression how to use Xdoc for the documentation of their Plugin Projects and how to benefit by using Xdoc.