ecoop08 22nd European Conference on Object-Oriented Programming
July 7th - 11th 2008, Paphos, Cyprus

 

ECOOP DEMO SESSION

ECOOP 2008 is offering a number of opportunities for demonstrations of research and production systems during the conference. ECOOP 2008 will host demonstrations of research prototypes, open source software products as well as commercial products, all aimed at academic or industrial audiences. Demonstrations will be selected on the basis of technical merit, novelty and relevance to the topics of the conference, and also feasibility of presentation.


Submission Guidelines

To submit a demonstration, please email a one page textual outline, or 1-2 page outline with figures, to the demonstrations chair: Anna Philippou

You must also indicate the type of demonstration: research prototype, open source software system, commercial product, other (please explain).

Accepted demonstrations will be required to provide a brief (200-400 word) textual description of the demo for the conference guide.

Important Dates

The initial deadline for demonstration proposals is June 6th. Requests received by that date will be responded to June 13th. Thereafter, submissions will still be accepted until such time as all slots are filled.

<-->

Demonstration and poster chair:

Anna Philippou, University of Cyprus

Demonstrations will be held in the Akamas C room of the conference site on Wednesday and Thursday.


D1 Wednesday July, 9th. 16:15 - 17:00, Thursday July, 10th. 10:45 - 11:30
The COSTA Cost and Termination Analyzer for Java Bytecode and its Web Interface

E. Albert, P. Arenas (Complutense University of Madrid, Spain)
S. Genaim, G. Puebla, D. Ramírez, and D. Zanardini (Technical University of Madrid, Spain)

COSTA is a research prototype which performs automatic program analysis and which is able to infer cost and termination information about Java bytecode programs. The system receives as input a bytecode program and a cost model chosen from a selection of resource descriptions, and tries to bound the resource consumption of the program with respect to the given cost model. COSTA provides several non-trivial notions of resource, such as the amount of memory allocated on the heap, the number of bytecode instructions executed, the number of billable events (such as sending a text message on a mobile phone) executed by the program. When performing cost analysis, COSTA produces a cost equation system, which is an extended form of recurrence relations. In order to obtain a closed (i.e., non-recursive) form for such recurrence relations which represents an upper bound, COSTA includes a dedicated solver. An interesting feature of COSTA is that it uses pretty much the same machinery for inferring upper bounds on cost as for proving termination (which also implies the boundedness of any resource consumption).

The COSTA web interface allows users to try out the system on a set of representative examples, and also to upload their own bytecode programs. As the behaviour of COSTA can be customized using a relatively large set of options, the web interface offers two different alternatives for choosing the values for such options. The first alternative, which we call automatic, allows the user to choose from a range of possibilities which differ in the analysis accuracy and overhead. All this, without requiring the user to understand the different options implemented in the system and their implications in analysis accuracy and overhead. The second alternative is called manual and it is meant for the expert user. There, the user has access to all of the analysis options available, allowing a fine-grained control over the behaviour of the analyzer. Some of these options include whether to analyze the Java standard libraries, to take exceptions into account, to perform a number of pre-analyses, to write/read analysis results to file in order to reuse them in later analyses, etc. In the demo, we will show analyses using different cost models and also analyze applications for both Standard Edition Java and Micro Edition Java (in particular, for the MIDP profile for mobile phones).

D2 Thursday July, 10th. 12:00 - 12:45
Building and using pluggable type systems with the Checker Framework

Michael D. Ernst, Massachusetts Institute of Technology

A static type system helps programmers to detect and prevent errors. However, a language's built-in type system does not help to detect and prevent enough errors, because it cannot express certain important invariants. A user-defined, or pluggable, type system enriches a language's built-in type system via type qualifiers. Pluggable types permit more expressive compile-time checking, and they can guarantee the absence of additional errors. Example type qualifiers include nonnull, readonly, interned, and tainted.

Despite considerable interest in user-defined type qualifiers, previous frameworks have been too inexpressive, unscalable, or incompatible with existing languages or tools. This has hindered the evaluation, understanding, and uptake of pluggable types.

The Checker Framework supports adding pluggable type systems to the Java language in a backward-compatible way. The Checker Framework is useful to two constituencies. A type system designer can create a type-checker for a custom type system. A programmer can use the type-checker to detect errors or verify their absence.

The Checker Framework is expressive and flexible. It builds in many features needed by type system designers and programmers, including:

  • backward-compatible Java and classfile syntax for type qualifiers
  • integration with javac and Eclipse
  • three type inference tools to ease programmer annotation burden
  • declarative and procedural syntax for writing type-checking rules
  • flow-sensitive type qualifier inference
  • polymorphism over types (Java generics)
  • polymorphism over type qualifiers
  • implicit and default qualifiers

Experience indicates that the Checker Framework is useful to programmers and type system designers. For programmers, type-checkers built using the Checker Framework have processed over 600K lines of code, finding real errors in every program. For type system designers, the checkers are concise, even for robust implementations of sophisticated type systems, and the simplest type systems require writing no code at all. The Checker Framework is being used by researchers around the world to perform realistic evaluation of type systems. It has yielded new insight into existing type systems and has enabled the creation and evaluation of new ones.

This demonstration will illustrate the power of the Checker Framework, both for programmers and for type system designers, and will prepare you to begin using it yourself.

The Checker Framework is freely available at http://groups.csail.mit.edu/pag/jsr308/. The distribution includes source code, binaries, extensive documentation, and example type-checkers.

