Generic Languages Framework (Project Schliemann)


  1. Create support for editing major scripting languages (JavaScript, PHP, ...)
  2. Add basic support for 100+ languages to NetBeans: Editors like Emacs and JEdit contain basic support (syntax coloring, code folding, indentation) for many languages. Languages are not hardcoded, but they have some generic language support. We need something like this too. Adding basic support for a language to NetBeans should be simple and fast.


The Schliemann project allows you to define a programming language and integrate it to NetBeans IDE. In the first step you should describe the language - lexical part (define tokens using regular expressions) and syntax (grammar rules). In the second step you can define how to visualize this language in NetBeans. You can define colors for tokens (syntax coloring) or folding (based on grammar rules). You can define what parts of this language should be displayed in the navigator, and how to indent this language plus many other features.

It is not an easy solution to all problems, of course. It does not mean that you can use this project to have the best C++ support in several weeks. This project can help you write basic (but feature rich) support for languages. It's not meant to be a first line IDE interface. There are important limitations.

Constraints, Limitations.

  1. Its not a compiler. You can not implement a build / run / debug / project support base on the Schlieamann engine.
  2. Schliemann supports the first two parts of compilation only - lexical and syntax analysis. There is no support for semantic analysis. It means there is no special support for features such as refactoring, semantic based code completion, find usages etc. But you can implement some semantic analysis based on Schliemann output (Parse Tree).

Why Schliemann?

The current NetBeans API is very powerful, and it allows you to create language support for any programming language. But it has some important limitations:

  1. Creating basic support for some new language is not easy. You must learn many APIs (Modules API, FileSystems API, Actions API, WindowSystem API, Options Dialog API, Nodes API, Navigator API, Dailogs API, Editor API, CodeFolding API, MimeLookup API, Editor Settings API, ... there are hundreds of classes - really!). That's why we have no support for many languages. It's simply too difficult for external contributors, and too time consuming for us. A new user needs a month or two to create even basic syntax coloring for a language.
  2. Current support does not scale. Each language support contains hundreds of classes, thousands of instances, many listeners, and big layer files that must be managed. Having support for 100 languages in NetBeans is problematic in this case. Each new language support slows down startup. IDE performance is influenced by numbers of listeners (on TopComponent, on various Lookups), actions and objects registered in layers. It's not meant as a critique. We definitely need such first line Java based APIs for first line feature rich language support. The Schliemann engine will never have such power.

Thats why we need a second way to write language support, I think. It should allow "doing easy things easily". One simple API covering the most used features. This second level language support should run in some "interpreted" mode. It means there are no special classes for each language and for each feature. The language definition language should be the same or as similair as possible to some standards - like antLR and JavaCC.

Competition, similar projects.

There are some similar engines like Schliemann. Many programmers editors have similar support, for example Emacs, vi or JEdit. But they typically implement basic features only (syntax coloring, indentation, code folding). They have some proprietary way to define lexical analysis and they have no syntax analyzers.

Parser compilers like AntLR or JavaCC do not contain support for IDEs. It's not possible to use them in interpreted mode, and there are other reasons why we can not use them in the Schliemann engine. They are not incremental, and they have weak support for error recovery. But they define standards to describe programming languages. That's why we should use the same or similar format.

Eclipse and Idea IDEs contains feature rich support for many programming languages.

See also: Generic Scripting Framework

About the name

Why the name Schliemann, you ask? Well, I did. My best guess, and if you chose the name and know for sure please correct me, is it is based on this Wikipedia page about Heinrich Schliemann which states:

...[Schliemann] used his entire life to learn languages -- Schliemann wrote
his diary in the language of whatever country he happened to be in.

Schliemann had a gift for languages and by the end of his life he was conversant
in English, French, Dutch, Spanish, Portuguese, Swedish, Italian, Greek, Latin,
Russian, Arabic and Turkish as well as his native German. Schliemann's ability
with languages was an important part of his career as a businessman in the
importing trade.

So it seems the name for a project designed to be able to support any language was based on a man who seemed to be able to learn just about any language. I like it :-).


Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo