1C のテクノロジー プラットフォームとしての Eclipse: エンタープライズ開発ツール

おそらく Eclipse 特別な紹介は不要になって久しいです。 Eclipse Java 開発ツール (JDT）。 ほとんどの開発者が「Eclipse」という言葉から連想するのは、この人気のあるオープンソース Java IDE です。 ただし、Eclipse は、開発ツールを統合するための拡張可能なプラットフォーム (Eclipse プラットフォーム) であり、JDT など、そのベースに基づいて構築された多数の IDE でもあります。 Eclipse は、Eclipse プラットフォームと JDT の開発を調整するトップレベルのプロジェクトである Eclipse プロジェクトと、その開発の成果物である Eclipse SDK の両方です。 最後に、Eclipse はプロジェクトの巨大なコミュニティを持つオープンソースの財団ですが、そのすべてが Java で書かれているわけではなく、開発ツール (プロジェクトなど) に関連しているわけではありません。 エクリプス IoT и 日食の科学）。 Eclipse の世界は非常に多様です。

この記事は本質的に概要であり、統合開発ツールを構築するためのプラットフォームとしての Eclipse アーキテクチャの基本のいくつかを検討し、テクノロジーの基盤を形成する Eclipse コンポーネントの最初のアイデアを示します。 「新しいコンフィギュレーター」のプラットフォーム 1C: Enterprise。 1C:エンタープライズ開発ツール。 もちろん、対象読者として Eclipse 開発者のみに焦点を当てているわけではないことも含め、そのようなレビューは必然的に大部分が表面的でかなり限定的なものになるでしょう。 ただし、経験豊富な Eclipse 開発者であっても、この記事で興味深い情報を見つけることができることを願っています。 たとえば、比較的新しく、あまり知られていないプロジェクトである「Eclipse の秘密」の XNUMX つについて説明します。 Eclipseハンドラー、1Cによって設立され、サポートされています。

Eclipse アーキテクチャの概要

まず、例を使用して Eclipse アーキテクチャの一般的な側面をいくつか見てみましょう。 Eclipse Java 開発ツール (JDT)。 例として JDT を選択したのは偶然ではありません。 これは、Eclipse に登場した最初の統合開発環境です。 Eclipse C/C++ Development Tooling (CDT) などの他の *DT Eclipse プロジェクトは後に作成され、基本的なアーキテクチャ原則と個々のソース コード フラグメントの両方を JDT から借用しています。 JDT で定められたアーキテクチャの基本は、1C:Enterprise Development Tools を含む、Eclipse プラットフォーム上に構築されたほぼすべての IDE に今日でも関連しています。

まず第一に、Eclipse は、特定のプログラミング言語をサポートするように設計された機能から言語に依存しない機能が分離され、UI に依存しない「コア」コンポーネントが関連するコンポーネントから分離される、かなり明確なアーキテクチャの階層構造によって特徴づけられることに注意する必要があります。ユーザーインターフェイスをサポートします。

したがって、Eclipse プラットフォームは言語に依存しない共通のインフラストラクチャを定義し、Java 開発ツールはフル機能の Java IDE を Eclipse に追加します。 Eclipse プラットフォームと JDT はどちらもいくつかのコンポーネントで構成されており、それぞれが UI に依存しない「コア」または UI レイヤーに属します (図 1)。

米。 1. EclipseプラットフォームとJDT

Eclipse プラットフォームの主なコンポーネントをリストしてみましょう。

• ランタイム — プラグインのインフラストラクチャを定義します。 Eclipse はモジュール式アーキテクチャーを特徴としています。 基本的に、Eclipse は「拡張ポイント」と「拡張機能」のコレクションです。
• — XNUMX つ以上のプロジェクトを管理します。 プロジェクトは、ファイル システムに直接マップされるフォルダーとファイルで構成されます。
• 標準ウィジェット ツールキット (SWT) - オペレーティング システムと統合された基本的なユーザー インターフェイス要素を提供します。
• ジェイフェイス — SWT 上に構築された多数の UI フレームワークを提供します。
• ワークベンチ — Eclipse UI パラダイム (エディター、ビュー、パースペクティブ) を定義します。

Eclipse プラットフォームは、デバッグ、比較、検索、チームなど、統合開発ツールを構築するための他の多くの便利なコンポーネントも提供していると言わなければなりません。 ソース コードの「スマート エディター」を構築するための基礎である JFace Text については、特に言及する必要があります。 残念ながら、この記事の範囲内では、これらのコンポーネントや UI レイヤー コンポーネントをざっと調べることさえできません。そのため、このセクションの残りの部分では、UI レイヤー コンポーネントの主要な「コア」コンポーネントの概要に限定して説明します。 Eclipse プラットフォームと JDT。

コアランタイム

Eclipse プラグイン インフラストラクチャは以下に基づいています。 OSGi そしてプロジェクトによって提供される 日食春分点。 各 Eclipse プラグインは OSGi バンドルです。 OSGi 仕様では、特に、バージョン管理と依存関係の解決のメカニズムが定義されています。 これらの標準メカニズムに加えて、Equinox では次の概念が導入されています。 拡張ポイント。 各プラグインは独自の拡張ポイントを定義でき、同じまたは他のプラグインによって定義された拡張ポイントを使用してシステムに追加機能 (「拡張機能」) を導入することもできます。 OSGi および Equinox メカニズムの詳細な説明は、この記事の範囲を超えています。 Eclipse のモジュール化は完全なものであり (ランタイムを含むサブシステムは XNUMX つ以上のプラグインで構成されます)、Eclipse のほぼすべてが拡張機能であることに注意してください。 さらに、これらの原則は、OSGi が導入されるずっと前に Eclipse アーキテクチャに組み込まれていました (当時、OSGi によく似た独自のテクノロジが使用されていました)。

コアワークスペース

Eclipse プラットフォーム上に構築されたほぼすべての統合開発環境は、Eclipse ワークスペースで動作します。 通常、IDE で開発されたアプリケーションのソース コードが含まれるワークスペースです。 ワークスペースはファイル システムに直接マップされ、フォルダーとファイルを含むプロジェクトで構成されます。 これらのプロジェクト、フォルダー、ファイルは次のように呼ばれます。 資源 ワークスペース。 Eclipse のワークスペース実装は、ファイル システムに関連するキャッシュとして機能するため、リソース ツリーのトラバースを大幅に高速化できます。 さらに、ワークスペースは、次のような多くの追加サービスを提供します。 リソース変更の通知メカニズム и インクリメンタルビルダーインフラストラクチャ.

Core Resources コンポーネント (org.eclipse.core.resources プラグイン) は、ワークスペースとそのリソースのサポートを担当します。 特に、このコンポーネントは、次の形式でワークスペースへのプログラムによるアクセスを提供します。 リソースモデル。 このモデルを効果的に使用するには、クライアントはリソースへのリンクを提示する簡単な方法が必要です。 この場合、モデル内のリソースの状態を直接保存するオブジェクトをクライアント アクセスから隠すことが望ましいでしょう。 そうしないと、たとえばファイルを削除する場合、クライアントはモデル内に存在しないオブジェクトを保持し続ける可能性があり、その後問題が発生します。 Eclipse は、と呼ばれるものを使用してこの問題を解決します。 ハンドル リソース。 ハンドルはキーとして機能し (ワークスペース内のリソースへのパスのみを知っています)、リソースの状態に関する情報を直接保存する内部モデル オブジェクトへのアクセスを完全に制御します。 このデザインはパターンのバリエーションです ハンドル・本体.

米。 図 2 は、リソース モデルに適用されたハンドル/ボディ イディオムを示しています。 IResource インターフェイスはリソースのハンドルを表し、API ではありませんが、このインターフェイスを実装する Resource クラスや本体を表す ResourceInfo クラスとは異なり、API です。 ハンドルはワークスペース ルートを基準としたリソースへのパスのみを認識しており、リソース情報へのリンクは含まれていないことを強調します。 リソース情報オブジェクトは、いわゆる「要素ツリー」を形成します。 このデータ構造は完全にメモリ内に具体化されます。 ハンドルに対応するリソース情報インスタンスを見つけるには、そのハンドルに格納されているパスに従って要素ツリーをたどります。

米。 2. IResource と ResourceInfo

後で説明するように、リソース モデルの基本設計 (ハンドルベースと呼ぶこともできます) は、Eclipse の他のモデルにも使用されます。 ここでは、この設計の特徴的な特性をいくつか挙げてみましょう。

• ハンドルは値オブジェクトです。 値オブジェクトは、その等価性がアイデンティティに基づいていない不変オブジェクトです。 このようなオブジェクトは、ハッシュされたコンテナーのキーとして安全に使用できます。 ハンドルの複数のインスタンスが同じリソースを参照できます。 それらを比較するには、equals(Object) メソッドを使用する必要があります。
• ハンドルはリソースの動作を定義しますが、リソースの状態に関する情報は含まれません (ハンドルに格納される唯一のデータは、リソースへのパスである「キー」です)。
• ハンドルは、存在しないリソース (まだ作成されていないリソース、またはすでに削除されたリソース) を参照している可能性があります。 リソースの存在は、IResource.exists() メソッドを使用して確認できます。
• 一部の操作は、ハンドル自体に保存されている情報のみに基づいて実装できます (いわゆるハンドル専用操作)。 例としては、IResource.getParent()、getFullPath() などがあります。 このような操作を成功させるために、リソースが存在する必要はありません。 成功するためにリソースが存在する必要がある操作は、リソースが存在しない場合に CoreException をスローします。

Eclipse は、ワークスペース リソースの変更を通知するための効率的なメカニズムを提供します (図 3)。 リソースは、Eclipse IDE 自体内で実行されたアクションの結果として、またはファイル システムとの同期の結果として変更される可能性があります。 どちらの場合も、通知を購読しているクライアントには、変更に関する詳細情報が「リソース デルタ」の形式で提供されます。 デルタは、ワークスペース リソース (サブ) ツリーの XNUMX つの状態間の変更を記述し、それ自体がツリーです。各ノードはリソースへの変更を記述し、子リソースへの変更を記述する次のレベルのデルタのリストを含みます。

米。 3. IResourceChangeEvent と IResourceDelta

リソース デルタに基づく通知メカニズムには次の特徴があります。

• デルタは再帰的合成の原理を使用して構築されるため、単一の変更と多数の変更は同じ構造を使用して記述されます。 サブスクライバ クライアントは、デルタのツリーを介した再帰降下を使用してリソース変更通知を処理できます。
• デルタには、リソースの移動やそれに関連付けられた「マーカー」の変更 (たとえば、コンパイル エラーはマーカーとして表されます) など、リソースへの変更に関する完全な情報が含まれています。
• リソース参照はハンドルを通じて行われるため、delta はリモート リソースを自然に参照できます。

すぐにわかるように、リソース モデル変更通知メカニズムの設計の主要コンポーネントは、他のハンドルベースのモデルにも関連します。

JDTコア

Eclipse ワークスペース リソース モデルは、言語に依存しない基本的なモデルです。 JDT コア コンポーネント (プラグイン org.eclipse.jdt.core) は、Java の観点からワークスペース構造をナビゲートおよび分析するための API、いわゆる「Java モデル」(Javaモデル）。 この API は、フォルダーとファイルの観点から定義される基礎となるリソース モデル API とは対照的に、Java 要素の観点から定義されます。 Java 要素ツリーの主なインターフェイスを図に示します。 4.

米。 4. Java モデル要素

Java モデルは、リソース モデルと同じハンドル/ボディ イディオムを使用します (図 5)。 IJavaElement はハンドルであり、JavaElementInfo は本体の役割を果たします。 IJavaElement インターフェイスは、すべての Java 要素に共通のプロトコルを定義します。 そのメソッドの一部はハンドル専用です: getElementName()、getParent() など。 JavaElementInfo オブジェクトには、対応する要素の状態、つまりその構造と属性が格納されます。

米。 5. IJavaElement と JavaElementInfo

Java モデルには、リソース モデルと比較して、基本的なハンドル/ボディ設計の実装にいくつかの違いがあります。 上で述べたように、リソース モデルでは、ノードがリソース情報オブジェクトである要素ツリーは完全にメモリ内に含まれます。 ただし、Java モデルは、.java および .class ファイルの内部構造 (型、フィールド、メソッド) も表すため、リソース ツリーよりもはるかに多くの要素を含めることができます。

メモリ内の要素のツリー全体が完全に具体化されることを避けるために、Java モデルの実装では、要素情報の制限されたサイズの LRU キャッシュが使用されます。ここで、キーはハンドル IJavaElement です。 要素情報オブジェクトは、要素ツリーがナビゲートされるときにオンデマンドで作成されます。 この場合、最も使用頻度の低い項目がキャッシュから削除され、モデルのメモリ消費量は指定されたキャッシュ サイズに制限されたままになります。 これはハンドルベースの設計のもう XNUMX つの利点であり、そのような実装の詳細がクライアント コードから完全に隠蔽されます。

Java 要素への変更を通知するメカニズムは、一般に、上で説明したワークスペース リソースへの変更を追跡するメカニズムと似ています。 Java モデルの変更を監視したいクライアントは、IJavaElementDelta を含む ElementChangedEvent オブジェクトとして表される通知をサブスクライブします (図 6)。

米。 6. ElementChangedEvent と IJavaElementDelta

Java モデルにはメソッド本体や名前解決に関する情報が含まれていないため、Java で記述されたコードの詳細な分析のために、JDT コアは追加の (ハンドルベースではない) モデルを提供します。 抽象構文ツリー (抽象構文ツリー、AST)。 AST はソーステキストを解析した結果を表します。 AST ノードは、ソース モジュールの構造の要素 (宣言、演算子、式など) に対応し、ソース テキスト内の対応する要素の座標に関する情報と、(オプションとして) 名前解決に関する情報が含まれています。いわゆるへのリンクの形式 バインディング。 バインディングは、コンパイラに認識される、型、メソッド、変数などの名前付きエンティティを表すオブジェクトです。 ツリーを形成する AST ノードとは異なり、バインディングは相互参照をサポートし、通常はグラフを形成します。 抽象クラス ASTNode は、すべての AST ノードの共通の基本クラスです。 ASTNode サブクラスは、Java 言語の特定の構文構造に対応します。

構文ツリーは大量のメモリを消費する可能性があるため、JDT はアクティブなエディタに対して XNUMX つの AST のみをキャッシュします。 Java モデルとは異なり、AST は通常、「中間」の「一時的な」モデルとみなされ、そのメンバーは、AST の作成につながった操作のコンテキスト外でクライアントによって参照されるべきではありません。

リストされている XNUMX つのモデル (Java モデル、AST、バインディング) は、JDT で「インテリジェントな開発ツール」を構築するための基礎を形成します。これには、さまざまな「ヘルパー」を備えた強力な Java エディタ、ソース コードを処理するためのさまざまなアクション (インポート リストの整理など) が含まれます。カスタマイズされたスタイルに従った名前と書式設定)、検索およびリファクタリング ツール。 この場合、Java モデルは、開発中のアプリケーションの構造を視覚的に表現するための基礎として使用されるため、特別な役割を果たします (たとえば、パッケージ エクスプローラー、アウトライン、検索、呼び出し階層など)。タイプ階層)。

