JSDT/Design

• Overview
• Quick Start
• How to Contribute
• Architecture
• Design

As of WTP 3.0, JSDT is part of the Web Tools Platform.

Design

The JavaScript Development Tools design would use the JDT design with the necessary adjustments made for JavaScript.

As far as the JavaScript Development Tools design is concerned, the major differences between Java and JavaScript are:

• Javascript has no explicit typing support, whereas in Java everything is typed, and incorporates argument types in function signatures.
• At the top level, a JavaScript file can contain any program statement, whereas a Java file only contains a Class.
• JavaScript has no classpath/jar file concept

Other areas where the java/JavaScript differences will necessitate changes:

• syntax differences - parse definitions
• additional program elements with no correspondence in Java
  • object literals
  • for (var in collection)

Inferred Types

In order for some JDT-based functionality (such as code completion) to work correctly, class type information needs to be available. This information is not available in JavaScript, but it can be inferred in many cases. A type inferring framework has been put in place to support this functionality, examining the JavaScript Abstract Syntax Tree (AST) and generating "virtual" class information. Type inferring is extensible, so the unique conventions among various JavaScript Toolkits (e.g. Dojo, jQuery, Prototype, etc.) can be handled, although through WTP 3.1 it has remained provisional. Inferred types may participate in refactoring, but their visibility within the UI is still being discussed.

JavaScript file handling

Java files have a very top down structure, where files only contain classes, which only contain fields, methods, and inner classes, and program statements only contained within methods. Because of this, some JDT functionality will not work for JavaScript, because a program statement can be directly at the top of a JavaScript file. The relevant JDT code is still undergoing refactorings to support these scenarios.

Variable/function resolution

In Java, everything is resolvable because of the classpath, package structure, and import statements. This has no correspondence in JavaScript, where functions themselves may also be resolvable as types.

Libraries

The JSDT mimics the JDT Java Build Path and classpath container mechanisms to offer JavaScript library support. JSDT libraries are collections of JavaScript source files that have prototyped object/class definitions and JSDoc. The inference engine then models these libraries and places each object/field/function in the projects Global Scope, making them available to every JavaScript file in the project. Because the library contents are not directly executed by JSDT, it isn't necessary for them to contain the complete implementation of those objects. In fact, the standard JavaScript runtime is itself presented as a source file containing stubs for the specification's contents. Bindings for nonstandard and future runtimes are similarly easy to create and use.

To illustrate-- the JSDT contains a FireFox library plugin with about 150k of JavaScript and JsDoc. This library represents the class structure within the FireFox browser that is accessible to a web page's JavaScript, but does not contain any implementation to the functions it declares. If a user wishes to target their JavaScript source to FireFox specifically, they would add the FireFox library to their project and gain content completion and hover help for the FireFox objects. Users may also limit the objects/functions/fields visible in the project by adding or removing libraries.

Libraries aren't limited to browser objects. AJAX runtimes can fit nicely into libraries, as would a website's standard set of utility functions. Really the possibilities are limitless. And the library mechanism is extremely easy to expand both by the end-user or through extension points.

Functionality mapping

This table shows how the JDT functionality corresponds to the JavaScript functionality. It does not include anything where there is a direct one to one correspondence.

JDT function	JSDT function
Build path	Libraries + Global Scope (frequently referred to as an "Include Path")
JDK level (1.4 vs 1.5)	ECMAscript level 3 vs 4 (v.3 supported now, v.4 will not be implemented as the specification was abandoned)
Compile	Validation & flow analysis

Extension Points

The JSDT functionality is embeddable. This means, for instance, that the JavaScript editing capabilities is embeddable within HTML and JSP Editors, both within script tags, and script attribute values. The JSDT is flexible so script support in other languages is possible using translator interfaces being planned for WTP 3.1.

The following JSDT extension points are supported :

• Global Scope variable initializer
• Global Scope container initializer core
• Code formatter
• Validation participant

 Currently the JSDT is represented in an AST.

The following jsdt.ui extension points will be supported :

• Global Scope container initializer ui (Wizzard, content assist images and type/text naming)
• javascript element filter
• javaScriptEditorTextHovers
• jsdocCompletionProcessor
• quickFixProcessors
• quickAssistProcessors
• foldingStructureProviders
• queryParticipants
• javaScriptCompletionProposalComputer
• javaScriptCompletionProposalSorters