sweet talk (part 2) tool support for sweet

Sweet Talk (part 2)Tool Support for Sweet

Phil Quitslund

Plan

1. Sweet Tooling issues

2. Introduction to Eclipse

3. Sweet Plugin at a glance

4. Implementation notes

5. Pitch and Caveats

6. Where next

Plan

1. Sweet Tooling issues

2. Introduction to Eclipse

3. Sweet Plugin at a glance

4. Implementation notes

5. Pitch and Caveats

6. Where next

Automating the BuildThe Problem: Manual builds considered painful

Automating the Build

• generative techniques require extra steps to stage builds

The Problem: Manual builds considered painful

Automating the Build

• generative techniques require extra steps to stage builds

The Problem: Manual builds considered painful

the rub: manual builds hurt and interrupt programmer flow

public abstract class List { public case Nil public case Cons(private int head, private List tail)}

public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }

Automating the Build

Automating the Build

public abstract class List { public case Nil public case Cons(private int head, private List tail)}

public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }

Automating the Build

3 “Introductions”

public abstract class List { public case Nil public case Cons(private int head, private List tail)}

public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }

Automating the Build

public abstract class List { public case Nil public case Cons(private int head, private List tail)}

public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }

Automating the Build

repositoryS

Automating the Build

repository

J

J

JS

Automating the Build

repository

J

J

JS

C

C

C

Managing DependenciesThe Problem: Crufty Orphans

Managing Dependencies

• generated files are "orphaned" when their introductions get removed.

The Problem: Crufty Orphans

Managing Dependencies

• generated files are "orphaned" when their introductions get removed.

The Problem: Crufty Orphans

the rub: manual maintenance is tedious and error prone

Managing Dependencies

repository

J

J

JS

C

C

C

Managing Dependencies

repository

J

J

JS

C

C

C

Managing Dependencies

repository

J

J

JS

C

C

C

Managing Dependencies

repository

J

J

JS

C

C

C

Managing Dependencies

repository

J

J

S

C

C

C

Managing Dependencies

repository

J

J

S

C

C

Managing Dependencies

repository

J

J

S

C

C

Done manually this is tedious and prone to error!

Error Handling

The Problem: Say What?

Error Handling

• Errors in generated files can be hard to trace back to their source

The Problem: Say What?

Error Handling

• Errors in generated files can be hard to trace back to their source

The Problem: Say What?

the rub: indirection decreases understandability

public abstract class List { public case Nil public case Cons(private int head, private List tail)}

public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }

Error Reporting

public abstract class List { public case Nil public case Cons(private int head, private List tail)}

public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }

Error Reporting

Legal Sweet

public abstract class List { public case Nil public case Cons(private int head, private List tail)}

public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); } case Nil { return 1; }

Error Reporting

Legal Sweet?

Error Reporting

public abstract class List { public case Nil public case Cons(private int head, private List tail)}

public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); } case Nil { return 1; }

Legal Sweet? Nope…

Error Reporting

Conflicting declarations

public abstract class List { public case Nil public case Cons(private int head, private List tail)}

public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); } case Nil { return 1; }

Error Reporting (from 10,000ft)

repository

S

S

S

Error Reporting (from 10,000ft)

repository

S

S

S

Error Reporting (from 10,000ft)

repository

S

S

S

Error Reporting (from 10,000ft)

repository

S

S

S

Error Reporting (from 10,000ft)

repository

S

S

S

Plan

1. Sweet Tooling issues

2. Introduction to Eclipse

3. Sweet Plugin at a glance

4. Implementation notes

5. Pitch and Caveats

6. Where next

What is Eclipse?

• A universal platform for integrating development tools– “An IDE for everything and nothing in

particular”

• An open, extensible architecture based on plug-ins

What is Eclipse? (a picture)

Platform Runtime

Workspace

Help

Team

Workbench

JFace

SWT

Eclipse Project

JavaDevelopment

Tools(JDT)

Stellation