1C:Enterprise Developments Tools で使用される Eclipse コンポーネント

図では、 図 7 は、1C:Enterprise Development Tools のテクノロジー プラットフォームの基盤を形成する Eclipse コンポーネントを示しています。

米。 7. 1C:エンタープライズ開発ツールのプラットフォームとしての Eclipse

エクリプスプラットフォーム 基本的なインフラストラクチャを提供します。 前のセクションでは、このインフラストラクチャのいくつかの側面について説明しました。

Eclipse モデリング フレームワーク (EMF) は、構造化データをモデル化する一般的な手段を提供します。 EMF は Eclipse プラットフォームに統合されていますが、通常の Java アプリケーションで個別に使用することもできます。 多くの場合、新しい Eclipse 開発者は、Eclipse プラットフォームの複雑さをまだ完全には理解していませんが、すでに EMF に精通しています。 このような当然の人気の理由の XNUMX つは、ユニバーサル デザインです。これには、特に、統合されたメタレベル API が含まれており、これにより、一般的な方法であらゆる EMF モデルを操作できます。 EMF が提供するモデル オブジェクトの基本実装と、メタモデルに基づいてモデル コードを生成するサブシステムにより、開発速度が大幅に向上し、エラーの数が減少します。 EMF には、モデルのシリアル化、モデルへの変更の追跡などのためのメカニズムも含まれています。

真の汎用ツールと同様に、EMF は幅広いモデリング問題の解決に適していますが、一部のクラスのモデル (たとえば、上で説明したハンドルベースのモデル) では、より特殊なモデリング ツールが必要になる場合があります。 EMF について話すことは、特に XNUMX つの記事の限られた範囲内で、ありがたい仕事です。なぜなら、これは別の本の主題であり、かなり分厚い本だからです。 EMF の基礎となる一般化の質の高いシステムにより、モデリングに特化したさまざまなプロジェクトの誕生が可能になり、それらはトップレベル プロジェクトに含まれることに注意してください。 日食モデリング EMF自体も同様です。 そのようなプロジェクトの XNUMX つが Eclipse Xtext です。

Eclipse Xtext 「テキスト モデリング」インフラストラクチャを提供します。 Xtext は使用します アントラー ソース テキストと EMF を解析して結果の ASG (抽象セマンティック グラフ、本質的に AST とバインディングの組み合わせ) を表現するためのもので、「セマンティック モデル」とも呼ばれます。 Xtext によってモデル化された言語の文法は、Xtext 独自の言語で記述されます。 これにより、ANTLR の文法記述を生成できるだけでなく、AST シリアル化メカニズム (つまり、Xtext はパーサーとアンパーサーの両方を提供します)、コンテキスト ヒント、およびその他の多数の言語コンポーネントを取得することもできます。 一方、Xtext で使用される文法言語は、たとえば ANTLR で使用される文法言語ほど柔軟性がありません。 したがって、実装された言語を Xtext に「曲げる」必要がある場合があります。これは、ゼロから開発される言語について話している場合には通常問題になりませんが、すでに確立された構文を持つ言語では受け入れられない場合があります。 それにもかかわらず、Xtext は現在、プログラミング言語とその開発ツールを構築するための Eclipse の中で最も成熟し、機能が豊富で多用途なツールです。 特に、ラピッドプロトタイピングに最適なツールです。 ドメイン固有言語 (ドメイン固有言語、DSL)。 前述の ANTLR と EMF に基づく「言語コア」に加えて、Xtext は、インデックス作成メカニズム、増分構築、「スマート エディター」などを含む多くの便利な高レベル コンポーネントを提供しますが、ハンドルは省略されています。ベースの言語モデル。 EMF と同様に、Xtext も別の本に値する主題であり、現時点ではそのすべての機能について簡単に話すことすらできません。

1C:エンタープライズ開発ツールは、EMF 自体と他の多くの Eclipse モデリング プロジェクトの両方を積極的に使用します。 特に、Xtext は、組み込みプログラミング言語やクエリ言語などの 1C:Enterprise 言語の開発ツールの基盤の XNUMX つです。 これらの開発ツールのもう XNUMX つの基盤は、Eclipse Handly プロジェクトです。これについては後で詳しく説明します (リストされている Eclipse コンポーネントの中で、まだ最も知られていません)。

Eclipseハンドラーは、Eclipse Technology のトップレベル プロジェクトのサブプロジェクトであり、1 年に 2014C によって Eclipse Foundation に行われた最初のコード寄稿の結果として誕生しました。 それ以来、1C はプロジェクトの開発をサポートし続けています。熱心なコミッターは会社の従業員です。 このプロジェクトは小規模ですが、Eclipse のかなりユニークな分野を占めています。その主な目的は、ハンドルベースのモデルの開発をサポートすることです。

ハンドル/ボディ イディオムなどのハンドルベースのモデルの基本的なアーキテクチャ原理については、例としてリソース モデルと Java モデルを使用して説明しました。 また、リソース モデルと Java モデルの両方が Eclipse Java 開発ツール (JDT) の重要な基盤であることにも言及しました。 また、ほとんどすべての *DT Eclipse プロジェクトは JDT に似たアーキテクチャを持っているため、すべてではないにしても、ハンドルベースのモデルが Eclipse プラットフォーム上に構築された多くの IDE の基礎になっていると言っても過言ではありません。 たとえば、Eclipse C/C++ 開発ツール (CDT) には、JDT での Java モデルと同じ役割を CDT アーキテクチャで果たすハンドルベースの C/C++ モデルがあります。

