A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document of the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present invention relates to the editing of software and software components.
Modern “smart” source code editors provide a wide range of features to the software developer based on increased understanding of the underlying programming language. For example, these editors may provide syntax coloring to highlight various components of the language grammar (class definitions, fields, methods, comments, etc.) The editors may also highlight known errors in the code. In general, this increased understanding of the underlying programming language is achieved by adding a language specific lexical analyzer and/or parser to the editor.
Unfortunately, most large-scale development projects include several programming languages targeted at different domains and different classes of developers. For example, it is not uncommon for a modern web application to include Java, Java Server Pages (JSP), JavaScript, the Hypertext Markup Language (HTML) and the eXtensible Markup Language (XML). Therefore, a typical development environment may effectively include several “smart” source code editors, each with an embedded lexical analyzer and/or parser specific to a given language.
Developing and maintaining a separate editor for each language in the development environment is costly and time consuming. Each time a new language is needed, a new editor must be constructed. Each time a new editing feature is added, it must be added to each language module. In addition, keeping the features of the language editors in sync can be a challenge. Minor differences between the editors in a given development environment can result in an inconsistent and confusing experience for the developer.
In addition, it is becoming increasingly useful to embed one language inside another within a single source file. For example, JSP pages include Java and JSP tags embedded within HTML. Emerging languages, such as ECMAScript for XML(E4X) embed XML within JavaScript. Other emerging technologies, such as Java for Web Service (JWS) embed a small annotation language inside Java comments to succinctly describe how that Java class should be exposed as a web service. In some cases, several languages can be nested several layers deep in a single source file.
The simple lexical analyzers and parsers embedded in common source editors are usually not sophisticated enough to recognize and process nested languages. Therefore, in some environments advanced source code editing features are simply not available for nested languages.
In other environments, a new editor might be constructed specially tailored to handle each new language combination even if separate editors already exist for each of the nested languages. For example, a JSP editor might be constructed to handle the combination of HTML, JSP tags and Java, even though separate HTML and Java editors already exist in the development environment. A new E4X editor may be constructed even though separate ECMAScript and XML editors already exist. This may result in duplication of code and will likely result in inconsistent behaviors as the different language editors evolve.
As language nesting becomes more popular, the increase in cost and time required to develop and maintain a comprehensive suite of smart editors using traditional methods becomes combinatorial.
To make matters worse, some nested languages appear in several contexts. For example, XML may be embedded in ECMAScript, Java and JWS annotations. In addition, small expression languages such as those required to understand date and time formats (e.g., YYYY-MM-DDThh:mm:ssTZD from ISO 8601) or time durations (e.g., 15 h 4 m30 s) may be embedded in several different languages. Adding these common sub-languages separately to each editor's lexical analyzer and/or parser again results in increased development and maintenance costs and potentially inconsistent behaviors. Any changes to the way these common sub-expressions are handled should be applied uniformly across all applicable host languages.
In a typical Integrated Development Environment (IDE), there are often two compilers. The first compiler is run from the command line, displaying a list of errors or emitting runable code. The second compiler exists as part of the IDE. Initially, this compiler may only implement lexical analysis of source code in order to support syntax coloring. Then it may implement syntactic analysis in order to support the structure pane and class browser. Eventually, this compiler will contain a nearly complete front-end in order to support code completion.
The trend of moving more and more of the compiler into the IDE is understandable: advanced IDE features are often based on advanced understanding of the language being edited. Unfortunately, it is not normally possible to use the command-line compiler inside the IDE. First, it is normally not componentized in such a way that the information needed by the IDE is easily accessible. Second, it is usually far too slow for interactive use as changes are made, especially if it takes multiple passes over the files. Third, it almost always recovers poorly from errors, which amongst other problems, makes code completion impossible.
These issues force the IDE to create its own compiler. However, supporting two compilers has many disadvantages. First, it is nearly twice the work of implementing a single compiler, particularly where the back-end is a fairly high-level language (i.e. Java bytecodes) and no optimization is performed. Second, the IDE's compiler is typically the second class citizen, and as a result, it is usually of lesser quality. Few IDE's actually implement 100% of the analysis in the command line compiler. Furthermore, the IDE's compiler is often designed in an evolutionary manner as new features are needed, resulting in a poorly organized compiler. Third, two different code bases need to be updated in order to make changes to the language. This makes creating a new language a slow and painful process. These problems get worse as the platform is scaled in the number of languages it supports and in the number and sophistication of IDE features.
In one embodiment, a source editor capable of editing multiple languages and a compiler framework are configured to communicate with language independent data. In one embodiment, the editor works using compiler meta data that is language independent. Thus, when a new language is introduced into the environment for editing and/or compiling, separate instructions regarding how to integrate the language for compiling or editing are not required. For these and other reasons, the editor provides an edit rich experience without using language specific knowledge.
In one embodiment, a source editor capable of editing multiple languages and a compiler framework are configured to communicate with language independent data. In one embodiment, the editor works using compiler meta data that is language independent. Thus, when a new language is introduced into the environment for editing and/or compiling, separate instructions regarding how to integrate the language for compiling or editing are not required. For these and other reasons, the editor provides an edit rich experience without using language specific knowledge.
To be competitive, a modern IDE should support multiple languages and many sophisticated IDE features. In addition, it is also useful for a compiler to support mixing and nesting languages within the same source file. For example, in emerging language such as E4X, the IDE should display errors for mismatched start and end tags in embedded XML and it should perform auto-completion of XML tags embedded in the source code. These features should be available independent of the host language embedding XML. As another example, JWS annotations should be treated as a nested language and the IDE should support features such as syntax coloring and code completion when editing the annotations.
Systems and methods in accordance with embodiments of the present invention overcomes problems in existing editing systems by providing and/or utilizing an extensible, data-driven, language independent source code editor with an embedded, extensible multi-language compiler framework. This editor may not include a language specific lexical analyzer or parser. Instead, the editor can be tightly integrated with a compiler framework that provides detailed information about the language currently being edited by the user. This information can be provided in a language-neutral way effectively decoupling the editor from the underlying set of languages being edited.
In addition, a language-independent editor can expose a set of APIs that makes it easy to customize behavior for specific languages that have characteristics not shared by most languages. This set of APIs can also enable the development of customized views, such as for developing visual editors that represent and allow the user to manipulate aspects of the source code pictorially.
Multi-Language, Compiler Framework
A multi-language compiler framework can be used inside the language independent editor. The compiler framework can be used to perform the task of a normal command-line compiler, and can also provide the language information necessary for implementing editor features. Having a single compiler can reduce the amount of work needed to add a new language and to modify and extend that language. It can also ensure that the editor's compiler is of the highest quality.
In addition, the compiler framework can make it easy to turn language information into editor features. This can allow language designers to focus on their language and not have to worry about implementing the editor-side as well.
The tight integration of the compiler into the editor, along with the extra time made available by not having to implement a separate compiler for the editor, significantly improves the language-based features of an editor. Here are some examples of the improvements that a compiler framework can make possible:
Performance
Error Display
Error Correction
Auto Correction
These are only a few examples of the kinds of features a compiler framework can provide by tightly integrating into the editor. The compiler framework can make all of the information produced by the compiler available in real-time for the editor to use, making possible almost any conceivable editor feature.
Compiler Framework Services
The sections below describe what a compiler framework can do for various consumers of the compiler framework functionality, such as runtime, editor, or language designer consumers. Also included is an exemplary list of languages that can be supported.
Runtime
Produce Annotated .Class Files
Provide Compiler Tools
Robust to Errors
Support Language Nesting
Expose Language Information
Easy
Encapsulates Syntax Details
Provide Project Information
Up-To-Date
Provide File Information
Up-To-Date
Provide File Information Changes
With the rich set of information provided by the compiler framework, it is possible to create a large set of useful source editor features that make it a more powerful tool. Below are some examples.
Editing Features
The editor for an IDE should know something about the languages it can edit and as a result it can provide a number of useful features which make it easier to edit source files in that language.
Token Coloring
Comment Editing Help
Auto-indenting
Matching Tokens
Edit by Token
There are many cases where type information can be used to provide the user with help understanding the meaning of identifiers or to help them understand what function calls and variable references are legal in a certain context.
Completion List
Parameter Information
Identifier Information
Class Browser
Navigation Bar
Squiggly Underlines
Error Auto-Correct
The benefits of the language independent editor are numerous. This section lists several examples of benefits that can be obtained using embodiments of the present invention.
Rapid New Language Support
Adding new languages to a development environment no longer requires the development of a new smart editor. Because the communication between the compiler framework and the source editor is language independent, new languages can be added without a single change to the editor. The compiler framework will provide a rich set of information about the syntax and semantics of each newly added language, immediately enabling a rich set of smart editor features. This drastically reduces the time and effort required to add a new language to a development environment.
Rapid New Editor Features
Similarly, decoupling the editor from the specific set of compilers means new editor features can be developed once, but will benefit all programming languages plugged into the compiler framework. It is not necessary to add the new feature to a separate editor for each language.
Consistent Editing Experience
Because there can be a single implementation for all editor features applied to all languages in the compiler framework, the editor can perform uniformly and consistently no matter what language is being edited. Consequently, users who have become accustomed to certain features in one language can use them in another language. The keystrokes and other gestures required to activate and use those features will be the same. The behavior of the editor will be familiar and unsurprising even if the developer is editing a new an unfamiliar language.
Language Nesting
Because an editor can be language neutral, it can support arbitrarily nested languages. An underlying compiler framework can consult different language modules for each nested portion of the source code and provides information about the syntax and semantics in a language neutral form. The compiler framework can also inform the editor where each language begins and ends within a source file so the editor can apply different user preferences for each language (e.g., the user might like different syntax coloring schemes for different languages).
One of the benefits of such architecture is that a new language compiler and a new language editor do not have to be developed for each new combination of nested languages. For example, if the compiler framework already has an XML language module and an ECMAScript language module, nesting XML within ECMAScript requires relatively minor modifications to the ECMAScript language module. It is not necessary to create a new language module to enable this functionality and no modifications to the editor are required.
Common Sub-Languages
The language independent editor can reduce the time and cost of embedding common sub-languages within several host languages. The sub-language can be developed once as an independent language module and nested inside as many other languages as needed. Detailed information about the syntax and semantics of the sub-language need not be added separately to each host language.
In addition, an editor may not need to know the information provided by the compiler framework about the sub-language is derived from a different language module. Therefore, the sub-language can be added to an arbitrary number of host languages without requiring any modifications to the Editor.
Changes to the sub-language can be made in place and will be reflected in all host languages. The user experience working with these sub-languages will be consistent regardless of the host language in which they are embedded. All editor features, including syntax coloring, error reporting and statement completion will be uniform and familiar.
Customized Language Features
APIs exposed by a language independent editor can allow custom language features to be developed easily and quickly. An API can provide default implementations for all the built-in editor features, and can allow extensions to modify or replace existing features or add completely new features. This extensibility can be very useful when the editor does not provide all the desired features or for unusual languages where the existing features need to be customized.
Customized Views
A language independent editor can also expose APIs that allow third parties to add custom, language editing views to the editor. For example, a workflow programming language might provide a graphical editor for business processes that allows users to create and modify the business processes by dragging and dropping icons on the display. The underlying source code would be modified simultaneously and source code changes could be viewed in a second window while they occur. Alternately, a web service editor might provide a view for graphically understanding and manipulating how the web service interacts with clients and external entities (e.g., other web services). Error! Reference source not found.
Data Driven Editor
As discussed earlier, the features of the language independent editor can be driven by language independent data provided by the compiler framework. This section describes examples of some of the key pieces of information provided by the compiler framework. A complete description of the API that governs the interaction between the compiler and editor is described elsewhere herein.
One of the important pieces of information that can be provided by a compiler framework is a stream of token nodes. Each token node can identify the start, end and type of a particular token identified by the compiler. The editor can use this information to provide features such as syntax coloring. For example, Error! Reference source not found.
Another important piece of information that can be provided by the compiler framework is a tree of language nodes representing the nested languages in the file. The compiler framework can determine the first language used in a source file by its file extension (e.g., .java, .jws, .jsp, etc.). The host language, based on its syntax, can identify subsequent languages. For example, the JSP language uses the delimiters <% and %> to identify nested sections of Java code. Each language node identifies where the nested language section starts and ends. In addition, it can identify the name of the language (e.g., via com.bea.compiler.ILanguage) and any additional nested language sections inside of it (via a getChildren( )method). A compiler can use this feature to e.g. allow users to specify different editor preferences for different languages.
A compiler framework can also provide information about the entire project, individual files, text buffers, errors in the code, changes to the code and more.
Principal Compiler Framework Components
Below are descriptions of the principal components of a compiler framework in accordance with one embodiment of the present invention.
Project Compiler
The Project Compiler contains the list of source directories and the class path. However, the principal data structure maintained by the project compiler is the type cache (part of the java type namespace).
The type cache contains Java signatures for all of the classes that exist in the project. Some of those classes come from .class files on the class path and the others come from files in one of the source directories. One of the most important jobs of the compiler in the IDE setting is to keep the type cache up to date by watching for changes in the files in the source directories. This task is performed by one of the worker threads in the thread pool (see below).
The type cache is indexed by file name and by class name. For each file, the entry contains the current list of errors. This means that at any time the IDE can know which files contain errors and can display those errors without opening the file. For each class, the type cache maintains a list of dependencies. A reverse index of dependencies also exists so that the compiler can quickly determine if changes made have broken dependencies in unchanged files.
Another important benefit of the type cache is improving the performance of type checking. The type cache allows a single file to be compiled without processing any other files. All external information needed to compile the file is contained in the type cache.
The project compiler (and its contained type cache) is serializable. The IDE will serialize the final state of the compiler to disk when the IDE is closed so that it can display the available classes when the IDE is reopened without parsing any files (other than those changed since closing).
File Compiler
A file compiler can be used to perform compilation of a single source file. It is designed to perform incremental compilation. Hence, it can maintain data structures containing the result of the previous scan, parse, and, in the case of a non-Java language, translation into Java classes. When changes are made to the file in memory, the next compile can reuse much of the previous results, vastly speeding up the process.
One of the unique features of this compiler is its built-in support for nesting of languages. The compiler maintains data structures containing information about where language nesting occurs (according to the last parse of the file). This is critical for the editor, which must react differently depending on which language contains the cursor at any given moment.
The compiler can support the interoperation of different languages. Specifically, any language can call into any other language. This is accomplished by using a common intermediate language. Since the target platform is the Java VM, the clear choice for intermediate language is Java itself. The compiler has a common Java back-end, which is used by all languages for producing byte codes. Each language is able to translate from its parse tree into Java classes. These classes are placed into the type cache to allow other languages to reference them.
Also important is the framework for language nesting. The outer language is able to determine where the inner language begins. Either the inner or the outer language may determine where the inner language ends. (In the normal case, the outer language will determine this. However, in special cases, the inner language can as well.) The file compiler will remember where the language nesting occurred for reuse on the next parse. Lastly, the outer language may implement a name resolution interface to allow the inner language to resolve references to names defined outside of the nested language.
Thread Pool
A thread pool can be used in both the IDE and runtime. In the context of the IDE, all parsing needs to be performed on background threads so that the process may be interrupted (if the user starts typing, for example). In the context of the runtime, the thread pool allows compilation of multiple files to be performed in parallel. Compilation should scale linearly to the number of processors. Naturally, all compiler data structures are implemented with appropriate synchronization. They do not assume that the client is accessing the APIs in a single-threaded manner.
Languages
Language objects can provide the editor with information needed to implement editor features. Language objects contain a method for retrieving different types of information using keys. If that language provides the information, the result of the lookup will be an object implementing a known interface. If not, the result will be null.
Standard interfaces exist for the type of information needed to implement standard editor features. Features that only exist for one language are implemented with custom interfaces. Standard interfaces also have default (abstract) implementations. Language implementers that want to provide such information only need to implement the abstract methods of the default implementation.
As an example, one standard interface provides information about matching characters in the token stream. This may be used to implement several features in the editor, such as the bolding of matching characters and the move to matching character keyboard command. To provide this information for a particular language, the language implementer only needs to implement methods describing which tokens match with which other tokens. The code that performs the search will be provided in the default base class.
These interfaces do not represent editor features directly. Rather they will represent types of information that is used to implement editor features. The code for turning this information into real features will exist in the editor.
As described above, data structures in the file compiler allow the editor to retrieve the stack of languages in affect a given point in the code. Maintaining languages as objects that can be retrieved in this manner is important because it provides that the same language features are available no matter where that language is used. For example, XML end tag completion should be available whether the user is editing a WSDL file, an XML map nested inside of an annotation in a JWS file, or XML in a script file. This will occur because all situations return the same language object for the XML part of the source.
Compiler Framework Interaction
When a new file is added to the project or an existing file is modified, the editor can notify the compiler of the change (e.g., via the interface com.bea.compiler.IProject). The compiler framework and the editor can both have access to the text buffer containing the contents of the file being edited. Each time the user modifies the file, the following exemplary steps can be taken.
For example, newly introduced errors may be highlighted using squiggly red underlines. If the code structure has changed, the change may be reflected in the structure browser.
It is important to note that the compiler may only complete a small amount of work needed to give immediate feedback to the user while the user is typing. All the larger tasks can be staged for background computation, so as not to disrupt responsiveness to the user.
Parse Tree Merge Algorithm
To maintain a positive user experience, it can be important for the merge algorithm mentioned above to be very efficient and to identify the minimal number of changes required to synchronize the parse trees maintained by the editor and the compiler framework. Each change notification generated by this algorithm may result in a significant amount of additional work, which could slow the system down. Therefore, naïve comparison algorithms that tend to “get lost” and generate false positives for portions of the file that have not actually changed may not suffice.
One merge algorithm with acceptable characteristics is presented below. The algorithm is recursive and is initially called passing the root nodes of the destination parse tree and source parse tree as parameters. The trees are constructed of nodes with edges connecting each parent node to its child nodes. Each destination node has a set of properties, which must be updated based on the associated source node.
Language Nesting
Because an editor can be language independent, nested languages can be handled. All detailed knowledge about the various languages can be embedded in language modules plugged into the underlying compiler framework. A compiler framework can use language neutral APIs described elsewhere herein to communicate understanding of the language concepts to the editor (e.g., positions and types of tokens, errors, etc.).
The editor can use the information provided by the compiler framework to determine which language is currently being edited and detect when the user moves the cursor from one language to another. This is useful e.g. if the user wants to establish different editing or display preferences for each language. For example,
The compiler can expose information about the languages used in a source file as a tree of language nodes. Each language node can identify a section of the file written in a particular language. The start position, stop position and information about the language (e.g., its name) are provided. If necessary, the editor can navigate this tree to understand all the languages used in a given source file and how they are nested inside one another.
The compiler framework can determine the initial language of each file using the file type (e.g., determined by a filename extension). It can then pass the file to language module that is registered to process files of that type. The language module in turn is programmed to identify the type and start position of any nested languages allowed in that language. The language module may also identify the end position of the nested language, but may request the assistance of the nested language processor for this task. Once the type and boundaries of a nested language are identified, the compiler framework will pass this portion of the file to the language module registered to process that language type. This process may continue allowing the editor and compiler framework to handle arbitrarily deeply nested languages.
Language Drivers
If the developer of a language module or custom language editing view wants to expose unique editing features tailored toward a specific language, they can implement a language driver. The language driver encapsulates the unique characteristics of the language and allows them to be plugged directly into the editor without requiring language specific features to be added to the editor itself. The complete API for developing language drivers is described in detail elsewhere herein.
Custom Editors and Views
Developers that wish to build custom editors for specific languages may do so by creating a class that implements the ISourceDocument interface specified elsewhere herein. The class DefaultSourceDocument can provide a default implementation of all the relevant editor features. Developers may derive their implementation from this class so they only have to override the specific behaviors they want to customize.
Likewise, developers wishing to build custom views for a specific language may do so by creating a class that implements the ISourceView interface specified also specified elsewhere herein. The class DefaultSourceView can provide a default implementation of all relevant view features. Developers may derive their implementation of ISourceView from this class so they only have to override the specific behaviors they want to customize.
Application Interfaces
Editor Extension API
A language independent editor can expose a set of APIs that can be used to define custom editor features and custom views for specific languages (e.g., visual editing tools). The full details of this API are described in this section.
Package com.bea.ide.sourceeditor
This package defines how the editor can be extended to support custom editing features and views e.g. for a particular language. Its classes and interfaces are described below.
public class com.bea.ide.sourceeditor.SourceUndoManager extends
javax.swing.undo.UndoManager
public interface com.bea.ide.sourceeditor.ISourceView implements com.bea.ide.document.IDocumentView
The ISourceView interface allows for manipulation of many end-user visible attributes of a document's text view.
public interface com.bea.ide.sourceeditor.ISourceDocument implements com.bea.ide.document.IDocument
ISourceDocument should be implemented by all document types with text data that wish to perform basic compiler-related functionality such as syntax coloring and parse tree support.
public class com.bea.ide.sourceeditor.EditorSvc
public static interface com.bea.ide.sourceeditor.EditorSvc.I
public class com.bea.ide.sourceeditor.DefaultSourceViewInfo extends com.bea.ide.document.DefaultDocumentViewInfo
Utility class allowing for delayed loading of a document's source view. The only reason for this extension of DefaultDocumentViewInfo is to provide a means of checking to see whether the view has been created so that unneccesary view construction can be avoided.
public abstract class com.bea.ide.sourceeditor.DefaultSourceDocument extends com.bea.ide.document.DefaultDocument implements com.bea.ide.sourceeditor.ISourceDocument
A default implementation of ISourceDocument. This makes the assumptions that any ISourceElement parse tree is made up of element types deriving from DefaultSourceElement. Usage Subclasses of this one need only implement @link #createDrivers( )??
public class com.bea.ide.sourceeditor.DefaultFileStatus implements com.bea.ide.ui.statusbar.IFileStatus
A simple object for setting line and column information displayed in the status bar.
Package com.bea.ide.sourceeditor.compiler
This package defines ways custom editors or views can interact with and get language information from the compiler. Its classes and interfaces are described below.
public abstract class com.bea.ide.sourceeditor.compiler.TwoWayEdit
A utility class to handle the details of submitting a two-way edit request to the compiler. While this class may be used directly, two-way edits are almost always initiated with methods on the @link com.bea.ide.sourceeditor.elementiSourceElement ISourceElement interface, making direct use of this class unneccesary.
public static class com.bea.ide.sourceeditor.compiler.TwoWayEdit.AddChild extends com.bea.ide.sourceeditor.compiler.TwoWayEdit
public static class com.bea.ide.sourceeditor.compiler.TwoWayEdit.ChangeProperty extends com.bea.ide.sourceeditor.compiler.TwoWayEdit
public static class com.bea.ide.sourceeditor.compiler.TwoWayEdit.RemoveChild extends com.bea.ide.sourceeditor.compiler.TwoWayEdit
public class com.bea.ide.sourceeditor.compiler.JavaBuilder implements com.bea.ide.sourceeditor.compiler.ILanguageBuilder
The builder class for java document types. This builder will handle construction of IDE-side parse trees for document types made up of java and java annotation languages.
The parse tree constructed is made up of @link com.bea.ide.sourceeditor.element.DefaultSourceElement DefaultSourceElement derivations, and contains most frequently needed parse information. Parse trees constructed by this class do not contain any parse information for Java method bodies. This is done intentionally, for performance reasons.
Construction of the parse tree takes place through calls into the builder methods from the compiler framework. See the @link com.bea.ide.sourceeditor.driver.ICompilerDriver ICompilerDriver for information on how to specify a builder for a different document type.
public interface com.bea.ide.sourceeditor.compiler.IPackageCache
public static interface com.bea.ide.sourceeditor.compiler.IPackageCache.ITypeDefinition
ITypeDefinition defines a cached package to be a set of two values, a type name and a package name. For example, type java.util.List is split into type name “List”, and package “java.util”.
public interface com.bea.ide.sourceeditor.compiler.ILanguageBuilder
this is basically a wrapper for a Javelin IStructureBuilder.
public interface com.bea.ide.sourceeditor.compiler.ILangObjectMapper
Interface used to map a class of compiler objects returned from <code> ISourceInfoFeature</code> to objects with the interfaces necessary for IDE related features. Use the extension.xml handler ‘urn:com-bea-ide:sourceeditor:sourceinfo’ to register an implementation of this interface. Entries have the following format: &It:object-mapper class=“workshop.sourceeditor.lang.TypeInfoObjectMapper”>&It;compiler-object type=“com.bea.compiler.info.IMethod”>&It:compiler-object type=“com.bea.compiler.info.IPackage”>&It;/object-mapper>
public interface com.bea.ide.sourceeditor.compiler.IIdentifierinfo
public interface com.bea.ide.sourceeditor.compiler.ICompletionSet
Interface representing a set of completions, used for statement completion support.
public interface com.bea.ide.sourceeditor.compiler.ICompletionitem
public static interface com.bea.ide.sourceeditor.compiler.ICompletionitem.IFormatRange
getRange( ) should return a 0-indexed range of text from getDisplayText that it wants to apply a format to. getTokenName( ) is used to look up that token name in the syntax coloring feature. As such, the token-names should be the same as what the compiler spits out (i.e. “java.identifier”). getImage( ) is only used if getTokenName( ) returns null. getImage( ) returns an image to display in place of the characters covered by the range.
public interface com.bea.ide.sourceeditor.compiler.ICompilerDiagnostic
public class com.bea.ide.sourceeditor.compiler.CompilerSvc
The Compiler Service is the general mechanism for communication between the IDE and Javelin, BEA's compiler framework. Since this type of communication is extremely structured, occurring primarily when the file system or document contents change, it is rarely necessary to call many of these methods explicity in an IDE extension. Some, like @link com.bea.ide.sourceeditorcompiler.CompilerSvc.I#getFeature getFeature are frequently called by external consumers.
public static interface com.bea.ide.sourceeditor.compiler.CompilerSvc.ITwoWayEditLock
public static interface com.bea.ide.sourceeditor.compiler.CompilerSvc.ICompilerLockManager
public static interface com.bea.ide.sourceeditor.compiler.CompilerSvc.I
Package com.bea.ide.sourceeditor.driver
This package defines how the editor can be extended with custom language drivers for implementing special language features in the editor. Its classes and interfaces are described below.
public class com.bea.ide.sourceeditor.driver.SourcelnstructionPoint implements com.bea.ide.debug.IDebugInstructionPoint
Implements the IDebug BreakPoint interface for text files.
public class com.bea.ide.sourceeditor.driver.SourceBreakpoint extends com.bea.ide.debug.DefaultBreakpoint implements com.bea.ide.debug.ISourceBreakPoint This class implements a breakpoint that will work on a file that implements ISourceDocument.
public static class com.bea.ide.sourceeditor.driver.SourceBreakpoint.DefaultLine implements com.bea.ide.sourceeditor.model.lSourceModel.Line
public interface com.bea.ide.sourceeditor.driver.ISourceViewDriver implements com.bea.ide.core.IDriverSupport
Implements customizable features of the source view. This driver extends IDriverSupport so that the source view can obtain customized drivers for structure view, property view, etc. . . . The SourceView will call ISourceViewDriver#getDriver(Object) for drivers not implemented by the source view itself. Drivers that the source view implements, include: IHelpDriver, IPrintDriver and ITransferDriver.
public interface com.bea.ide.sourceeditor.driver.INavigationBarDriver
Contains file-specific code for implementing the navigation bar. Note that each file could potentially show up in the navigation bar either as the primary file or as a control being used.
public interface com.bea.ide.sourceeditor.driver.ILanguageDriver
Implementations of this driver provide customization for working with the languages in the source view. The methods require understanding of the lexical structure of the language for correct implemention. Note that one document may make use of several language drivers, since a single document type may contain several nested languages.
public static interface com.bea.ide.sourceeditor.driver.ILanguageDriver.IBlockInfo
Summary of the information gathered by the findMatchingXxx methods.
public static interface com.bea.ide.sourceeditor.driver.ILanguageDriver.IBlockDelim
Defines one end of a block. Note that block close positions are inclusive unlike ranges which have an exclusive end position.
public static interface com.bea.ide.sourceeditor.driver.ILanguageDriver.IParameterHelp
public static interface com.bea.ide.sourceeditor.driver.ILanguageDriver.IAutoCorrection
public static interface com.bea.ide.sourceeditor.driver.ILanguageDriver.IAutoFill
Object describing an auto-fill. Each auto-fill has three components, the replacement text, a replacement range and the final caret position.
public interface com.bea.ide.sourceeditor.driver.ICompilerDriver
ICompilerDriver implementations allow different document types to customize their behavior with respect to the Javelin compiler framework. See individual methods for more information.
public class com.bea.ide.sourceeditor.driver.DefaultSourceViewDriver extends com.bea.ide.sourceeditor.driver.DefaultDocumentDriver implements com.bea.ide.sourceeditor.driver.ISourceViewDriver
A default implementation of SourceViewStrategy.
public class com.bea.ide.sourceeditor.driver.DefaultLanguageDriver extends com.bea.ide.sourceeditor.driver.DefaultDocumentDriver implements com.bea.ide.sourceeditor.driver.ILanguageDriver
public static class com.bea.ide.sourceeditor.driver.DefaultLanguageDriver.BlockInfo implements com.bea.ide.sourceeditor.driver.ILanguageDriver.IBlockInfo
public static class com.bea.ide.sourceeditor.driver.DefaultLanguageDriver.BlockDelim implements com.bea.ide.sourceeditor.driver.ILanguageDriver.IBlockDelim
public class com.bea.ide.sourceeditor.driver.DefaultDocumentDriver
public class com.bea.ide.sourceeditor.driver.DefaultDebugRunnable extends com.bea.ide.sourceeditor.driver.DefaultDocumentDriver implements com.bea.ide.workspace.IWebRunnable
This is the debug class to take care of being runnable, etc. UNDONES(willpugh) All the funky JSX/Script environments stuff should be pulled out into a script DebugRunnable class for jsx.
public class com.bea.ide.sourceeditor.driver.DefaultDebugDriver extends com.bea.ide.sourceeditor.driver.DefaultDocumentDriver implements com.bea.ide.debug.IDebugDriver
Implements the strategy for debugging text files.
public class com.bea.ide.sourceeditor.driver.DefaultCompilerDriver implements com.bea.ide.sourceeditordriverICompilerDriver
The default compiler driver specifies default compiler interactions for compiler-recognized document types. This behavior generally consists of syntax coloring and error reporting within the source editor. This default behavior does NOT include the creation of an IDE-side parse/structure tree. For this functionality, a document type must supply a compiler driver implementation that returns a valid @link com.bea.ide.sourceeditor.compiler.ILanguageBuilder ILanguageBuilder interface from the @link com.bea.ide.sourceeditor.driver.ICompilerDriver#createBuilder createBuilder method. See @link com.bea.ide.lang.java.driver.JavaCompilerDriver JavaCompilerDriver for an example.
Note that a providing a compiler driver on a document type is only useful if that document type is recognized by the compiler framework. This functionality is generally achieved by writing a compiler language extension or by mapping a new document type to an existing language extension via the compiler's ‘javelin-config.xml’ configuation file.
Package com.bea.ide.sourceeditor.element
This package defines how the editor can be extended to support new or modified elements in the language. Elements are recognizable pieces of a document (e.g., a function name). Its classes and interfaces are described below.
public interface com.bea.ide.sourceeditor.element.ISourceElementGroup
Empty interface.
public interface com.bea.ide.sourceeditor.element.ISourceElement implements com.bea.ide.document.IDocumentElement
An ISourceElement is a specific type of IElement corresponding to the contents of a document. All parse tree elements are of type ISourceElement.
public abstract class com.bea.ide.sourceeditor.element.DefaultSourceElement extends com.bea.ide.document.DefaultDocumentElement implements com.bea.ide.sourceeditor.element.ISourceElement
A default implementation of ISourceElement.
protected class com.bea.ide.sourceeditor.element.DefaultSourceElement.DefaultAuthorElement
protected class com.beaide.sourceeditor.element.DefaultSourceElernent.CompilerPropertyDescriptor extends java.beans.PropertyDescriptor
protected static class com.bea.ide.sourceeditor.element.DefaultSourceElement.StaticCompilerPropertyDescriptor extends java.beans.PropertyDescriptor
For performance, a class that can be passed to CompilerPropertyDescriptor's constructor to save the overhead of finding the getter and setter methods.
Package com.bea.ide.sourceeditor.model
This package defines ways custom editors or views can interact with the document model. The document model is a data structure that contains the text of a document. Its classes and interfaces are described below.
public interface com.bea.ide.sourceeditor.model.ISourceModeIListener
A source model listener is notified of all changes to a source model. This includes changes to the text data as well as line attributes.
public interface com.bea.ide.sourceeditor.model.ISourceModelEvent
A source model event indicates that the text of the source model has changed in some way. Changes include text changes and line attribute changes. See ISourceModelListener and ISourceModel.addSourceModelListener for more information.
public static final class com.bea.ide.sourceeditor.model.ISourceModelEvent.EventType
The type of change indicated by the event. There are three types, each static objects that can be compared directly via references.
public interface com.bea.ide.sourceeditor.model.ISourceModel
A source model is a data structure that contains the actual text data of a given document. Generally implemented as a linked list of lines, some implementations may extend the swing AbstractDocument class, though this is not required and should not be relied upon.
public static interface com.bea.ide.sourceeditor.model.ISourceModel.Line
A line in the source model. It is assumed that it is safe to hold a reference to a line through document edits; Line objects must remain valid by tracking document changes and adjusting their range appropriately.
Package com.bea.ide.sourceeditor.ul
This package defines mechanisms developers can use to implement custom UI features. Its classes and interfaces are described below.
public interface com.bea.ide.sourceeditor.ui.IPopupTip
public static interface com.bea.ide.sourceeditor.ui.IPopupTip.Container
public interface com.bea.ide.sourceeditor.ui.IHoverListener
public class com.bea.ide.sourceeditor.ui.HoverEvent extends javax.swing.event.ChangeEvent
public abstract class com.bea.ide.sourceeditor.ui.DefaultPopupTip implements com.bea.ide.sourceeditor.ui.IPopupTip
Compiler Framework Client API
A compiler framework client API can define how clients, such as the editor and runtime, communicate with the compiler framework. Clients can use this API to access and modify a wide range of information about the project, its source files and object files. This API can be the mechanism by which the full compiler is integrated into the editor to provide the features described above. This section contains a complete description of all the packages that are part of the client API.
This API defines how the editor and runtime use the compiler. The package COm.bea.compiler contains the main interfaces. Some subpackages of this provide additional interfaces that are specific to a particular language. For example, the APIs in com.bea.compiler.java provide the Java-specific information for the editor and runtime.
The compiler framework is designed for integration into an editor. Like any Java compiler, the compiler framework can translate source files into Java bytecodes. But in addition, the compiler framework is designed to provide the language information that is the backbone of advanced editor features. The compiler framework makes it easy to translate the language knowledge in the compiler into editor features.
Package com.bea.compiler
This package defines how the editor and runtime use the compiler to get language information and produce running code. Its classes and interfaces are described below.
public interface com.bea.compiler.IToken
Contains information about a token found by a scanner.
public interface com.bea.compiler.ITextChange
Represents a change that occurred in the text of a source file.
public interface com.bea.compiler.IProjectChangeListener
Defines the shape of project change notifcations to the client.
public interface com.bea.compiler.IProjectChangeEvent
Encapsulates all of the changes found during a compilation.
public interface com.bea.compiler.IProject
Maintains compiler information about all of the source files in a project. This information is automatically updated when notified of changes to the source files. When requested, it will produce a .class files.
Note that the project does not take a source path argument. Instead, the source path is managed by applying changes to the project. Thus, to add files to a new project, the client must apply a change list containing an add for each of the files.
public static interface com.bea.compiler.IProject.IOutputDirector
Provides a mapping from source file to a root under which all the generated classes for the file will be placed.
public static interface com.bea.compiler.IProject.IInUseFile
public interface com.bea.compiler.INode
Represents a node in the tree of nested languages in a source file.
public interface com.bea.compiler.INamespace
Maintains information about some sort of objects that can be defined by source files in a project.
public static interface com.bea.compiler.INamespace.IInfoChange
Represents a change that was found during compilation regarding an object in this namespace.
public interface com.bea.compiler.ILanguage
Represents a particular language supported by the compiler.
public interface com.bea.compiler.IFileStore
Encapsulates knowledge about how to navigate a particular type of store for source files. New file stores can be registered with the compiler.
public static interface com.bea.compiler.IFileStore.IRoot
Represents the root of a tree of files. This allows lookup for specific files under that root.
public static interface com.bea.compiler.IFileStore.IEntry
Represents an entry (file or directory) under a particular root.
public interface com.bea.compiler.IFileChange
Represents a change that was found in a source file of the project. These objects will be used to notify the compiler of the changes.
public interface com.bea.compiler.IFile
Encapsulates information about a file. The file may contain source text or it may be a file/jar of compiled class(es).
public interface com.bea.compiler.IDiagnosticSet
Encapsulates a set of diagnostics found in the source. The encapsulated set of diagnostics is grouped into entries, where each entry corresponds to a file that contains some diagnostics.
public static interface com.bea.compiler.DiagnosticSet.IEntry
Encapsulates a file all of its diagnostics.
public interface com.bea.compiler.IDiagnostic
Contains information about an error detected in the source code. Note that the range returned is inclusive on both ends.
Note that a ‘column’ in this context is a count of the number of characters. Specifically, a tab increases the column count by one.
public interface com.bea.compiler.ICompiler
Maintains global information about the configuration of the compiler. Multiple projects may be outstanding at the same time, all of which share this configuration.
public static interface com.bea.compiler.ICompiler.IExceptionListener
Defines the events provided to listeners for uncaught exceptions.
public interface com.bea.compiler.IBufferCache
Provides instances of IBuffer to the compiler if they exist in the cache.
public interface com.bea.compiler.IBuffer
Encapsulates access to the contents of a source file. The file in question can be in memory or on disk.
Note that the contents of the buffer should never change asynchronously to the compiler. In other words, a buffer should represent a of the source code, and unless the compiler requests a change to the text by calling replaceText, the contents should not change.
public interface com.bea.compiler.IBackEnd
Represents a particular back-end supported by the compiler.
public class com.bea.compiler.Compiler
Stores a reference to the single instance of the class that implements ICompiler.
Package com.bea.compiler.classfile
This package defines how the editor and runtime use the compiler to get language information and produce running code. Its classes and interfaces are described below.
public class com.bea.compiler.classfile.ClassFileAnnotation implements java.io.Serializable
This class defines the shape of annotation entries put into the .class files generated by the compiler. The value of each attribute is a serialized version of an array of these ClassFileAnnotation.
Package com.bea.compiler.command
This package defines how the client sends commands to the compiler and receives the results. Its classes and interfaces are described below
public interface com.bea.compiler.command.ICmdCompiler
public static interface com.bea.compiler.command.ICmdCompiler.IResult
Records information about the result of compilation.
public class com.bea.compiler.command.CmdCompiler
Provides the ability to instantiate command-line compilers.
Package com.bea.compiler.enterprise
This package defines how the client gets additional information pertaining to enterprise applications, such as web applications. Its classes and interfaces are described below
public interface com.bea.compiler.enterprise.IEntProject
Defines additional information needed for an enterprise project. By “enterprise”, we mean both J2EE and the WebLogic Workshop framework. For example, this information may be provided in web.xml.
public static interface com.bea.compiler.enterprise.IEntProjectiWebAppProject
Exposes the information available on a enterprise project that is a web application project.
Package com.bea.compiler.feature
This package defines how the client accesses information about certain features of the souce code. Its classes and interfaces are described below.
public interface com.bea.compiler.feature.ITokenInfoFeature implements com.bea.compiler.feature.IFeature
public interface com.bea.compilenfeature.IStructureFeature implements com.bea.compilerfeature.IFeature
Used to build structure trees, which are client accessible representations of the parse tree. Structure trees are medium used for two-way editing.
public static class com.bea.compiler.feature.IStructureFeature.Range
Stores a range in the source code.
public static interface com.bea.compiler.feature.IStructureFeature.IStructureBuilder
An interface used to build structure trees. An IStructureBuilder must be implemented by the user of this feature and passed to createStructure. The builder will be called in order to build the structure tree.
public static interface com.bea.compiler.feature.IStructureFeature.IStructureNode
An interface that must be implemented by the nodes in a structure tree.
public static interface com.bea.compiler.feature.IStructureFeature.IAuthorNode
An interface that must be implemented by nodes that are used to author code.
public static class com.bea.compiler.feature.IStructureFeature.StructureCode implements java.lang.Comparable
Represents a “code” used is used to identify a type of nodes or a property on a node. Each code can be thought of as a pair of the form (class, code). This allows each language to define its own space of codes, which cannot conflict with another language's codes.
public interface com.bea.compilenfeature.ISourceinfoFeature implements com.bea.compiler.feature.IFeature
This is similar to the ITokenInfoFeature but provides more general information about the source. For that reason, it can be used only on files that have completed the front-end of compilation.
public static class com.bea.compilenfeature.ISourceInfoFeature.Range
Records a range of offsets in the source of the form [start,end).
public static class com.bea.compiler.feature.ISourceInfoFeature.MethodCallContext
Provides enclosing context for a method call.
public interface com.bea.compilenfeature.IPropertyInfoFeature implements com.bea.compiler.feature.IFeature
Provides information about the properties of a certain strucutre node, including the valid tags and their attributes.
public static interface com.bea.compiler.feature.IPropertyInfoFeature.IDescription
This interface provides information about a node.
public static interface com.bea.compilenfeature.IPropertyInfoFeature.ITag
This interface provides information about a tag
public static interface com.bea.compiler.feature.IPropertyInfoFeature.IAttribute
This interface provides information about an attribute.
public static interface com.bea.compiler.feature.IPropertyInfoFeature.IType
This interface provides information about a type.
public static interface com.bea.com piler.feature.IPropertyInfoFeature.ICustomType
This interface provides info about a custom type
public static interface com.bea.compiler.feature.IPropertyInfoFeature.ITypeFactory
Factory interface that supports creating different types
public static class com.bea.compiler.feature.IPropertyInfoFeature.TypeFactory
Contains reference to an ITypeFactory singleton object.
public interface com.bea.compiler.feature.INodeInfoFeature implements com.bea.compiler.feature.IFeature
Provides information about the language structure of a file.
public interface com.bea.compiler.feature.IFeature
The interface all features provide to the compiler clients.
Package com.bea.compiler.fileinfo
This package defines how the client accesses information about the project's files and directories. Its classes and interfaces are described below.
public interface com.bea.compiler.fileinfo.IFileNamespace
Maintains the namespace of files for a project. This namespace allows compilers to query for files with given names and to look at any exposed content. In both cases, dependencies are added on that information.
public static interface com.bea.compiler.fileinfo.IFileNamespace.IInfoChange implements com.bea.compiler.INamespace.IInfoChange
Describes a change that occurred in the type namespace. This includes both the outer type and the entity because a new member can show up in types that inherit it as well as its outer type.
public interface com.bea.compiler.fileinfo.IFileInfo implements java.lang.Comparable
Represents a node in the file namespace, which can be either a file or a directory. Each file can provide access to its content in various forms. Each content type is encoded using a MIME-like name.
Package com.bea.compiler.info
This package defines how the client accesses information about the structure of a source file. Its classes and interfaces are described below.
public class com.bea.compiler.info.Type
Contains references to the static types defined. These statics are filled in at run-time by the framework.
public class com.bea.compiler.info.Name
Contains references to the static names defined. These statics are filled in at run-time the framework.
public interface com.bea.compiler.info.IVariable
Encapsulates information about a variable defined in the source. This variable can be a local variable, a method parameter, a field of a user type, and so on.
public interface com.bea.compiler.info.IType
Represents a Type available in the Java runtime or the error type, which is used at compile time to denote something of an unknown type.
public interface com.bea.compiler.info.IReferenceTypeMember implements com.bea.compiler.info.IDeclaredEntity
Represents a member of a type, which can be a field, method, or a type.
public interface com.bea.compiler.info.IReferenceType implements com.bea.compiler.info.IPackageMember, com.bea.compilerinfo.IReferenceTypeMember, com.bea.compiler.info.IType
Represents a reference type, which can be either user-defined type (i.e., a class or interface) or an arrayp type.
public interface contbea.compiler.info.IPackageMember implements java.lang.Comparable
Represents a member of a package, which can be either a package or a top-level type.
public interface com.bea.compiler.info.IPackage implements com.bea.compiler.info.IPackageMember
Represents a package that exists in the source code.
public interface com.bea.compiler.info.IName implements java.lang.Comparable
Refers to a declared entity in the source code. A name is composed of sequence of identifiers. The last identifier, which is most specific to this named entity, is referred to simply as its ID.
public interface com.bea.compiler.info.IMethod implements com.bea.compiler.info.IReferenceTypeMember, com.bea.compiler.info.ICallable
Represents a method of a user-defined type.
public interface com.bea.compiler.info.IField implements com.bea.compiler.info.IReferenceTypeMember, com.bea.compiler.info.IVariable, java.lang.Comparable
Represents a field of a user-defined type.
public interface com.bea.compiler.info.IDeclaredEntity
Represents any entity declared in the source file. This can be a user-defined type, a field, a method, or a constructor. Note that only the first three of those are members of the outer type.
public interface com.bea.compiler.info.IConstructor implements com.bea.compilerinfo.ICallable
Represents a constructor of a user-defined class.
public interface com.bea.compiler.info.ICallable implements com.bea.compiler.info.IDeclaredEntity, java.lang.Comparable
Represents a callable object in a class, namely a constructor of method.
public interface com.bea.compiler.info.IArrayType implements com.bea.compiler.info.IReferenceType
Represents an array reference type.
public interface com.bea.compiler.info.IArgument implements java.lang.Comparable
Represents an argument to a callable in the source.
public interface com.bea.compiler.info.IAnnotationSet Represents the set of annotations and javadoc information on a declared entity, including “synthetic” annotations that were added but not present in the source text proper.
public interface com.bea.compiler.info.IAnnotation
Contains additional information provided in the language about a particular reference type or member.
Annotations have values that are arbitrary objects. A grammar for a set of annotations will define more precisely what these values will be so that consumers of those annotations can deal with them appropriately.
public interface com.bea.compiler.info.IAccess
Represents a type of accessibility available in the Java runtime on a class, interface, or member.
public class com.bea.compiler.info.Access
Contains references to the four types of access defined. These statics are filled in at run-time the framework.
Package com.bea.compiler.info.beaninfo
This package defines how the client accesses additional information available for JavaBeans. Its classes and interfaces are described below.
public interface com.bea.compiler.info.beaninfo.IPropertyDescriptor
Represents a JavaBean-style property.
public class com.bea.compiler.info.beaninfo.Introspector
public interface com.bea.compiler.info.beaninfo.IIntrospector
public interface com.bea.compiler.info.beaninfo.IIndexedPropertyDescriptor implements com.bea.compiler.info.beaninfo.IPropertyDescriptor
Represents a JavaBean-style indexed property.
public interface com.bea.compiler.info.bean.info.IEventDescriptor
Represents a JavaBean-style event descriptor
public interface com.bea.compiler.info.beaninfo.IBeanInfo
Represents the JavaBean information associated with a specific reference type
Package com.bea.compiler.java
This package defines the information produced by the Java programming language support in the compiler. Its classes and interfaces are described below.
public class com.bea.compiler.java.JavaStructure extends com.bea.compiler.feature.IStructureFeature.StructureCode
Package com.bea.compiler.java.annotation
This package defines the information produced by the Java programming language support in the compiler about the annotations found in Java source code. Its classes and interfaces are described below.
public class com.bea.compiler.java.annotation.AnnotationStructure extends com.bea.compiler.feature.IStructureFeature.StructureCode
Package com.bea.compiler.typeinfo
This package defines how the client accesses information about types. Its classes and interfaces are described below.
public interface com.bea.compiler.typeinfo.ITypeNamespace implements com.bea.compiler.INamespace
Represents the namespace of types that were defined in the project.
public static interface com.bea.compiler.typeinfo.ITypeNamespace.IInfoChange implements com.bea.compiler.INamespace.IInfoChange
Describes a change that occurred in the type namespace. This includes both the outer type and the entity because a new member can show up in types that inherit it as well as its outer type.
Compiler Framework Language API
This API defines how to extend the compiler with new languages.
This API defines how to extend the compiler with new languages. The package com.bea.language contains the main interfaces. Some subpackages of this provide additional interfaces that are specific to a particular language. For example, the APIs in com.bea.compiler.java define how to extend Java with further language information.
Package com.bea.language
This exemplary package defines how the compiler framework interacts with specific language modules. It defines how support for compiling a particular language is provided to the compiler framework. Its classes and interfaces are described below.
public interface com.bea.language.IParseNode
Implemented by all parse tree nodes in the compiler framework.
public interface com.bea.language.ILineColumn
Records the line and column of a particular offset in the source.
public interface com.bea.language.ILangToken
Extends IToken with the ability to retrieve the text value of the token. This is in the language API because this method is only available during compilation.
The purpose of having this type is to allow for tokens that retrieve their text values in different ways. Thus, this method should be always be used to retrieve the text of a token, rather than asking the ILangContext for the text at this range.
public interface com.bea.language.ILangResolver
Encapsulates the ability to translate from the parse tree into a set of Java class files.
public static interface com.bea.language.ILangResolver.IFileResolver
Performs resolving of the file as a whole.
public static interface com.bea.language.ILangResolver.ITypeResolver
Performs resolving of a type in the file.
public static class com.bea.language.ILangResolver.ITypeResolver.SuperTypes
Records the superclass and interfaces of some type.
public static interface com.bea.language.ILangResolver.IUpdateResolver
Used to update links between entities and their source in the parse tree when copying resolve shapes.
public static interface com.bea.language.ILangResolver.IOuterContext
Contains information passed by the outer language during parsing.
public static class com.bea.language.ILangResolver.DefaultOuterContext implements com.bea.language.ILangResolver.IOuterContext
Provides a default implementation of IOuterContext
public static class com.bea.language.ILangResolver.OuterContext
Provides a static reference to the current outer resolved.
public abstract class com.bea.language.ILangReader extends java.io.Reader
Extends the Reader class to allow a transducer to be used as input to a scanner. The transducer may hide multiple characters in the real stream with a single character (or vice versa), so this interface provides a way for the transducer to communicate the actual size in the underlying stream of the characters returned.
public interface com.bea.language.ILangParser
Encapsulates the parsing algorithm for a language.
public static interface com.bea.language.ILangParser.IOuterContext
Contains information passed by the outer language during parsing.
public static class com.bea.language.ILangParser.OuterContext
Provides a static reference to the current outer context.
public interface com.bea.language.ILangNode
Represents a node in the tree of nested languages. Each language owns some range of the file.
public interface com.bea.language.ILangNamespace
Defines the required implementation for a namespace of some sort that will be managed as part of a project. Namespaces are fundamental to compilation: the information they record is used by languages in order to ensure correct cooperation between files and is used by the client in order to understand what sort of objects are defined in a source file. As a result, namespaces must interact with the compiler in more detailed ways than even languages.
Each registered namespace will be instantiated using the default constructor in order to create an instance for a new project.
A bit of background about compilation is relevant here. When compilation begins, a list of changed files is known. During compilation, a namespace may discover that a dependency of another file has been broken. This will add an out-of-date file into the compilation. Also during compilation, a namespace may decide to add a file into the project. This normally occurs because a reference was made to a name that does not exist in the project but for which a file is found that probably contains the object with that name. This will add a “discovered” file into the compilation. Thus, at the end of compilation, there may be more files compiled than at the beginning.
Namespaces are responsible for updating themselves to the results of compilation of individual files and for notifying the compiler of out-of-date and discovered files.
File Status
Each time a compilation is performed, there is a target file status that is needed for each file. A “one-hot” encoding is used to indicate the status of a file. However, the status variable passed this instance will actually encode a range of statuses, meaning that compilation will stop when the file reaches any one of them.
public static interface com.bea.language.ILangNamespace.IInfoChange
Represents a change that was found in the namespace during the current compile. Changes are recorded in order to determine whether dependencies have been broken as well as to inform the client. Not all recorded changes need to be reported to the client.
public static interface com.bea.language.ILangNamespace.IContext
Defines the additional APIs available to namespaces.
Because namespaces can be used both during compilation and outside of it (i.e., from a feature), some of these methods must be available at both times. Methods not saying otherwise are available at all times.
public static interface com.bea.language.ILangNamespace.IInfoResolver
Used to perform some type of resolution on some object in the namespace. Every resolve can be described by a pair (object, phase) where object can be any object in the namespace and phase is an integer describing the type of information needed. It is assumed that two resolve requests are equal iff the objects and phases are equal.
public abstract class com.bea.language.ILangMultiReader extends com.bea.language.ILangReader
Extends ILangReader with the ability to insert the contents of another file into the stream at the current position.
public interface com.bea.language.ILangLocator
Provides the ability to retrieve a text range for a declared entity produced from a declaration in the file. This range is used for various things such as locating errors produced by the framework. The ranges returned from the methods below should just be the range of the name of this identifier, rather than the range of the entire declaration in the source.
public interface com.bea.language.ILangLanguage
Extends the ILanguage interface with information needed by the framework.
public interface com.bea.language.ILangGenerator
Encapsulates the algorithm for generating code in this language. This is accomplished by implenting a transformation from the parse tree of this file into the intermediate language for each class defined.
public static interface com.bea.language.ILangGenerator.IOuterContext
Contains information passed by the outer language during codegen.
public static class com.bea.language.ILangGenerator.OuterContext
Provides a static reference to the current outer context.
public interface com.bea.language.ILangContext
Provides the context in which the stages of compilation are performed. For convenience, all methods are defined here, although some are not applicable in all phases. This is done to allow phases to share code, which would then not know what phase it was running in. If a method is called in an inappropriate phase, an assertion will fire.
Each method below is marked with which phases can use it.
public interface com.bea.language.ILangCompiler
Encapsulates the ability to compile from a source language into Java class files.
public interface com.bea.language.ILangChecker
Encapsulates a semantic checking algorithm to perform as part of compilation for a language.
public static interface com.bea.language.ILangChecker.IOuterContext
Contains information passed by the outer language during parsing.
public static class com.bea.language.ILangChecker.OuterContext
Provides a static reference to the current outer resolved.
public interface com.bea.language.ILangBackEnd
Defines the functionality required in order to provide a back-end to the compiler.
public interface com.bea.language.IDependency
Records information about a dependency of a file (or more specifically, an object in the namespace) on the state of some part of the namespace. Namespaces will often keep references to the namespace on the “target” of the dependency, which is the parent of all objects in which changes would break the dependency. This makes it easy to see if a change broke any dependencies. The framework facilitates this by allowing dependencies to set and remove these references at the appropriate time of compilation.
public static interface com.bea.language.IDependency.IBreakChecker
Allows checking for changes that break this dependency.
public class com.bea.language.CyclicDependencyException extends java.lang.RuntimeException
Thrown when a cyclic dependency is found in the resolve phase. This is an unchecked exception because it can be thrown almost anywhere.
To simplify life for compiler writers, this class contains a static method that will return the current compilation context. This means that languages do not need to pass the context down through each component.
Package com.bea.language.codegen
This package contains the interfaces for the intermediate representation. Its classes and interfaces are described below.
public interface com.bea.language.codegen.IRXQRLStatement implements com.bea.language.codegen.IRStatement
Represents a foriegn set of statement(s) in the source code.
public interface com.bea.language.codegen.IRXMLListExpression implements com.bea.language.codegen.IRExpression
public interface com.bea.language.codegen.IRXMLExpression implements com.bea.language.codegen.IRExpression
public interface com.bea.language.codegen.IRXMLDotQuery implements com.bea.language.codegen.IRExpression
public interface com.bea.language.codegen.IRWithStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRWhileStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRVariableInitializer implements com.bea.language.codegen.IRNode
Represents the initializer of a variable or an array element. Variable initializers can be either single expressions, if the variable being initialized is not an array or they can contain an array initializer, if the element being initialized is also an array. Variable initializers are not used directly to initialize arrays, top-level array initializers are always IRArrayInitializer s.
If is Array returns true, this variable initializer actually represents an array initializer, and you should call getArrayInitializer otherwise this initializer is just a single expression and you should call getInitializerExpression.
public interface com.bea.language.codegen.IRUnaryExpression implements com.bea.language.codegen.IRExpression
public interface com.bea.language.codegen.IRTypeExpression implements com.bea.language.codegen.IRExpression
Represents and expression that just wraps a type.
public interface com.bea.language.codegen.IRType implements com.bea.language.codegen.IRNode
Defines the basic information about a Java type. More complicated types inherit from this class and add extra information. The type code is used to specify either one of the primitive types or a class or array type.
public interface com.bea.language.codegen.IRTryStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRThrowStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRThisExpression implements com.bea.language.codegen.IRExpression
Represents a reference to a this pointer. A this expression can be qualified by an arbitrary name.
public interface com.bea.language.codegen.IRTernaryExpression implements com.bea.language.codegen.IRExpression
public interface com.bea.language.codegen.IRSynchronizedStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRSwitchStatement implements com.bea.Ianguage.codegen.IRStatement
public interface com.bea.language.codegen.IRSwitchLabel implements com.bea.language.codegen.IRNode
public interface com.bea.language.codegen.IRSwitchBlockStatementGroup implements com.bea.language.codegen.IRNode
Represents a block of labels and statments that make up the body of a switch statement. A single switch block statement group represents a contiguous set of labels followed by the statements to be executed if any of those labels are matched. For example, the following:
case a: case b: case c: System.out.println(“foo”); break;
is one switch block statement group where a, b and c are the labels and the println and the break are the statements.
public interface com.bea.language.codegen.IRStatementExpression implements com.bea.language.codegen.IRStatement
Represents an expression which is being used in a statement. there are a limited number of expressions that can be legally used as statements including:
Assignments
Pre/Post increments/decrements
Method invocations
Class instance creations
public interface com.bea.language.codegen.IRStatement implements com.bea.language.codegen.IRNode
public interface com.bea.language.codegen.IRReturnStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRParenthesizedExpression implements com.bea.language.codegen.IRExpression
public interface com.bea.language.codegen.IROperator implements com.bea.language.codegen.IRNode
public interface com.bea.language.codegen.IRNode
The base class for all nodes in the intermediate representation. Every node has a unique node type code. All the possible node types are defined as members of this interface.
public interface com.bea.language.codegen.IRNamespaceStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRNameExpression implements com.bea.language.codegen.IRExpression
Represents and expression that just contains a name.
public interface com.bea.language.codegen.IRName implements com.bea.language.codegen.IRNode
Represents simple or qualified name. If the name is qualified, each simple component is represented by an <code>IRName</code>. The next component can be retrieved by using <code>getNext( )/code>. Names are stored in reverse order, that is com.bea.language would be represented as language->bea->com. <p>Also each name part can include information about what the name represents. This should be present on any name that is used in a context that allows multiple parts. Single-part names (for example, the IDs of fields and methods) will not have this information.
public static interface com.bea.language.codegen.IRNameiNameInfo
Defines the type of info available on names.
public interface com.bea.language.codegen.IRModifiers implements com.bea.language.codegen.IRNode
public interface com.bea.language.codegen.IRMethodInvocation implements com.bea.language.codegen.IRExpression
public interface com.bea.language.codegen.IRMethodDeclarationStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRMethodDeclaration implements com.bea.language.codegen.IRCIassBodyDeclaration
public interface com.bea.language.codegen.IRLocalVariableDeclarationStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRLocalVariableDeclaration implements com.bea.language.codegen.IRNode, com.bea.language.info.ILangVariable
public interface com.bea.language.codegen.IRLiteral implements com.bea.language.codegen.IRExpression
A literal represents a literal value that can appear in the source code such as “foo” or 1.0e+123. A literal consists of a type code, to identify the type of the literal and a string value.
public interface com.bea.language.codegen.IRLabeledStatement implements com.bea.language.codegen.IRStatement
Represents a statement that has a label next to it.
public interface com.bea.language.codegen.IRInitializerBlock implements com.bea.language.codegen.IRCIassBodyDeclaration
public interface com.bea.language.codegen.IRIffhenElseStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRForStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRFormalParameter implements com.bea.language.codegen.IRNode, com.bea.language.info.ILangVariable
public interface com.bea.language.codegen.IRFinally implements com.bea.language.codegen.IRNode
public interface com.bea.language.codegen.IRFieldDeclaration implements com.bea.language.codegen.IRCIassBodyDeclaration
public interface com.bea.language.codegen.IRFieldAccess implements com.bea.language.codegen.IRExpression
Represents a field access. There are few wrinkes here that are worth mentioning.
Field accesses can refer to the super class in which case is Super will be true. Depending on the situation, the class on which the field is being accessed can either be represented by a name or an expression. For instance new Foo( ).bar is a field access using an expression as the class name.
public class com.bea.language.codegen.IRFactory
public interface com.bea.language.codegen.IRExpression implements com.bea.language.codegen.IRNode
public interface com.bea.language.codegen.IREmptyStatement implements com.bea.language.codegen.IRStatement
Empty statements represent the case where a; is used as a statement. They do nothing and are simply placeholders.
public interface com.bea.language.codegen.IRDoStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRDeleteStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRContinueStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRConstructorInvocation implements com.bea.language.codegen.IRExpression
public interface com.bea.language.codegen.IRConstructorDeclaration implements com.bea.language.codegen.IRCIassBodyDeclaration
public interface com.bea.language.codegen.IRCompilationUnit implements com.bea.language.codegen.IRNode
public interface com.bea.language.codegen.IRClassOrInterfaceType implements com.bea.language.codegen.IRType
Represents a class or interface. It should be noted that the names of these types are not resolved. If you want those you should get the IReferenceType object for the type.
public interface com.bea.language.codegen.IRClassLiteral implements com.bea.language.codegen.IRExpression
Represents literal references to the class object for a particular type. An example would be Object.class.
public interface com.bea.language.codegen.IRClassInstanceCreationExpression implements combea.language.codegen.IRExpression
Represents a class creation expression, which is basically an expression that up a class. There are a two special things that can appear as part of one of these expressions.
First, a new expression may be qualified by a type, which is used to create inner classes outside of the class in which they are defined. This qualifier appears right before the new operator. Second, a new expression may have a “body” when an anonymous class is being created. This body will be a list of class body declarations which are used to extend the base class.
public interface com.bea.language.codegen.IRClassDeclarationStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRClassDeclaration implements com.bea.language.codegen.IRCIassBodyDeclaration
Represents a class or interface declaration.
public interface com.bea.language.codegen.IRClassBodyDeclaration implements com.bea.language.codegen.IRNode
Represents any declaration that can appear directly in a class. This includes fields, methods, classes, interfaces, constructors, and initializers.
public interface com.bea.language.codegen.IRCatches implements com.bea.language.codegen.IRNode
public interface com.bea.language.codegen.IRCastExpression implements com.bea.language.codegen.IRExpression
public interface com.bea.language.codegen.IRBreakStatement implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRBlock implements com.bea.language.codegen.IRStatement
public interface com.bea.language.codegen.IRBinaryExpression implements com.bea.language.codegen.IRExpression
public interface com.bea.language.codegen.IRAssertStatement implements com.bea.language.codegen.IRStatement
Represents an assert statement in the source code.
public interface com.bea.language.codegen.IRArrayType implements com.bea.language.codegen.IRType
public interface com.bea.language.codegen.IRArrayInitializer implements com.bea.language.codegen.IRNode
Represents the initializer of an array, or an element of an array that is also an array. Array initializers are composed of a linked list of IRVariableInitializer s.
public interface com.bea.language.codegen.IRArrayCreationExpression implements com.bea.language.codegen.IRExpression
Represents an expression that creates a new instance of an array. All such valid expressions will satisfy these invariant that the number of dimensions in the type of the array expression itself is equal to the number of dimension expressions plus the number of extra dimensions.
public interface com.bea.language.codegen.IRArrayAccess implements com.bea.language.codegen.IRExpression
public interface com.bea.language.codegen.IRAnnotationAttribute implements com.bea.language.codegen.IRNode
Describes an attribute of an annotation on an declared entity in the file. An annotation attribute is similar to an attribute in XML.
public interface com.bea.language.codegen.IRAnnotation implements com.bea.language.codegen.lRNode
Describes an annotation on a declared entity in the file. An annotation is similar to a tag in XML.
public interface com.bea.language.codegen.IIRFactory
Package com.bea.language.enterprise
This package provides information about the enterprise context of the project. Its classes and interfaces are described below.
public interface com.bea.language.enterprise.ILangEntContext
Provides additional context for enterprise projects.
public class com.bea.language.enterprise.EntContext
Provides access to the enterprise context for this project.
Package com.bea.Ianguage.feature
This package defines how a language extension accesses information about certain features of the source code. Its classes and interfaces are described below.
public interface com.bea.language.feature.IProjectFeature
The interface all features must provide to the framework.
public interface com.bea.language.feature.ILangTokenUpdateFeature implements com.bea.language.feature.ILangFeature
Provided by languages that want to perform updating of their token sets to changes in real time.
public static interface com.bea.language.feature.ILangTokenUpdateFeature.IContext
Callback interface to the update framework.
public interface com.bea.language.feature.ILangTokenInfoFeature implements com.bea.language.feature.ILangFeature
public interface com.bea.language.feature.ILangStructureFeature implements com.bea.language.feature.ILangFeature
public interface com.bea.language.feature.ILangSourceInfoFeature implements com.bea.language.feature.ILangFeature
public interface com.bea.language.feature.ILangPropertyInfoFeature implements com.bea.language.feature.ILangFeature
public interface com.bea.language.feature.ILangFeature
The interface all language specific features provide.
public static interface com.bea.language.feature.ILangFeature.IContext
The context provided to all language specific features.
public static class com.bea.language.feature.ILangFeature.Context
A static context object used to set and retrieve the context from TLS.
public interface com.bea.language.feature.IFileFeature implements com.bea.language.feature.IProjectFeature
Defines the shape of a feature that pertains to a particular file in the project. These features can maintain state and can lock the state of the file as well.
public static interface com.bea.language.feature.IFileFeature.IContext
Defines the context available to an in-use feature.
Package com.bea.language.fileinfo
This package defines interfaces implemented by compilers that wish to access or manipulate file information. Its classes and interfaces are described below.
public interface com.bea.language.fileinfo.ILangFileResolver
Implemented by compilers that wish to expose their content in the file namespace.
public static interface com.bea.language.fileinfo.ILangFileResolver.IContent
Represents the content of the file. Implementations will probably want to store the content in only one form, but may wish to make it available in other forms uppon request.
public interface com.bea.language.fileinfo.ILangFileCompiler implements com.bea.language.ILangCompiler
Implemented by compilers that wish to participate more fully in the file namespace.
Package com.bea.Ianguage.info
This package defines mutable versions of the compiler info interfaces of com.bea.compiler.info. Its classes and interfaces are described below.
public class com.bea.language.info.LangInfoFactory
Provides access to the factory of info structores.
public interface com.bea.language.info.IScope
Represents a set of defined entities in the source. Note that this allows only for resolution of simple names. Typically, a language will add its own algorithm for resolving multi-part names on top of the scope.
public interface com.bea.languageinfo.IMethodLocation
Represents the location in which the method with the given ID was looked for (taking into account the argument types).
public interface com.bea.languageinfo.ILangVariable
Encapsulates information about a variable defined in the source. This variable can be a local variable, a method parameter, a field of a user type, and so on.
public interface com.bea.language.info.ILangUserType implements com.bea.language.info.ILangReferenceTypeMember
A mutable version of IReferenceType. Note that no mutation should ever be performed after the type is handed to the framework.
public interface com.bea.language.info.ILangReferenceTypeMember implements com.bea.language.info.ILangDeclaredEntity
A mutable version of IReferenceTypeMember.
public interface com.bea.language.info.ILangMethod implements com.bea.language.info.ILangReferenceTypeMember, com.bea.language.info.ILangCallable
A mutable version of IMethod.
public static interface com.bea.language.info.ILangMethod.ISignature
Defines the shape by which methods are said to define the same method.
public interface com.bea.language.info.ILangInfoFactory
Defines the interface for creation of compiler info structures.
For each type of structure that can be created, this provides one “constructor” that takes all of the information at creation time and another that returns a structure with null/default fields that must be filled in afterward.
public interface com.bea.language.info.ILangField implements com.bea.language.info.ILangReferenceTypeMember, com.bea.language.info.ILangVariable
A mutable version of IField.
public interface com.bea.language.info.ILangDeclaredEntity
A mutable version of IReferenceTypeMember.
public interface com.bea.language.info.ILangConstructor implements com.bea.language.info.ILangDeclaredEntity, com.bea.language.info.ILangCallable
A mutable version of IConstructor.
public interface com.bea.language.info.ILangCallable
A mutable version of ICallable.
public interface com.bea.language.info.ILangArrayType implements com.bea.language.info.ILangReferenceTypeMember
Represents a mutable version of array reference types.
public interface com.bea.language.info.ILangArgument
A mutable version of IArgument.
public interface com.bea.language.info.ILangAnnotationSet
Represents a mutable version of the annotation set, which also exposes the fact that the annotations are stored in a tree. Note that the root node of the tree is insignificant.
public interface com.bea.language.info.ILangAnnotation
Represents a mutable version of annotations. This version also exposes the fact that the annotations are arranged into a tree, which has links between siblings and from the parent to the first child.
public interface com.bea.language.info.ILangAmbiguous
Represents a member of a reference type that is ambiguous. For fields and types, this means that the type inheritted two entities with the same name. For methods, this means that the type inheritted two methods with the same signature. In the case of methods, this is not ever an error.
Provides methods for creating implementations of IConstant.
public interface com.bea.language.info.IConstant
Records the constant value of a field or expression in the source. This interface allows implementations to compute the values on demand. This can improve performance as computing the value of some constants (strings) can be very expensive.
public class com.bea.language.info.ConstantFactory
Provides access to the singleton constant factory.
Package com.bea.language.java
This package defines how the Java language implementation can be extended to create support for other languages based on Java and its annotations. Its classes and interfaces are described below.
public class com.bea.language.java.TransformSymbol
public class com.bea.language.java.JavaLanguageFactory
Contains the reference to the template instance of the Java language.
public class com.bea.language.java.JavaFeatureContext
Provides access to the implementation of IJavaFeatureContext.
public class com.bea.language.java.JavaContext
Provides access to the implementation of IJavaContext.
public interface com.bea.language.java.IJavaStructureNode
public static interface com.bea.language.java.IJavaStructureNodennit implements com.bea.languagejava.IJavaStructureNode
public static interface com.bea.languagejava.IJavaStructureNode.IPackage implements com.bea.languagejava.IJavaStructureNode
public static interface com.bea.languagejava.IJavaStructureNode.IImport implements com.bea.languagejava.IJavaStructureNode
public static interface com.bea.language.java.IJavaStructureNode.IClass implements com.bea.languagejava.IJavaStructureNode
public static interface com.bea.language.java.IJavaStructureNode.IMethod implements com.bea.language.java.IJavaStructureNode
public static interface com.bea.language.java.IJavaStructureNode.IField implements com.bea.language.java.IJavaStructureNode
public static interface com.bea.language.java.IJavaStructureNode.IParameter implements com.bea.language.java.IJavaStructureNode
public static interface com.bea.language.java.IJavaStructureNode.IModifiers implements com.bea.language.java.IJavaStructureNode
public static interface com.bea.language.java.IJavaStructureNode.IComment implements com.bea.languagejava.IJavaStructureNode
public static interface com.bea.language.java.IJavaStructureNode.ITag implements com.bea.language.java.IJavaStructureNode
public static interface com.bea.language.java.IJavaStructureNode.IAttribute implements com.bea.language.java.IJavaStructureNode
public interface com.bea.language.java.IJavaResolver
Allows an extender of the Java language to change the compile-time visible shape of the class. To change the run-time shape of the class, implement IJavaGenerator.
Objects are created by the ILangInfoFactory returned by LangInfoFactory.get( ).
Note that while all the methods below are defined in terms of adding new entities, extensions can also modify the entries already present. This should be done with great care, however, as such an operation has a high potential for confusing the (user) programmer.
public interface com.bea.language.java.IJavaLanguageFactory
Defines the shape of the Java language object, which can be cloned in order to create languages based on Java with annotations.
public interface com.bea.language.java.IJavaGenerator
Allows an extender of the Java language to change the run-time shape of the class. To change the compile-time shape of the class, implement IJavaResolver.
Objects are created by the IIRFactory returned by IRFactory.get( ).
Note that while all the methods below are defined in terms of adding new entities, extensions can also modify the entries already present. This should be done with great care, however, as such an operation has a high potential for confusing the (user) programmer.
public interface com.bea.language.java.IJavaFeatureContext
Provides additional context to a Java feature.
public interface com.bea.language.java.IJavaFeature implements com.bea.language.feature.ILangFeature
Defines extra context available to an extend feature of Java.
public static interface com.bea.language.java.IJavaFeature.IContext
Defines the extra context available to this feature.
public interface combea.language.java.IJavaExtension
Defines the way to create extended versions of the Java language.
public interface com.bea.language.java.IJavaContext
Provides additional context to a Java extension.
public interface com.bea.language.java.IJavaChecker
Allows a Java extension to perform further checks on the Java code. Diagnostics can be issued by calling Context.get( ).addDiagnostic( . . . ).
The container will make a depth-first traversal of the entities in the file, giving this extension checker a chance to perform checking on each of the entities found. During this process, the checker will be notified when the traversal is entering a particular type. Just for cleaniness, the container will check a type before it is entered (in theory, any such checking could be done in either startType or endType).
Each declared entity given will be either an IReferenceType, IField, IMethod, or IConstructor. It is not necessary to use instanceof, however, because IDeclaredEntity has methods that can determine what type of entity you have.
public interface com.bea.language.java.IJavaBuilder
Package com.bea.language.schema
This package provides interfaces for building parsers and validity checkers for tree shaped data. Its classes and interfaces are described below.
public class com.bea.language.schema.SchemaFactory
Contains a reference to the singleton instance of the implementation of the ISchemaFactory interface.
public interface com.bea.language.schema.ISimpleType implements com.bea.language.schema.IContentType
Represents a content type that is “simple” in the sense that its value is not parsed beyond tokenization on whitespace. Simple types are further categorized by whether they take their value as an atomic unit (after whitespace is transformed) or as a list of whitespace separated tokens.
public interface com.bea.language.schema.ISimpleOrderedType implements com.bea.language.schema.ISimpleAtomicType
Represents a simple atomic type whose value set can be ordered.
public interface com.bea.language.schema.ISimpleListType implements com.bea.language.schema.ISimpleType
Represents a simple type that takes its value as a whitespace separated list of tokens.
public static interface com.bea.language.schema.ISimpleListType.IListToken
Represents a single token in the list to be compiled.
public interface com.bea.language.schema.ISimpleDecimalType implements com.bea.language.schema.ISimpleOrderedType
Represents an ordered atomic type for decimal numbers.
public interface com.bea.language.schema.ISimpleDateTimeType implements com.bea.language.schema.ISimpleOrderedType
Represents an ordered atomic type for dates and times.
public interface com.bea.language.schema.ISimpleAtomicType implements com.bea.language.schema.ISimpleType
Represents a simple type that takes its value as a single atomic unit, after whitespace has been transformed.
public interface com.bea.language.schema.ISchemaFactory
Contains methods for creating schemas, types, and related objects. Built-in types and grammars are provided to handle (essentially) all of XML Schema and DTD. Note: collections passed in to create*( ) methods are not cloned, so it is caller's responsibility to maintain them.
public static interface com.bea.language.schema.ISchemaFactory.IAttributeOccurance
Provides a specification for how an attribute is allowed to appear in the attribute list of a particular element.
public static interface com.bea.language.schemanchemaFactory.IOccurance
Provides a specification for how an element or group of elements is allowed to appear in the body of a particular element.
public static interface com.bea.language.schernanchemaFactory.IElementOccurance implements com.bea.language.schema.ISchemaFactory.IOccuranee
Provides a specification for how an element is allowed to appear in the body of a particular element.
public static interface com.bea.language.schema.ISchemaFactory.IGroupOccurance implements com.bea.language.schema.ISchemaFactory.IOccurance
Provides a specification for how a group is allowed to appear in the body of a particular element.
public interface com.bea.language.schema.IQualifiedName
Represents a namespace qualified name of an element in the tree.
public interface com.bea.language.schema.ILanguageType implements com.bea.language.schema.IContentType
Represents a content type is parsed and checked as a nested language of the host language.
public interface com.bea.language.schema.IGrammar
Encapsulates the rules about how content and elements can appear in the source. Each instance of the grammar is intended to operate as a finite state machine. (Although it need not be implemented as one.)
The only restriction built into this interface is that it must be possible to determine the schema for the next element given only its name and the names of the previous elements. Hence, a finite state machine is almost always sufficient for describing the grammar.
Information about the sequence of names found is delivered in the requests that are made of the grammar. Whenever content is found, a call is made to getNextContent. Whenever an element is found, a call is made to getNextElement.
public interface com.bea.language.schema.IElementType
Provides information about the legal content of an element.
public interface com.bea.language.schema.IElementSchema
Provides information about the legal shape of an element in the tree.
public interface com.bea.language.schema.IContentType
Provides information about the legal values for “content” in the tree. Content appears as the value of an attribute or in the body of an element.
We separate content types into two varieties: simple and language. The former parses as a string of whitespace separated text and is checked for validity by calling a method. The latter uses its own parser and type checker, which can be completely generic.
public interface com.bea.language.schema.IAttributeSchema
Provides information about the legal shape of an attribute on an element in the tree.
public interface com.bea.language.schema.IAttributeGrammar
Encapsulates the rules about how attributes can appear on a particular element in the tree. As with IGrammar, this grammar is intended to operate as a finite state machine.
Package com.bea.language.transform
This package provides interfaces for building transforming compilers that transform a source language to a target language. Its classes and interfaces are described below.
public class com.bea.language.transform.TransformTargetScanner
Exposes a base level ITransformTargetScanner implementation for use in implementing target language specific versions. This implementation maintains the list of tokens, and implements a simple fake token type for insertion among real tokens gathered from the source language parse.
public static interface com.bea.language.transform.TransformTargetScanner.IBaseTransformTarget Scanner implements com.bea.language.transform.ITransformTargetScanner
public interface com.bea.language.transform.ITransformTargetScanner
An in memory scanner that allows one language to transform its parse tree into a list of tokens for parsing by a target language.
public static interface com.bea.language.transform.ITransformTargetScanner.ITransformToken
Extends IToken to provide text for tokens that did not come from the real source code.
public interface com.bea.language.transform.ITransformSourceScanner
Supports a simple scan of a section of the source file being transformed, returning language native tokens of the target language for use in the transform.
public interface com.bea.language.transform.ILangTransformParser implements com.bea.language.ILangParser
A parser that allows its tokens to be supplied by a transform scanner. ILangTransformCompiler.getParser( ) returns an ILangParser that may be cast to ILangTransformParser.
public interface com.bea.language.transform.ILangTransformLanguage implements com.bea.language.ILangLanguage
Marker interface for a language that returns an ILangTransformCompiler from its getCompiler( ) method.
public interface com.bea.language.transform.ILangTransformCompiler implements com.bea.language.ILangCompiler
ILangTransformLanguage.getCompiler returns an ILangCompiler which may be cast to an ILangTransformCompiler.
Package com.bea.language.typeinfo
This package provides interface for languages that need to access or manipulate type information. Its classes and interfaces are described below.
public interface com.bea.language.typeinfo.ILangTypeNamespace
Exposes additional methods available to languages.
Package com.bea.Ianguage.xscript
This package provides interfaces for accessing and manipulating XScript code (JavaScript with native XML support). Its classes and interfaces are described below.
public class com.bea.language.xscript.XScriptLanguageFactory
Contains the reference to the template instance of the Java language.
public interface com.bea.language.xscript.IXScriptLanguageFactory
Defines the shape of the XScript language object, which can be cloned in order to create languages based on XScript with annotations.
public interface com.bea.language.xscript.IXSCodeBlock
The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to one of ordinary skill in the art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalence.
The present application claims the benefit of priority under 35 U.S.C. §119(e) to U.S. Provisional Patent Application entitled “SYSTEMS AND METHODS FOR TYPE INDEPENDENT SOURCE CODE EDITING”, Application No. 60/449,984, filed on Feb. 26, 2003, which application is incorporated herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
5321841 | East et al. | Jun 1994 | A |
5469562 | Saether | Nov 1995 | A |
5604860 | McLaughlin | Feb 1997 | A |
5630131 | Palevich | May 1997 | A |
5748975 | Van De Vanter | May 1998 | A |
5801958 | Dangelo et al. | Sep 1998 | A |
5835769 | Jervis et al. | Nov 1998 | A |
5836014 | Faiman | Nov 1998 | A |
5867822 | Sankar | Feb 1999 | A |
5944794 | Okamoto | Aug 1999 | A |
5961593 | Gabber et al. | Oct 1999 | A |
5966535 | Benedikt et al. | Oct 1999 | A |
6012083 | Savitzky | Jan 2000 | A |
6016495 | McKeehan | Jan 2000 | A |
6018730 | Nichols | Jan 2000 | A |
6023578 | Birsan | Feb 2000 | A |
6028997 | Leymann et al. | Feb 2000 | A |
6029000 | Woolsey et al. | Feb 2000 | A |
6044217 | Brealey et al. | Mar 2000 | A |
6067623 | Blakley, III et al. | May 2000 | A |
6070184 | Blount | May 2000 | A |
6092102 | Wagner | Jul 2000 | A |
6119149 | Notani | Sep 2000 | A |
6141701 | Whitney | Oct 2000 | A |
6148336 | Thomas | Nov 2000 | A |
6185734 | Saboff | Feb 2001 | B1 |
6212546 | Starkovich | Apr 2001 | B1 |
6222533 | Notani | Apr 2001 | B1 |
6226675 | Meltzer et al. | May 2001 | B1 |
6230287 | Pinard et al. | May 2001 | B1 |
6230309 | Turner | May 2001 | B1 |
6237135 | Timbol | May 2001 | B1 |
6243737 | Flanagan | Jun 2001 | B1 |
6292932 | Baisley | Sep 2001 | B1 |
6311327 | O'Brien | Oct 2001 | B1 |
6330569 | Baisley | Dec 2001 | B1 |
6334114 | Jacobs | Dec 2001 | B1 |
6338064 | Ault et al. | Jan 2002 | B1 |
6343265 | Glebov | Jan 2002 | B1 |
6353923 | Bogle et al. | Mar 2002 | B1 |
6360358 | Elsbree | Mar 2002 | B1 |
6367068 | Vaidyanathan et al. | Apr 2002 | B1 |
6377939 | Young | Apr 2002 | B1 |
6408311 | Baisley | Jun 2002 | B1 |
6411698 | Bauer | Jun 2002 | B1 |
6445711 | Scheel | Sep 2002 | B1 |
6470364 | Prinzing | Oct 2002 | B1 |
6516322 | Meredith | Feb 2003 | B1 |
6560769 | Moore | May 2003 | B1 |
6567738 | Gopp | May 2003 | B2 |
6584454 | Hummel | Jun 2003 | B1 |
6594693 | Borwankar | Jul 2003 | B1 |
6594700 | Graham | Jul 2003 | B1 |
6601113 | Koistinen | Jul 2003 | B1 |
6604198 | Beckman et al. | Aug 2003 | B1 |
6609115 | Mehring | Aug 2003 | B1 |
6615258 | Barry | Sep 2003 | B1 |
6636491 | Kari | Oct 2003 | B1 |
6637020 | Hammond | Oct 2003 | B1 |
6643652 | Helgeson | Nov 2003 | B2 |
6654932 | Bahrs | Nov 2003 | B1 |
6662357 | Bowman-Amuah | Dec 2003 | B1 |
6678518 | Eerola | Jan 2004 | B2 |
6684388 | Gupta | Jan 2004 | B1 |
6687702 | Vaitheeswaran | Feb 2004 | B2 |
6687848 | Najmi | Feb 2004 | B1 |
6721740 | Skinner | Apr 2004 | B1 |
6721779 | Maffeis | Apr 2004 | B1 |
6732237 | Jacobs et al. | May 2004 | B1 |
6748420 | Quatrano | Jun 2004 | B1 |
6754884 | Lucas | Jun 2004 | B1 |
6757689 | Battas | Jun 2004 | B2 |
6789054 | Makhlouf | Sep 2004 | B1 |
6795967 | Evans et al. | Sep 2004 | B1 |
6799718 | Chan | Oct 2004 | B2 |
6802000 | Greene et al. | Oct 2004 | B1 |
6804686 | Stone et al. | Oct 2004 | B1 |
6823495 | Vedula | Nov 2004 | B1 |
6832238 | Sharma | Dec 2004 | B1 |
6836883 | Abrams et al. | Dec 2004 | B1 |
6847981 | Song et al. | Jan 2005 | B2 |
6850979 | Saulpaugh | Feb 2005 | B1 |
6859180 | Rivera | Feb 2005 | B1 |
6874143 | Murray | Mar 2005 | B1 |
6889244 | Gaither | May 2005 | B1 |
6915519 | Williamson | Jul 2005 | B2 |
6918084 | Slaughter | Jul 2005 | B1 |
6922827 | Vasilik | Jul 2005 | B2 |
6948150 | Pepin | Sep 2005 | B1 |
6950872 | Todd, II | Sep 2005 | B2 |
6959307 | Apte | Oct 2005 | B2 |
6963914 | Breitbart | Nov 2005 | B1 |
6971096 | Ankireddipally | Nov 2005 | B1 |
6976086 | Sadeghi | Dec 2005 | B2 |
7000219 | Barrett | Feb 2006 | B2 |
7017146 | Dellarocas | Mar 2006 | B2 |
7043722 | Bau, III | May 2006 | B2 |
7047530 | Lu | May 2006 | B2 |
7051072 | Stewart | May 2006 | B2 |
7051316 | Charisius | May 2006 | B2 |
7054858 | Sutherland | May 2006 | B2 |
7062718 | Kodosky | Jun 2006 | B2 |
7069507 | Alcazar | Jun 2006 | B1 |
7072934 | Helgeson | Jul 2006 | B2 |
7073167 | Iwashita | Jul 2006 | B2 |
7076772 | Zatloukal | Jul 2006 | B2 |
7089584 | Sharma | Aug 2006 | B1 |
7096422 | Rothschiller | Aug 2006 | B2 |
7107578 | Alpern | Sep 2006 | B1 |
7111243 | Ballard | Sep 2006 | B1 |
7117504 | Smith | Oct 2006 | B2 |
7127704 | Van De Vanter et al. | Oct 2006 | B2 |
7143186 | Stewart | Nov 2006 | B2 |
7146422 | Marlatt | Dec 2006 | B1 |
7155705 | Hershberg | Dec 2006 | B1 |
7165041 | Guheen | Jan 2007 | B1 |
7181731 | Pace | Feb 2007 | B2 |
7184967 | Mital | Feb 2007 | B1 |
7240331 | Vion-Dury | Jul 2007 | B2 |
7260599 | Bauch | Aug 2007 | B2 |
7260818 | Iterum | Aug 2007 | B1 |
7283991 | Kimmerly | Oct 2007 | B1 |
20020004848 | Sudarshan | Jan 2002 | A1 |
20020010781 | Tuatini | Jan 2002 | A1 |
20020010803 | Oberstein | Jan 2002 | A1 |
20020016759 | Macready et al. | Feb 2002 | A1 |
20020035604 | Cohen | Mar 2002 | A1 |
20020049788 | Lipkin | Apr 2002 | A1 |
20020073236 | Helgeson | Jun 2002 | A1 |
20020073396 | Crupi | Jun 2002 | A1 |
20020078365 | Burnett et al. | Jun 2002 | A1 |
20020083075 | Brummel | Jun 2002 | A1 |
20020111922 | Young | Aug 2002 | A1 |
20020116454 | Dyla | Aug 2002 | A1 |
20020120685 | Srivastava | Aug 2002 | A1 |
20020143960 | Goren | Oct 2002 | A1 |
20020152106 | Stoxen | Oct 2002 | A1 |
20020161826 | Arteaga | Oct 2002 | A1 |
20020165936 | Alston et al. | Nov 2002 | A1 |
20020169644 | Greene | Nov 2002 | A1 |
20020174178 | Stawikowski | Nov 2002 | A1 |
20020174241 | Beged-Dov | Nov 2002 | A1 |
20020184610 | Chong | Dec 2002 | A1 |
20020188486 | Gil | Dec 2002 | A1 |
20020194244 | Raventos | Dec 2002 | A1 |
20020194267 | Flesner | Dec 2002 | A1 |
20020194495 | Gladstone | Dec 2002 | A1 |
20030004746 | Kheirolomoom | Jan 2003 | A1 |
20030005181 | Bau et al. | Jan 2003 | A1 |
20030014439 | Boughannam | Jan 2003 | A1 |
20030018661 | Darugar | Jan 2003 | A1 |
20030018665 | Dovin et al. | Jan 2003 | A1 |
20030018832 | Amirisetty | Jan 2003 | A1 |
20030018963 | Ashworth | Jan 2003 | A1 |
20030023957 | Bau | Jan 2003 | A1 |
20030028364 | Chan | Feb 2003 | A1 |
20030028579 | Kulkarni | Feb 2003 | A1 |
20030041198 | Exton et al. | Feb 2003 | A1 |
20030043191 | Tinsley | Mar 2003 | A1 |
20030046591 | Asghari-Kamrani | Mar 2003 | A1 |
20030051066 | Pace | Mar 2003 | A1 |
20030055868 | Fletcher | Mar 2003 | A1 |
20030055878 | Fletcher | Mar 2003 | A1 |
20030074217 | Beisiegel | Apr 2003 | A1 |
20030079029 | Garimella | Apr 2003 | A1 |
20030084203 | Yoshida | May 2003 | A1 |
20030110117 | Saidenberg et al. | Jun 2003 | A1 |
20030110446 | Nemer | Jun 2003 | A1 |
20030126136 | Omoigui | Jul 2003 | A1 |
20030149791 | Kane | Aug 2003 | A1 |
20030167358 | Marvin | Sep 2003 | A1 |
20030196168 | Hu | Oct 2003 | A1 |
20040003335 | Gertz et al. | Jan 2004 | A1 |
20040019645 | Goodman | Jan 2004 | A1 |
20040040011 | Bosworth | Feb 2004 | A1 |
20040078373 | Ghoneimy | Apr 2004 | A1 |
20040103406 | Patel | May 2004 | A1 |
20040133660 | Junghuber et al. | Jul 2004 | A1 |
20040148336 | Hubbard | Jul 2004 | A1 |
20040204976 | Oyama | Oct 2004 | A1 |
20040216086 | Bau | Oct 2004 | A1 |
20040225995 | Marvin et al. | Nov 2004 | A1 |
20040260715 | Mongeon | Dec 2004 | A1 |
20050050068 | Vaschillo | Mar 2005 | A1 |
20050278585 | Spencer | Dec 2005 | A1 |
20060206856 | Breeden et al. | Sep 2006 | A1 |
20060234678 | Juitt | Oct 2006 | A1 |
20070038500 | Hammitt | Feb 2007 | A1 |
Number | Date | Country |
---|---|---|
2 248 634 | Mar 2000 | CA |
WO 9923558 | May 1999 | WO |
WO 0029924 | May 2000 | WO |
Number | Date | Country | |
---|---|---|---|
20050114771 A1 | May 2005 | US |
Number | Date | Country | |
---|---|---|---|
60449984 | Feb 2003 | US |