SweetPlugin

AnotherTool

Plug-inDevelopmen

tEnvironment

(PDE)

Eclipse Platform

Debug

What is Eclipse?

• Lot’s for free (well almost)– Tight integration of common core tools

• CVS, Ant, JUnit, diff

– Extensible/open architecture

• Third-party plugins– ruby, c#, php, etc.– AOSD (aspectJ, hyperJ, FEAT, JQuery, etc)

Plan

1. Sweet Tooling issues

2. Introduction to Eclipse

3. Sweet Plugin at a glance

4. Implementation notes

5. Pitch and Caveats

6. Where next

Plugin Features

• Keyword awareness

• Integrated SweetBuilder

• Automated House-Cleaning

• Artifact Special Treatment

• Basic Error-Reporting

• Integrated Help

DEMO!!

Cross fingers please…

Plan

1. Sweet Tooling issues

2. Introduction to Eclipse

3. Sweet Plugin at a glance

4. Implementation notes

5. Pitch and Caveats

6. Where next

Automating the Build (Impl.)

- Eclipse leverages the Observer (Listener) Design Pattern

The idea is to register listeners to monitor for changes to resources that should trigger a build.

Automating the Build (Impl.)

• Our pipeline:

Automating the Build (Impl.)

• Ordered list of builders

• Insert SweetBuilder before JavaBuilder

• Our pipeline:

SB

JB

Managing Dependencies (Impl.)

/

pkgA pkgB pkgC

ouptut/

pkgA pkgB pkgC

Possible Approach: Parallel Worlds

Managing Dependencies (Impl.)

/

pkgA pkgB pkgC

ouptut/

pkgA pkgB pkgC

Possible Approach: Parallel Worlds

Possible Solution: “make clean”

Managing Dependencies (Impl.)

- Complete rebuild

- Worst case every Java file re-compiled

- File-based

- subtler: de-values artifacts• In a multi-view setting should be first-class!

Parallel Worlds Disadvantages

Managing Dependencies (Impl.)

- Use Sweet Parser to collect Introductions

- Store in Resource object metadata

Advantages:– Persistence for free– Limited introduction/deletion ripple

Better: Mapping

Error Reporting (Impl.)

- Should be integrated into environment- Shouldn’t re-route programmer flow- Minimize dissonance

Ideal: Handle Like Errors NOT Exceptions!

Error Reporting (Impl.)

- Extended Sweet Handler to collect Problem data

- Data marshalled into a Marker object

- Attached to Eclipse Resource

Result:

- visual (localized) cues, persistence, navigability

Eclipse Resource Marker Strategy

Plan

1. Sweet Tooling issues

2. Introduction to Eclipse

3. Sweet Plugin at a glance

4. Implementation notes

5. Pitch and Caveats

6. Where next

Pitch

• Nice vision– “user as programmer”

• Nice Execution– Mature tool for Java and Plugin Development

• Growing market share– Research and Industry

• Active Developer Community• In short: a viable tool to leverage now

– http://www.eclipse.org

Caveats

• Steep Initial Learning Curve

• Lagging Documentation– but “system is the curriculum…”

• Designer Bias– “strong world view”– pervasively file-oriented

Plan

1. Sweet Tooling issues

2. Introduction to Eclipse

3. Sweet Plugin at a glance

4. Implementation notes

5. Pitch and Caveats

6. Where next

Where next

• Short Term– Plugin improvements

• Export metadata (introductions) to Ant• More sophisticated Error Reporting• Context visualization

– Sweet Programming Guide

• Long Term– Multi-view support

Programming in the 21st century

• Emphasis on“ilities”– Reusability, evolvability, etc.– What about the “archies?” (hier/heter)

• The rub: current SOC technologies (HyperJ, AspectJ, etc) depose the dominant decomposition only to replace it with their own!

• It remains to be seen if their decomposition is any better!• Polyphonic Programming!

• The time for multi-view AOSD Tool-support is now!