Handly が登場するまで、Eclipse はハンドルベースの言語モデルを構築するための特殊なライブラリを提供していませんでした。 現在存在するモデルは、主に Java モデル コードを直接適用 (別名コピー/ペースト) することによって作成されました。 許可される場合 Eclipse パブリック ライセンス (EPL)。 (明らかに、これは通常、たとえば Eclipse プロジェクト自体については法的な問題ではありませんが、クローズド ソース製品については問題ありません。) この手法は、その本質的な無計画性に加えて、よく知られた問題を引き起こします。エラーに適応する際にコードの重複が発生し、等さらに悪いことに、結果として得られるモデルは「それ自体」のままであり、統合の可能性を活用していないことです。 しかし、ハンドルベースの言語モデルの共通の概念とプロトコルを分離すると、EMF の場合と同様に、それらを操作するための再利用可能なコンポーネントの作成につながる可能性があります。

Eclipse がこれらの問題を理解していなかったわけではありません。 2005 年に遡ります マルティン・エシュリマン、CDT プロトタイプ開発の経験を要約し、 主張した ハンドルベースのモデルを含む言語モデルの共通インフラストラクチャを作成する必要性。 しかし、よくあることですが、タスクの優先順位が高いため、これらのアイデアの実装は実現しませんでした。 一方、*DT コードの因数分解は、Eclipse でまだ開発が進んでいないトピックの XNUMX つです。

