10 likes | 119 Views
edu.yorku.jscoop JSCOOPProjectNature. edu.yorku.jscoop.translator TranslateAction JSCOOP_InitiralTranslationVisitor JSCOOP_MainClassTranslationVisitor JSCOOP_TranslatorVisitor. JSCOOP Project File. Await Processing: Copy of File is a hidden file, which is processed
E N D
edu.yorku.jscoop JSCOOPProjectNature edu.yorku.jscoop.translator TranslateAction JSCOOP_InitiralTranslationVisitor JSCOOP_MainClassTranslationVisitor JSCOOP_TranslatorVisitor JSCOOP Project File Await Processing:Copy of File is a hidden file, which is processed for errors and reported back to the original JSCOOP project file, then deleted. edu.yorku.jscoop JSCOOPProjectWizard Translation File Creation: Copy of File is a new file the translation creates from processing the current JSCOOP project file. Eclipse New Wizards Resource Natures Pop Up Menus Help Table of Contents JDT Compilation Participant Resource Markers edu.yorku.jscoop JSCOOPProjectNature toc.xml topics_GettignStarted.xml topics_JSCOOPDevelopersGuide.xml topics_JSCOOPToolingDevelopersGuide.xmltopics_UsersGuide.xml html/* Copy of File edu.yorku.jscoopJSCOOP_CompilationParticipantJSCOOP_ToolingVisitorJSCOOP_Problem Rewritten AST Original AST JSCOOP: SCOOP For Java Eclipse Tooling Support  Kevin Doyle With Jenna Lau, Jonathan Ostroff and Faraz Ahmadi Torshizi.Department of Computer Science and Engineering, York University, 4700 Keele Street, Toronto, Canada M3J 1P3 • CREATING A JSCOOP PROJECT • JSCOOP Projects are Java Projects with an additional JSCOOP Project Nature • JSCOOP Projects can be created in Eclipse using the New Project Wizard to select the JSCOOP Project Wizard USING THE @SEPARATE ANNOTATION • The @separate annotation can be used to decorate fields, local variables and method parameters • Objects decorated by the @separate annotation are considered separate with respect to the current object • The @separate annotation takes in an argument dir to provide support for arrays used in the separate context • USING THE @AWAIT ANNOTATION • The @await annotation can be used to decorate method declarations and takes in an argument pre to specify boolean conditions • Preconditions specified in @await declarations will be treated as wait conditions • HOW TO MANIPULATE THE ECLIPSE AST • In order to take advantage of existing Eclipse tools for Java, annotations were chosen over keywords for JSCOOP • A JSCOOP_CompilationParticipant was created to act on compilation events (specifically save reconciles) • To parse the Eclipse AST, a class extending ASTVisitor is required. The ASTVisitor provides capability for visiting all nodes of the DOM created from a parsed Java document, including: • Variable Declarations • Assignment Statements • Method Declarations • Method Invocations • The Eclipse AST can be altered for the purpose of correctness checking of @await statements and automated translation of JSCOOP Projects to Java code JSCOOP PLUG-IN • The tooling is broken down into two packages within this plug-in: • edu.yorku.jscoop • This package is responsible for correctness checking and GUI support for JSCOOP Project creation. A single visitor class is used to parse JSCOOP files for problem determination • edu.yorku.jscoop.translator • This package is responsible for the automated translation of JSCOOP code to Java code. • Basic framework for automated translation has been designed with the anticipation of future development to fully implement this feature • CORRECTNESS CHECKING FOR @SEPARATE • JSCOOP Eclipse tooling provides correctness checking for the following cases: • Incorrect placement of annotation • Incorrect use of directive (dir) • Introduction of traitors on: • Variable declarations • Assignments • Method calls • Note: The concept of a “traitor” is taken from the SCOOP model. Traitors are introduced when separate objects are used where a non-separate object is expected • Errors are highlighted in the Eclipse development environment as follows: CORRECTNESS CHECKING FOR @AWAIT • Valid precondition strings specified in the @await annotation correspond to valid boolean expressions for Java assert statements ABSTRACT The real world is concurrent. Several things may happen at the same time. Computer systems must increasingly contend with concurrent applications. SCOOP is a concurrent programming language with a new semantics for contracts that applies equally well in concurrent and sequential contexts. SCOOP eliminates race conditions and atomicity violations by construction. In this work we describe JSCOOP – an equivalent solution in Java. This solution introduces new annotations modeled after SCOOP keywords as well as several core library classes which provide the backend support necessary to mirror SCOOP semantics. JAC (Java with Annotated Concurrency via JML) is a prior attempt to port SCOOP notions to Java. OBJECTIVE JSCOOP extends Java’s concurrent behaviour by hiding the notion of threads, semaphores and synchronization. This is achieved by adding two annotated keywords (@separate and @await). These keywords have the same meaning as separate and require in SCOOP. The goal in creating the JSCOOP library was to provide a base set of classes similar to SCOOPLI for SCOOP. These classes are intended to provide support for major SCOOP concepts, including a fair scheduling algorithm that eliminates race conditions, separate processor functionality, and mechanisms to mirror Eiffel’s agents for wrapping calls. Consider an excerpt of JSCOOP code using the new keywords for the classic Dining Philosophers example: Advantages • No explicit thread declarations • No synchronized blocks • No semaphores or explicit waits Support developed for JSCOOP includes: (a) An Eclipse JSCOOP plug-in that supports the two new keywords as annotations and does automated syntax type checking for “traitors” (that prevent atomicity or race violations). This is described in this poster. (b) Prototype runtime translation to translate JSCOOP to multithreaded Java. A core library for the translation has been developed that provides support for the translation, with proof of concept on some examples. See sister poster. • 1) private @separate JObject o; • 2) @separate JObject o = new JObject(); • 3) public void aMethod(@separate JObject arg) {} • Non-separate array, Non-separate elements • JObject[] o = new JObject[#](); • 2)Separate array, Non-separate elements • @separate(dir=“@separate JObject[] o”) • JObject[] o = new JObject[#](); • 3) Non-separate array, Separate elements • @separate(dir=“JObject[@separate] o”) • JObject[] o = newJObject[#](); • 4) Separate array, Separate elements • @separate(dir=“@separate JObject[@separate] o”) • JObject[] o = new JObject[#](); public class Philosopher { private @separate Fork left, right; @await(pre="!l.isInUse() && !r.isInUse()") publicvoid eat(@separate Fork l, @separate Fork r) { l.pickUp(); r.pickUp(); if(l.isInUse() && r.isInUse()) status = EATING; l.putDown(); r.putDown(); if(!l.isInUse() && !r.isInUse()) status = IDLE; } … } @await(pre=“list.isEmpty() && arg1 != null) public void aMethod(@separate Jlist list, @separate JObject arg1) { … }