D3 Wednesday July, 9th. 15:30 - 16:15, Thursday July, 10th. 16:15 - 17:00
The Maxine Virtual Machine

B. Mathiske, L. Daynes, D. Simon, B. Titzer, M. Van De Vanter (Sun Microsystems Laboratories)

Sun Microsystems Laboratories has just released under GPL v2.0 a preview version of the Maxine VM, a new research virtual machine written in the Java programming language that emphasizes ease of development, portability, maintainability, and configurability. Maxine seeks to make VM development substantially more agile than has been possible in the past. It is also the first metacircular VM implementation integrated with the latest JDK software from Sun.

VM developers can work with the Maxine code base in their choice of NetBeans software, Eclipse, or IntelliJ, and need not be concerned with complications such as makefiles, Ant files, or preprocessors. Maxine's source code leverages all the newest language features, including generics, annotations, return type overloading, enums, etc., and exemplifies system programming in the Java programming language.

The design of Maxine is modular and enables the construction of different VMs based on different choices for configurable features, including dynamic compilers for Just-in-Time compilations and/or VM image generation, dynamic recompilation strategies, garbage collectors, read and write barriers, object reference representations, object layouts, thread synchronization, and VM machine startup sequence.

All internal data structures of the VM (e.g., runtime representation of classes, bytecode and native representation of methods, etc...) are first-class Java objects. This enables their reification by serviceability tools inspecting a remote running Maxine VM. This ability has eased considerably the construction of the Maxine Inspector: a visual debugging tool that seamlessly integrates object browsing with both source-level and low-level (i.e., native machine instructions) debugging.

The demonstration will begin with a tour of the Maxine VM from a developer's perspective, illustrating the various steps a Maxine VM developer go through: installing sources, editing code, configuring and building a VM image, unit testing, running the VM with Sun JDK 1.6, and debugging using the Maxine Inspector.

The demonstration then focuses on the Maxine Inspector. The inspector will be first used to show on a live Maxine VM prominent internal mechanisms of the VM, such as bootstrapping, dynamic link resolution and class loading, runtime compilation, signal usage, exception handling, etc. Then, we will illustrate how the Inspector ease the identification of bugs in the Maxine VM, and help improving the productivity of VM developers.

The Maxine Virtual Machine and Inspector are both available at https://maxine.dev.java.net.

D4 Wednesday July, 9th. 12:45 - 13:30, Thursday July, 10th. 15:30 - 16:15
The g-Eclipse Project

Harald Gjermundrød and Marios D. Dikaiakos on behalf of the g-Eclipse consortium

Overview:

The g-Eclipse project - both a European funded research project and an Eclipse technology project - is building an integrated workbench framework to access the power of existing Grid infrastructures on top of the reliable ecosystem of the Eclipse community to enable a sustainable development. The g-Eclipse team develops a middleware-independent platform by providing extension points to connect to different Grid infrastructures. The framework itself comes with exemplary gLite support and support for the GRIA middleware. The implementation of support for Amazon Web Service (AWS) is currently underway. With the help of g-Eclipse, Grid users can easily access their personalized Grid resources. Furthermore, Grid resource providers profit from a shortening of the service-to-market time and Grid application developers benefit from the seamless integration of the remote development process into the existing Eclipse development environments using g-Eclipse

Current Stage of the Project:

The g-Eclipse project started in July 2006 and the EU-funded part will end in December 2008. As the project is also an official Eclipse project its sustainability will continue as an open source Eclipse project with other national and EU-funded projects extending/using the framework. Monthly milestone releases are created and made freely available for download from the www.eclipse.org/geclipse or www.geclipse.eu websites. The latest stable release is version 0.5 (released September 2007) and the current milestone release is 1.0 milestone 6

Features Highlights

The framework comes with three pre-defined perspectives, namely user, operator, and developer. Each of these perspective contains a set of features including the ones below:

User Perspective:
  1. Create a Grid project
  2. Create a job description following the JSDL standard
  3. Submit a job to the Grid and retrieve its output
  4. Mount Grid Storage Elements and browse, drag and drop, open files on the Grid
Operator Perspective:
  1. Manage a local Grid site
  2. Specify and submit service jobs to the Grid
  3. Browse available Grid resources and their properties
Developer Perspective:
  1. Remote debugging of Grid jobs
  2. Scientific visualization

D5 Wednesday July, 9th. 12:00 - 12:45, Thursday July, 10th. 12:45 - 13:30
SwingBean: Graphical Components Based on Class Metadata

Eduardo Martins Guerra, Aeronautical Institute of Technology, São José dos Campos, Brazil

In the MVC model, the view layer is the hardest to have its classes reused, because the graphical-interface components that compound a screen depend of the domain entities. For example, a form or a table usually contains elements that can be mapped to some class property. Using class metadata to create graphical components, the domain specific portion of a screen can be abstracted and it will enable the reuse in the view layer.

SwingBean is an open-source framework that provides metadata based graphical components to be used in Java with the Swing API. It has more than 2500 downloads and was already used successfully in large scale applications in the production phase and for teaching how to create graphical interfaces in Java. With SwingBean it is very easy to create templates that can be used directly to create more than one screen just configuring properties. SwingBean also has functionalities to: validate information based on metadata; create binding between domain objects and graphical components and set and retrieve information in the components.

The demonstration will present the SwingBean framework and how it can use the class structure and some additional metadata configured in an XML document to create complex forms and tables. The creation of simple templates will also be demonstrated to show how the reuse in the view layer could be archived using this kind of approach. The demonstration will be made interactively with a "live implementation" of screens.