ある意味、Handly プロジェクトは、EMF とほぼ同じ問題を解決するように設計されていますが、ハンドルベースのモデル、主に言語の問題 (つまり、何らかのプログラミング言語の構造の要素を表す) が対象です。 Handy を設計するときに設定した主な目標は次のとおりです。

• 主題領域の主な抽象化の特定。
• コードの再利用により、ハンドルベースの言語モデルの実装の労力を削減し、品質を向上させます。
• 結果のモデルに統合されたメタレベル API を提供し、言語ハンドルベースのモデルで動作する共通の IDE コンポーネントを作成できるようにします。
• 柔軟性と拡張性。
• Xtext との統合 (別のレイヤー内)。

共通の概念とプロトコルを強調するために、言語ハンドルベースのモデルの既存の実装が分析されました。 Handly が提供する主なインターフェイスと基本的な実装を図に示します。 8.

米。 8. Handly要素の共通インターフェースと基本実装

IElement インターフェイスは要素のハンドルを表し、すべての Handly ベースのモデルの要素に共通です。 抽象クラス Element は、一般化されたハンドル/ボディ メカニズムを実装します (図 9)。

米。 9. IElement と汎用ハンドル/ボディの実装

さらに、Handly は、モデル要素の変更を通知するための一般化されたメカニズムを提供します (図 10)。 ご覧のとおり、これはリソース モデルや Java モデルに実装された通知メカニズムとほぼ同様であり、IElementDelta を使用して要素変更情報の統一された表現を提供します。

米。 10. 一般的なインターフェイスと Handly 通知メカニズムの基本実装

上で説明した Handly パーツ (図 9 および 10) を使用して、ほぼすべてのハンドルベースのモデルを表すことができます。 作成用 言語的な モデルに加えて、プロジェクトは追加機能を提供します。特に、ソース テキスト構造の要素の共通インターフェイスと基本実装、いわゆる ソース要素 (図8)。 ISourceFile インターフェイスはソース ファイルを表し、ISourceConstruct はソース ファイル内の要素を表します。 抽象クラス SourceFile および SourceConstruct は、ソース ファイルとその要素の操作をサポートする一般化されたメカニズムを実装します。たとえば、テキスト バッファーの操作、ソース テキスト内の要素の座標へのバインド、モデルと作業コピー バッファーの現在の内容の調整などです。 、など。 通常、これらのメカニズムの実装は非常に困難ですが、Handly は高品質の基本実装を提供することで、ハンドルベースの言語モデルを開発する労力を大幅に削減できます。

上記のコア メカニズムに加えて、Handly は、テキスト バッファーとスナップショットのインフラストラクチャ、ソース コード エディターとの統合サポート (Xtext エディターとのすぐに使用できる統合を含む)、およびいくつかの一般的な UI コンポーネントを提供します。ソースコードエディターで作業し、アウトラインフレームワークなどのモデルを操作します。 その機能を説明するために、プロジェクトでは、Handly での Java モデルの実装など、いくつかの例を提供しています。 (JDT での Java モデルの完全な実装と比較して、このモデルは明確にするために意図的に多少簡略化されています。)

前述したように、Handly の初期設計とその後の開発における主な焦点は、スケーラビリティと柔軟性であり、今後もそうであり続けます。

