Mungkin sudah lama tidak memerlukan pengenalan khusus. Banyak orang yang mengenal Eclipse berkat alat pengembangan Eclipse Java (). IDE Java open-source populer inilah yang diasosiasikan oleh sebagian besar pengembang dengan kata “Eclipse”. Namun, Eclipse merupakan platform yang dapat diperluas untuk mengintegrasikan alat pengembangan (Eclipse Platform), dan sejumlah IDE yang dibangun berdasarkan platform tersebut, termasuk JDT. Eclipse adalah Proyek Eclipse, proyek tingkat atas yang mengoordinasikan pengembangan Platform Eclipse dan JDT, dan Eclipse SDK, hasil pengembangan tersebut. Terakhir, Eclipse adalah Yayasan sumber terbuka dengan komunitas proyek yang sangat besar, tidak semuanya ditulis dalam Java atau terkait dengan alat pengembangan (misalnya, proyek и ). Dunia Eclipse sangat beragam.
Pada artikel yang bersifat ikhtisar ini, kami akan mencoba melihat beberapa dasar-dasar arsitektur Eclipse sebagai platform untuk membangun alat pengembangan terintegrasi dan memberikan gambaran awal tentang komponen Eclipse yang menjadi fondasi teknologi tersebut. platform untuk "Konfigurator baru" 1C: Perusahaan. . Tentu saja, tinjauan semacam itu pasti akan bersifat dangkal dan agak terbatas, termasuk karena kami tidak hanya berfokus pada pengembang Eclipse sebagai target audiens. Namun, kami berharap pengembang Eclipse yang berpengalaman pun dapat menemukan informasi menarik di artikel tersebut. Misalnya, kita akan berbicara tentang salah satu “rahasia Eclipse”, sebuah proyek yang relatif baru dan kurang dikenal , yang didirikan dan didukung oleh 1C.
Pengantar Arsitektur Eclipse
Pertama mari kita lihat beberapa aspek umum arsitektur Eclipse menggunakan sebuah contoh (JDT). Pemilihan JDT sebagai contoh bukanlah suatu kebetulan. Ini adalah lingkungan pengembangan terintegrasi pertama yang muncul di Eclipse. Proyek *DT Eclipse lainnya, seperti Eclipse C/C++ Development Tooling (CDT), dibuat kemudian dan meminjam prinsip arsitektur dasar dan fragmen kode sumber individual dari JDT. Dasar-dasar arsitektur yang ditetapkan dalam JDT masih relevan hingga saat ini untuk hampir semua IDE yang dibangun di atas Platform Eclipse, termasuk 1C:Enterprise Development Tools.
Pertama-tama, perlu dicatat bahwa Eclipse dicirikan oleh lapisan arsitektur yang cukup jelas, dengan pemisahan fungsionalitas yang tidak bergantung pada bahasa dari fungsionalitas yang dirancang untuk mendukung bahasa pemrograman tertentu, dan pemisahan komponen "inti" yang tidak bergantung pada UI dari komponen yang terkait. dengan antarmuka pengguna yang mendukung.
Dengan demikian, Platform Eclipse mendefinisikan infrastruktur umum yang tidak bergantung pada bahasa, dan alat pengembangan Java menambahkan IDE Java berfitur lengkap ke Eclipse. Baik Platform Eclipse maupun JDT terdiri dari beberapa komponen, yang masing-masing merupakan bagian dari “inti” atau lapisan UI yang tidak bergantung pada UI (Gambar 1).
Beras. 1. Platform Eclipse dan JDT
Mari kita daftar komponen utama Platform Eclipse:
- Runtime — Mendefinisikan infrastruktur plugin. Eclipse dicirikan oleh arsitektur modular. Pada dasarnya, Eclipse adalah kumpulan "titik ekstensi" dan "ekstensi".
- ruang kerja — Mengelola satu atau lebih proyek. Sebuah proyek terdiri dari folder dan file yang dipetakan langsung ke sistem file.
- Perangkat Widget Standar (SWT) - Menyediakan elemen antarmuka pengguna dasar yang terintegrasi dengan sistem operasi.
- wajah J — Menyediakan sejumlah kerangka UI yang dibangun di atas SWT.
- Workbench — Mendefinisikan paradigma Eclipse UI: editor, pandangan, perspektif.
Harus dikatakan bahwa Platform Eclipse juga menyediakan banyak komponen berguna lainnya untuk membangun alat pengembangan terintegrasi, termasuk Debug, Bandingkan, Pencarian, dan Tim. Perhatian khusus harus diberikan pada Teks JFace - dasar untuk membangun "editor cerdas" kode sumber. Sayangnya, pemeriksaan sekilas terhadap komponen-komponen ini, serta komponen lapisan UI, tidak mungkin dilakukan dalam cakupan artikel ini, jadi di sisa bagian ini kami akan membatasi diri pada ikhtisar komponen “inti” utama dari Platform Eclipse dan JDT.
Waktu Proses Inti
Infrastruktur plugin Eclipse didasarkan pada dan disediakan oleh proyek . Setiap plugin Eclipse adalah bundel OSGi. Spesifikasi OSGi mendefinisikan, khususnya, mekanisme pembuatan versi dan resolusi ketergantungan. Selain mekanisme standar tersebut, Equinox memperkenalkan konsep tersebut titik ekspansi. Setiap plugin dapat menentukan titik ekstensinya sendiri, dan juga memperkenalkan fungsionalitas tambahan (“ekstensi”) ke sistem menggunakan titik ekstensi yang ditentukan oleh plugin yang sama atau plugin lainnya. Penjelasan rinci tentang mekanisme OSGi dan Equinox berada di luar cakupan artikel ini. Mari kita perhatikan saja bahwa modularisasi di Eclipse bersifat total (subsistem apa pun, termasuk Runtime, terdiri dari satu atau lebih plugin), dan hampir semua yang ada di Eclipse adalah ekstensi. Selain itu, prinsip-prinsip ini telah tertanam dalam arsitektur Eclipse jauh sebelum OSGi diperkenalkan (pada saat itu mereka menggunakan teknologi mereka sendiri, mirip dengan OSGi).
Ruang Kerja Inti
Hampir semua lingkungan pengembangan terintegrasi yang dibangun di atas Platform Eclipse berfungsi dengan ruang kerja Eclipse. Ini adalah ruang kerja yang biasanya berisi kode sumber aplikasi yang dikembangkan di IDE. Ruang kerja dipetakan langsung ke sistem file dan terdiri dari proyek, yang berisi folder dan file. Proyek, folder, dan file ini disebut sumber daya ruang kerja. Implementasi ruang kerja di Eclipse berfungsi sebagai cache sehubungan dengan sistem file, yang memungkinkan untuk mempercepat traversal pohon sumber daya secara signifikan. Selain itu, ruang kerja menyediakan sejumlah layanan tambahan, antara lain и .
Komponen Sumber Daya Inti (plugin org.eclipse.core.resources) bertanggung jawab untuk mendukung ruang kerja dan sumber dayanya. Secara khusus, komponen ini menyediakan akses terprogram ke ruang kerja dalam bentuk model sumber daya. Untuk bekerja secara efektif dengan model ini, klien memerlukan cara sederhana untuk menyajikan tautan ke sumber daya. Dalam hal ini, sebaiknya sembunyikan objek yang secara langsung menyimpan status sumber daya dalam model dari akses klien. Jika tidak, dalam kasus, misalnya, menghapus file, klien dapat terus menahan objek yang tidak lagi ada dalam model, dengan masalah yang timbul. Eclipse memecahkan masalah ini menggunakan sesuatu yang disebut menangani sumber. Handle bertindak sebagai kunci (hanya mengetahui jalur ke sumber daya di ruang kerja) dan sepenuhnya mengontrol akses ke objek model internal, yang secara langsung menyimpan informasi tentang status sumber daya. Desain ini merupakan variasi pola .
Beras. Gambar 2 mengilustrasikan idiom Handle/Body sebagaimana diterapkan pada model sumber daya. Antarmuka IResource mewakili pegangan sumber daya dan merupakan API, tidak seperti kelas Resource, yang mengimplementasikan antarmuka ini, dan kelas ResourceInfo, yang mewakili isi, yang bukan API. Kami menekankan bahwa pegangan hanya mengetahui jalur ke sumber daya relatif terhadap akar ruang kerja dan tidak berisi tautan ke info sumber daya. Objek info sumber daya membentuk apa yang disebut “pohon elemen”. Struktur data ini sepenuhnya terwujud dalam memori. Untuk menemukan instance info sumber daya yang sesuai dengan suatu pegangan, pohon elemen dilintasi sesuai dengan jalur yang disimpan dalam pegangan itu.
Beras. 2. iResource dan ResourceInfo
Seperti yang akan kita lihat nanti, desain dasar model sumber daya (kita mungkin menyebutnya berbasis pegangan) juga digunakan di Eclipse untuk model lain. Untuk saat ini, mari kita daftar beberapa ciri khas dari desain ini:
- Pegangan adalah objek nilai. Objek nilai adalah objek abadi yang kesetaraannya tidak didasarkan pada identitas. Objek tersebut dapat digunakan dengan aman sebagai kunci dalam wadah hash. Beberapa contoh pegangan dapat mereferensikan sumber daya yang sama. Untuk membandingkannya, Anda perlu menggunakan metode sama dengan(Objek).
- Handle mendefinisikan perilaku sumber daya, namun tidak berisi informasi tentang status sumber daya (satu-satunya data yang disimpannya adalah "kunci", jalur ke sumber daya).
- Pegangan dapat merujuk pada sumber daya yang tidak ada (baik sumber daya yang belum dibuat, atau sumber daya yang telah dihapus). Keberadaan sumber daya dapat diperiksa menggunakan metode IResource.exists().
- Beberapa operasi dapat diimplementasikan hanya berdasarkan informasi yang disimpan dalam pegangan itu sendiri (disebut operasi hanya pegangan). Contohnya adalah IResource.getParent(), getFullPath(), dll. Sumber daya tidak perlu ada agar operasi tersebut berhasil. Operasi yang memerlukan keberadaan sumber daya agar berhasil memunculkan CoreException jika sumber daya tidak ada.
Eclipse menyediakan mekanisme yang efisien untuk memberitahukan perubahan sumber daya ruang kerja (Gambar 3). Sumber daya dapat berubah baik sebagai akibat dari tindakan yang dilakukan dalam Eclipse IDE itu sendiri atau sebagai akibat sinkronisasi dengan sistem file. Dalam kedua kasus tersebut, klien yang berlangganan notifikasi diberikan informasi rinci tentang perubahan dalam bentuk “delta sumber daya”. Delta menggambarkan perubahan antara dua keadaan pohon sumber daya ruang kerja (sub-) dan merupakan pohon itu sendiri, masing-masing simpul menggambarkan perubahan pada sumber daya dan berisi daftar delta di tingkat berikutnya yang menggambarkan perubahan pada sumber daya anak.
Beras. 3. IResourceChangeEvent dan IResourceDelta
Mekanisme notifikasi berdasarkan delta sumber daya memiliki karakteristik sebagai berikut:
- Perubahan tunggal dan banyak perubahan dijelaskan menggunakan struktur yang sama, karena delta dibangun menggunakan prinsip komposisi rekursif. Klien pelanggan dapat memproses pemberitahuan perubahan sumber daya menggunakan penurunan rekursif melalui pohon delta.
- Delta berisi informasi lengkap tentang perubahan pada sumber daya, termasuk pergerakannya dan/atau perubahan “penanda” yang terkait dengannya (misalnya, kesalahan kompilasi direpresentasikan sebagai penanda).
- Karena referensi sumber daya dibuat melalui pegangan, delta secara alami dapat mereferensikan sumber daya jarak jauh.
Seperti yang akan segera kita lihat, komponen utama desain mekanisme pemberitahuan perubahan model sumber daya juga relevan untuk model berbasis pegangan lainnya.
Inti JDT
Model sumber daya ruang kerja Eclipse adalah model dasar tanpa bahasa. Komponen JDT Core (plugin org.eclipse.jdt.core) menyediakan API untuk menavigasi dan menganalisis struktur ruang kerja dari perspektif Java, yang disebut “model Java” (model Jawa). API ini didefinisikan dalam elemen Java, bukan API model sumber daya yang mendasarinya, yang didefinisikan dalam folder dan file. Antarmuka utama pohon elemen Java ditunjukkan pada Gambar. 4.
Beras. 4. Elemen Model Java
Model Java menggunakan idiom handle/body yang sama dengan model sumber daya (Gambar 5). IJavaElement adalah pegangannya, dan JavaElementInfo berperan sebagai badan. Antarmuka IJavaElement mendefinisikan protokol yang umum untuk semua elemen Java. Beberapa metodenya hanya dapat ditangani: getElementName(), getParent(), dll. Objek JavaElementInfo menyimpan status elemen terkait: struktur dan atributnya.
Beras. 5. IJavaElement dan JavaElementInfo
Model Java memiliki beberapa perbedaan dalam implementasi desain dasar pegangan/badan dibandingkan dengan model sumber daya. Seperti disebutkan di atas, dalam model sumber daya, pohon elemen, yang simpulnya merupakan objek info sumber daya, seluruhnya terdapat dalam memori. Namun model Java dapat memiliki jumlah elemen yang jauh lebih besar daripada pohon sumber daya, karena model ini juga mewakili struktur internal file .java dan .class: jenis, bidang, dan metode.
Untuk menghindari terwujudnya seluruh pohon elemen dalam memori, implementasi model Java menggunakan cache LRU info elemen berukuran terbatas, dengan kuncinya adalah pegangan IJavaElement. objek info elemen dibuat sesuai permintaan saat pohon elemen dinavigasi. Dalam hal ini, item yang paling jarang digunakan akan dikeluarkan dari cache, dan konsumsi memori model tetap terbatas pada ukuran cache yang ditentukan. Ini adalah keuntungan lain dari desain berbasis pegangan, yang sepenuhnya menyembunyikan detail implementasi tersebut dari kode klien.
Mekanisme untuk memberitahukan perubahan pada elemen Java secara umum mirip dengan mekanisme untuk melacak perubahan pada sumber daya ruang kerja yang dibahas di atas. Klien yang ingin memantau perubahan dalam model Java berlangganan notifikasi, yang direpresentasikan sebagai objek ElementChangedEvent yang berisi IJavaElementDelta (Gambar 6).
Beras. 6. ElementChangedEvent dan IJavaElementDelta
Model Java tidak berisi informasi tentang badan metode atau resolusi nama, jadi untuk analisis rinci kode yang ditulis dalam Java, JDT Core menyediakan model tambahan (berbasis non-pegangan): (pohon sintaksis abstrak, AST). AST mewakili hasil parsing teks sumber. Node AST sesuai dengan elemen struktur modul sumber (deklarasi, operator, ekspresi, dll.) dan berisi informasi tentang koordinat elemen terkait dalam teks sumber, serta (sebagai opsi) informasi tentang resolusi nama di bentuk tautan ke apa yang disebut bindings. Binding adalah objek yang mewakili entitas bernama, seperti tipe, metode, dan variabel, yang diketahui oleh kompiler. Berbeda dengan node AST yang membentuk pohon, binding mendukung referensi silang dan umumnya membentuk grafik. Kelas abstrak ASTNode adalah kelas dasar umum untuk semua node AST. Subkelas ASTNode sesuai dengan konstruksi sintaksis tertentu dari bahasa Java.
Karena pohon sintaksis dapat menghabiskan banyak memori, JDT hanya menyimpan satu AST untuk editor aktif. Berbeda dengan model Java, AST biasanya dipandang sebagai model "perantara", "sementara", yang elemen-elemennya tidak boleh dirujuk oleh klien di luar konteks operasi yang mengarah pada pembuatan AST.
Tiga model yang terdaftar (model Java, AST, binding) bersama-sama membentuk dasar untuk membangun “alat pengembangan cerdas” di JDT, termasuk editor Java yang kuat dengan berbagai “pembantu”, berbagai tindakan untuk memproses kode sumber (termasuk mengatur daftar impor nama dan pemformatan sesuai dengan gaya yang disesuaikan), alat pencarian dan pemfaktoran ulang. Dalam hal ini, model Java memainkan peran khusus, karena digunakan sebagai dasar representasi visual dari struktur aplikasi yang sedang dikembangkan (misalnya, dalam Package Explorer, Outline, Search, Call Hierarchy, dan Ketik Hirarki).
Komponen Eclipse yang digunakan dalam 1C:Enterprise Developments Tools
Pada Gambar. Gambar 7 menunjukkan komponen Eclipse yang menjadi dasar platform teknologi untuk 1C:Enterprise Development Tools.
Beras. 7. Eclipse sebagai platform untuk 1C:Enterprise Development Tools
Platform Gerhana menyediakan infrastruktur dasar. Kita telah melihat beberapa aspek infrastruktur ini di bagian sebelumnya.
(EMF) menyediakan sarana umum untuk memodelkan data terstruktur. EMF terintegrasi dengan Platform Eclipse, tetapi juga dapat digunakan secara terpisah dalam aplikasi Java biasa. Seringkali, pengembang baru Eclipse sudah mengenal EMF dengan baik, meskipun mereka belum sepenuhnya memahami seluk-beluk Platform Eclipse. Salah satu alasan popularitas yang memang layak diterima ini adalah desain universalnya, yang mencakup, antara lain, API meta-level terpadu, yang memungkinkan Anda bekerja dengan model EMF apa pun secara umum. Implementasi dasar untuk objek model yang disediakan oleh EMF dan subsistem untuk menghasilkan kode model berdasarkan meta-model secara signifikan meningkatkan kecepatan pengembangan dan mengurangi jumlah kesalahan. EMF juga berisi mekanisme untuk membuat serialisasi model, melacak perubahan pada model, dan banyak lagi.
Seperti alat serba guna lainnya, EMF cocok untuk memecahkan berbagai masalah pemodelan, namun beberapa kelas model (misalnya, model berbasis pegangan yang dibahas di atas) mungkin memerlukan alat pemodelan yang lebih khusus. Berbicara tentang EMF adalah tugas yang tidak ada gunanya, terutama dalam batasan satu artikel, karena ini adalah subjek dari buku tersendiri, dan cukup tebal. Mari kita perhatikan saja bahwa sistem generalisasi berkualitas tinggi yang mendasari EMF memungkinkan lahirnya seluruh rangkaian proyek yang didedikasikan untuk pemodelan, yang termasuk dalam proyek tingkat atas. bersama dengan EMF itu sendiri. Salah satu proyek tersebut adalah Eclipse Xtext.
menyediakan infrastruktur "pemodelan teks". Penggunaan Xtext untuk mengurai teks sumber dan EMF untuk mewakili ASG yang dihasilkan (grafik semantik abstrak, yang pada dasarnya merupakan kombinasi AST dan binding), juga disebut “model semantik”. Tata bahasa yang dimodelkan oleh Xtext dijelaskan dalam bahasa Xtext sendiri. Hal ini memungkinkan Anda tidak hanya menghasilkan deskripsi tata bahasa untuk ANTLR, tetapi juga mendapatkan mekanisme serialisasi AST (yaitu Xtext menyediakan parser dan unparser), petunjuk konteks, dan sejumlah komponen bahasa lainnya. Di sisi lain, bahasa tata bahasa yang digunakan di Xtext kurang fleksibel dibandingkan, katakanlah, bahasa tata bahasa yang digunakan di ANTLR. Oleh karena itu, terkadang perlu untuk “membengkokkan” bahasa yang diimplementasikan ke Xtext, yang biasanya tidak menjadi masalah jika kita berbicara tentang bahasa yang dikembangkan dari awal, tetapi mungkin tidak dapat diterima untuk bahasa dengan sintaksis yang sudah ada. Meskipun demikian, Xtext saat ini merupakan alat yang paling matang, kaya fitur, dan serbaguna di Eclipse untuk membangun bahasa pemrograman dan alat pengembangannya. Secara khusus, ini adalah alat yang ideal untuk pembuatan prototipe cepat (bahasa khusus domain, DSL). Selain “inti bahasa” yang disebutkan di atas berdasarkan ANTLR dan EMF, Xtext menyediakan banyak komponen tingkat tinggi yang berguna, termasuk mekanisme pengindeksan, konstruksi tambahan, “editor cerdas”, dan masih banyak lagi, tetapi mengabaikan penanganan- model bahasa berbasis. Seperti EMF, Xtext adalah subjek yang layak untuk dijadikan buku terpisah, dan saat ini kita bahkan hampir tidak dapat membicarakan semua kemampuannya secara singkat.
1C:Enterprise Development Tools secara aktif menggunakan EMF itu sendiri dan sejumlah proyek Pemodelan Eclipse lainnya. Secara khusus, Xtext adalah salah satu dasar alat pengembangan untuk bahasa 1C:Enterprise seperti bahasa pemrograman dan bahasa kueri bawaan. Basis lain untuk alat pengembangan ini adalah proyek Eclipse Handly, yang akan kita bahas lebih terinci (dari komponen Eclipse yang terdaftar, komponen ini masih paling sedikit diketahui).
, sebuah subproyek dari proyek tingkat atas Teknologi Eclipse, muncul sebagai hasil kontribusi kode awal ke Eclipse Foundation yang dibuat oleh 1C pada tahun 2014. Sejak itu, 1C terus mendukung pengembangan proyek: Handly committer adalah karyawan perusahaan. Proyek ini kecil, tetapi menempati ceruk yang cukup unik di Eclipse: tujuan utamanya adalah untuk mendukung pengembangan model berbasis pegangan.
Prinsip arsitektur dasar model berbasis pegangan, seperti idiom pegangan/badan, telah dibahas di atas menggunakan model sumber daya dan model Java sebagai contoh. Dicatat juga bahwa model sumber daya dan model Java merupakan fondasi penting untuk alat pengembangan Eclipse Java (JDT). Dan karena hampir semua proyek *DT Eclipse memiliki arsitektur yang mirip dengan JDT, tidak berlebihan untuk mengatakan bahwa model berbasis pegangan mendasari banyak, jika tidak semua IDE dibangun di atas Platform Eclipse. Misalnya, Eclipse C/C++ Development Tooling (CDT) memiliki model C/C++ berbasis pegangan yang memainkan peran yang sama dalam arsitektur CDT seperti model Java di JDT.
Sebelum Handly, Eclipse tidak menawarkan perpustakaan khusus untuk membangun model bahasa berbasis pegangan. Model-model yang ada saat ini dibuat terutama dengan mengadaptasi langsung kode model Java (alias copy/paste), dalam kasus yang memungkinkan Lisensi Publik Eclipse (EPL). (Jelas, ini biasanya bukan masalah hukum, katakanlah, proyek Eclipse itu sendiri, tetapi tidak untuk produk sumber tertutup.) Selain keserampangan yang melekat, teknik ini menimbulkan masalah yang umum: duplikasi kode yang ditimbulkan saat beradaptasi dengan kesalahan, dll. Yang lebih buruk lagi adalah model-model yang dihasilkan tetap “sesuatu” dan tidak memanfaatkan potensi unifikasi. Namun mengisolasi konsep dan protokol umum untuk model bahasa berbasis pegangan dapat mengarah pada pembuatan komponen yang dapat digunakan kembali untuk bekerja dengannya, serupa dengan yang terjadi dalam kasus EMF.
Bukan berarti Eclipse tidak memahami masalah ini. Kembali pada tahun 2005 , merangkum pengalaman mengembangkan prototipe CDT, kebutuhan untuk menciptakan infrastruktur umum untuk model bahasa, termasuk model berbasis pegangan. Namun, seperti yang sering terjadi, karena tugas-tugas dengan prioritas lebih tinggi, implementasi ide-ide tersebut tidak pernah berhasil. Sementara itu, faktorisasi kode *DT masih menjadi salah satu topik yang terbelakang di Eclipse.
Dalam arti tertentu, proyek Handly dirancang untuk memecahkan masalah yang kira-kira sama dengan EMF, tetapi untuk model berbasis pegangan, dan terutama model bahasa (yaitu, mewakili elemen struktur beberapa bahasa pemrograman). Tujuan utama yang ditetapkan saat mendesain Handly tercantum di bawah ini:
- Identifikasi abstraksi utama bidang studi.
- Mengurangi upaya dan meningkatkan kualitas implementasi model bahasa berbasis pegangan melalui penggunaan kembali kode.
- Menyediakan API tingkat meta terpadu ke model yang dihasilkan, sehingga memungkinkan pembuatan komponen IDE umum yang bekerja dengan model berbasis pegangan bahasa.
- Fleksibilitas dan skalabilitas.
- Integrasi dengan Xtext (dalam lapisan terpisah).
Untuk menyoroti konsep dan protokol umum, implementasi model berbasis pegangan bahasa yang ada dianalisis. Antarmuka utama dan implementasi dasar yang disediakan oleh Handly ditunjukkan pada Gambar. 8.
Beras. 8. Antarmuka umum dan implementasi dasar elemen Handly
Antarmuka IElement mewakili pegangan elemen dan umum untuk elemen semua model berbasis Handly. Elemen kelas abstrak mengimplementasikan mekanisme pegangan/tubuh yang digeneralisasi (Gbr. 9).
Beras. 9. Implementasi IElement dan handle/body generik
Selain itu, Handly menyediakan mekanisme umum untuk memberi tahu tentang perubahan elemen model (Gbr. 10). Seperti yang Anda lihat, ini secara umum mirip dengan mekanisme notifikasi yang diterapkan dalam model sumber daya dan model Java, dan menggunakan IElementDelta untuk memberikan representasi terpadu informasi perubahan elemen.
Beras. 10. Antarmuka umum dan implementasi dasar mekanisme notifikasi Handly
Bagian Handly yang dibahas di atas (Gbr. 9 dan 10) dapat digunakan untuk mewakili hampir semua model berbasis pegangan. Untuk membuat linguistik model, proyek ini menawarkan fungsionalitas tambahan - khususnya, antarmuka umum dan implementasi dasar untuk elemen struktur teks sumber, yang disebut elemen sumber (Gbr. 8). Antarmuka ISourceFile mewakili file sumber, dan ISourceConstruct mewakili elemen dalam file sumber. Kelas abstrak SourceFile dan SourceConstruct mengimplementasikan mekanisme umum untuk mendukung pekerjaan dengan file sumber dan elemennya, misalnya, bekerja dengan buffer teks, mengikat koordinat elemen dalam teks sumber, merekonsiliasi model dengan konten buffer copy pekerjaan saat ini , dll. Penerapan mekanisme ini biasanya cukup menantang, dan Handly dapat secara signifikan mengurangi upaya pengembangan model bahasa berbasis pegangan dengan menyediakan implementasi dasar berkualitas tinggi.
Selain mekanisme inti yang tercantum di atas, Handly menyediakan infrastruktur untuk buffer teks dan snapshot, dukungan untuk integrasi dengan editor kode sumber (termasuk integrasi langsung dengan editor Xtext), serta beberapa komponen UI umum yang bekerja dengan editor kode sumber Model praktis seperti kerangka kerangka. Untuk mengilustrasikan kemampuannya, proyek ini memberikan beberapa contoh, termasuk implementasi model Java di Handly. (Dibandingkan dengan implementasi penuh model Java di JDT, model ini sengaja disederhanakan agar lebih jelas.)
Seperti disebutkan sebelumnya, fokus utama selama desain awal Handly dan pengembangan selanjutnya adalah skalabilitas dan fleksibilitas.
Pada prinsipnya, model berbasis pegangan berskala cukup baik “sesuai desain”. Misalnya, idiom handle/body memungkinkan Anda membatasi jumlah memori yang dikonsumsi oleh suatu model. Namun ada juga nuansanya. Jadi, saat menguji skalabilitas Handly, masalah ditemukan dalam implementasi mekanisme notifikasi - ketika sejumlah besar elemen diubah, membangun delta membutuhkan terlalu banyak waktu. Ternyata masalah yang sama juga terjadi pada model JDT Java, yang pernah mengadaptasi kode terkait. Kami memperbaiki bug di Handly dan menyiapkan patch serupa untuk JDT, yang diterima dengan penuh syukur. Ini hanyalah salah satu contoh di mana memperkenalkan Handly ke dalam implementasi model yang ada berpotensi berguna, karena dalam kasus ini bug tersebut dapat diperbaiki hanya di satu tempat.
Agar penerapan Handly ke dalam implementasi model yang ada layak secara teknis, perpustakaan harus memiliki fleksibilitas yang signifikan. Masalah utamanya adalah menjaga kompatibilitas ke belakang di seluruh model API. Masalah ini diselesaikan di dengan secara jelas memisahkan API khusus model, yang ditentukan dan dikontrol sepenuhnya oleh pengembang, dari API tingkat meta terpadu yang disediakan oleh perpustakaan. Hal ini tidak hanya memungkinkan secara teknis untuk mengimplementasikan Handly ke dalam implementasi yang sudah ada, namun juga memberikan kebebasan yang signifikan bagi pengembang model baru saat merancang API.
Fleksibilitas juga memiliki aspek lain. Misalnya, Handly hampir tidak menerapkan batasan pada struktur model dan dapat digunakan untuk memodelkan bahasa tujuan umum dan bahasa khusus domain. Saat membangun struktur file sumber, Handly tidak menentukan bentuk representasi AST tertentu dan, pada prinsipnya, bahkan tidak memerlukan kehadiran AST itu sendiri, sehingga memastikan kompatibilitas dengan hampir semua mekanisme parsing. Terakhir, Handly mendukung integrasi penuh dengan ruang kerja Eclipse, tetapi juga dapat bekerja secara langsung dengan sistem file berkat integrasinya (EFS).
Versi sekarang keluar pada bulan Desember 2016. Terlepas dari kenyataan bahwa proyek tersebut saat ini dalam tahap inkubasi dan API akhirnya belum diperbaiki, Handly sudah digunakan dalam dua produk komersial besar yang mengambil risiko bertindak sebagai “pengadopsi awal”, dan, harus saya katakan, jangan menyesalinya dulu.
Seperti disebutkan di atas, salah satu produknya adalah 1C:Enterprise Development Tools, di mana Handly digunakan sejak awal untuk memodelkan elemen struktur tingkat tinggi dari bahasa 1C:Enterprise seperti bahasa pemrograman bawaan dan bahasa kueri . Satu lagi produk yang kurang dikenal masyarakat umum. Ini , lingkungan desain terintegrasi untuk prosesor set instruksi khusus aplikasi (ASIP), yang digunakan baik di dalam perusahaan Ceko Codasip sendiri maupun oleh kliennya, termasuk , , , . Codasip telah menggunakan Handly dalam produksinya sejak tahun 2015, dimulai dengan versi Handly 0.2. Codasip Studio keluaran terbaru ini menggunakan versi 0.5 yang dirilis pada bulan Juni 2016. Ondřej Ilčík, yang memimpin pengembangan IDE di Codasip, berhubungan dengan proyek ini, memberikan masukan penting atas nama “pengadopsi pihak ketiga”. Dia bahkan dapat meluangkan waktu luang untuk berpartisipasi langsung dalam pengembangan proyek, mengimplementasikan lapisan UI (~4000 baris kode) untuk salah satu contoh Handly, model Java. Informasi langsung yang lebih rinci tentang penggunaan Handly oleh pengguna dapat ditemukan di halaman proyek.
Kami berharap setelah rilis versi 1.0 dengan jaminan stabilitas API dan proyek keluar dari status inkubasi, Handly akan memiliki pengguna baru. Sementara itu, proyek ini terus menguji dan menyempurnakan API lebih lanjut, merilis dua rilis "utama" per tahun - pada bulan Juni (tanggal yang sama dengan rilis Eclipse secara bersamaan) dan Desember, memberikan jadwal yang dapat diprediksi dan dapat diandalkan oleh pengguna. Kami juga dapat menambahkan bahwa “tingkat bug” proyek ini tetap berada pada tingkat yang rendah dan Handly telah bekerja dengan andal pada produk-produk pengguna awal sejak versi pertama. Untuk menjelajahi Eclipse Handly lebih jauh, Anda dapat menggunakan и .
Sumber: www.habr.com