原則として、ハンドルベースのモデルは「設計上」非常にうまく拡張できます。 たとえば、ハンドル/ボディのイディオムを使用すると、モデルが消費するメモリの量を制限できます。 しかし、ニュアンスもあります。 したがって、Handly のスケーラビリティをテストしたときに、通知メカニズムの実装に問題が発見されました。多数の要素が変更されると、デルタの構築に時間がかかりすぎるという問題がありました。 同じ問題が、対応するコードがかつて適応された JDT Java モデルにも存在することが判明しました。 Handly のバグを修正し、JDT 用にも同様のパッチを用意しました。これはありがたいことに受け入れられました。 これは、Handly を既存のモデル実装に導入すると潜在的に役立つ可能性がある一例にすぎません。この場合、そのようなバグは XNUMX か所だけで修正できるためです。

既存のモデル実装に Handly を実装するには、ライブラリに大幅な柔軟性が必要です。 主な問題は、API モデル全体での下位互換性を維持することです。 この問題はで解決されました ハンドリー0.5 これは、開発者によって定義され完全に制御されるモデル固有の API を、ライブラリによって提供される統合メタレベル API から明確に分離することによって実現されます。 これにより、Handly を既存の実装に実装することが技術的に可能になるだけでなく、新しいモデルの開発者が API を設計する際に大きな自由が得られます。

柔軟性には他の側面もあります。 たとえば、Handly はモデルの構造にほとんど制限を課さず、汎用言語とドメイン固有言語の両方をモデル化するために使用できます。 ソース ファイルの構造を構築する際、Handly は AST 表現の特定の形式を規定せず、原則として AST 自体の存在を必要としないため、ほぼすべての解析メカニズムとの互換性が保証されます。 最後に、Handly は Eclipse ワークスペースとの完全な統合をサポートしていますが、Eclipse ワークスペースとの統合により、ファイル システムを直接操作することもできます。 Eclipseファイルシステム （EFS）。

現行版 ハンドリー0.6 2016年XNUMX月に発売されました。 プロジェクトは現在育成段階にあり、API はまだ最終的に修正されていないという事実にもかかわらず、Handly は「早期採用者」として機能するリスクを負った XNUMX つの大きな商用製品ですでに使用されています。まだ後悔しないでください。

上で述べたように、これらの製品の 1 つは 1C:Enterprise Development Tools であり、Handly は最初から、組み込みプログラミング言語やクエリ言語などの XNUMXC:Enterprise 言語の高レベル構造の要素をモデル化するために使用されます。 。 もう XNUMX つの製品は一般にはあまり知られていません。 これ コダシップスタジオ、特定用途向け命令セット プロセッサ (ASIP) 用の統合設計環境で、チェコの企業 Codasip 社内とそのクライアント (以下を含む) の両方で使用されています。 AMD, AVG, Mobileye, シグマデザイン。 Codasip は、2015 年からバージョン Handly 0.2 から実稼働環境で Handly を使用しています。 Codasip Studio の最新リリースでは、0.5 年 2016 月にリリースされたバージョン 4000 が使用されています。 Codasip で IDE 開発を率いる Ondřej Ilčík 氏は、このプロジェクトに連絡を取り、「サードパーティの採用者」を代表して重要なフィードバックを提供しています。 彼は自由時間を見つけてプロジェクトの開発に直接参加し、Handly サンプルの XNUMX つである Java モデルの UI レイヤー (約 XNUMX 行のコード) を実装することもできました。 採用者による Handly の使用に関するさらに詳しい直接の情報は、このページでご覧いただけます。 導入事例 プロジェクト。

API の安定性が保証されたバージョン 1.0 がリリースされ、プロジェクトがインキュベーション状態を終了した後、Handly に新しい採用者が現れることを期待しています。 その間、プロジェクトは API のテストとさらなる改善を続け、年 XNUMX 回の「メジャー」リリース - XNUMX 月 (Eclipse の同時リリースと同じ日) と XNUMX 月にリリースし、導入者が信頼できる予測可能なスケジュールを提供します。 また、プロジェクトの「バグ率」は一貫して低いレベルを維持しており、Handly は最初のバージョン以来、早期採用者の製品で確実に動作していることも付け加えておきます。 Eclipse Handy をさらに詳しく調べるには、次を使用できます。 入門チュートリアル и アーキテクチャの概要.

出所： habr.com