你的位置:首页 > Java教程

[Java教程]Atitit.ide技术原理与实践attilax总结


 

Atitit.ide技术原理与实践attilax总结

 

 

1.1. 语法着色1

1.2. 智能提示1

1.3. 类成员outline..func list1

1.4. 类型推导(type inference): 1

1.5. Remote debug1

1.6. debugging api包一个gui就够了 1

1.7. expression evaluation 2

1.8. 如Java Compiler API2

1.9. Ide每部分代码数统计3

 

 

1.1. 语法着色

语法高亮要靠parser,跳转到定义处编译器要提供symbol和源码位置字典,重构编译器要重写ast, 要支持调试窗口里运行表达式甚至直接调用函数,这个要运行时支持。编译

1.2. 智能提示

1.3. 类成员outline..func list

1.4. 类型推导(type inference):

1.5. Remote debug

,attach上去调

 

1.6. debugging api包一个gui就够了

 

1.7. expression evaluation

这种黑魔法一样的东西(仅针对编译型语言这么说,解释型应该会容易很多),当初应该花了大量的精力开发;

 

作者::  ★(attilax)>>>   绰号:老哇的爪子 ( 全名::Attilax Akbar Al Rapanui 阿提拉克斯 阿克巴 阿尔 拉帕努伊 ) 汉字名:艾龙,  EMAIL:1466519819@qq.com

转载请注明来源: http://www.cnblogs.com/attilax/

 

1.8. 如Java Compiler API

 

 

 我主要关注的是编译器,所以下面就编译器与IDE多聊几句。

当然,现实中开发一个IDE还真的有可能得去实现源语言的编译器。

上面提到的SharpDevelop/MonoDevelop,目前新的版本已经改为基于微软的Roslyn编译器来提供C#支持,语法高亮、错误提示、智能提示等都做得很好了。但其早期版本其实非常弱,只有所谓“语法高亮”,可以参考这个文档。后来为了实现智能提示等功能总算决定实现个真正的C# parser。不过它并没有基于任何现成的编译器来支持IDE功能,而是自己写了一个,上面的书中第12章就是介绍这个parser的,不过写得有点乱嗯。

以Eclipse的Java开发环境(JDT)为例,它要实现准确的语法高亮和语法错误提示,就得按照Java语法实现一个完整的parser;它要实现实时的语义错误提示,就得按照Java语义实现一个完整的语义分析器,而且为了良好的用户体验,它可能要内建更多的对错误模式的检查和提示。做到这里,离一个完整的Java源码编译器也就只剩一个很简单直观的代码生成器(code generator)了。于是Eclipse做了ECJ——Eclipse Compiler for Java,整合在Eclipse JDT中。
在此基础上,Eclipse JDT还有项目模型,将项目里的各种资源都用一个统一的模型管理起来,从workspace到project、package、file然后里面的class/interface这样一直下去。在class/interface层面上这个模型用的就是ECJ的AST。

其实如果有一个现成的对IDE支持良好的编译器的话,实现一个IDE就不必费那么多事自己去写编译器。但是Eclipse诞生时,主流的Java源码编译器javac并不开源,而IBM当时主流的Java源码编译器Jikes是用C++写的,要整合在用Java写的Eclipse里不太方便,所以才要自己写。
有了这个编译器之后,Eclipse倒是可以做许多“非常规”的事情。例如说它可以为有错误的源码文件生成Class文件,而且这个Class文件可以一直执行到源码里有错的地方然后抛出异常——这种事情javac就不太可能会去做。

后来javac开源了,而且开放出许多便于IDE实现自身功能的API出来(例如Java Compiler API),后来的Netbeans就干脆直接用javac来实现语法高亮、报错等各种功能了。背后的故事可以参考这篇博文:NetBeans IDE 6.0

而一个反例就是微软的Visual Studio里的C++支持。Visual C++自身是个优秀的优化编译器,但它的前端部分(词法/语法/语义分析+中间代码生成)的历史非常非常“久远”,原始设计并未考虑支持IDE的功能,所以Visual Studio IDE里的C++支持其实用的是另一套完全不同的C++ parser(购买自EDG),既增加了复杂度又无法保证两套parser之间完全的兼容性。
当然微软也早就意识到了这个问题。近来,随着对C++14的支持,微软大幅更新了其Visual C++编译器的前端(参考Rejuvenating the Microsoft C/C++ Compiler),按照这个路子走下去的话,在IDE里替换掉EDG的C++ parser改为直接用Visual C++自己的,兴许也是可能的未来。

 

 

 

1.9. Ide每部分代码数统计

分类

包含内容

源码行数

Code Analysis

代码模型、分析和生成相关

123957

IDE

IDE程序和界面相关

62940

Visual Editor

可视化编辑器

30760

Text Editor

文本编辑器

20264

Tools

版本控制和帮助等辅助工具

11556

Language

语言绑定,包括C#,VB等

9292

Debugger

调试器

9238

Framework

Asp.Net Mvc等框架支持

8513

Misc

杂项

2289

Builder

构建和MsBuild相关

1774

Data

数据库支持

1396

对应的图表:

项目分析

可见整个IDE最复杂的部分在于代码模型的处理,代码数量几乎是第二名(IDE)的两倍之多,占整个项目代码的比例也接近 50% 了。我没有进一步分析,不过大概可以想象,代码编辑时的文本着色、语法提示、代码生成、辅助分析、重构等功能应该都与此相关。如果真的想自己写一个IDE的话,这一部分肯定是个难啃的硬骨头。

参考资料

IDE的现实分析 - 对“开发一个IDE难度有多大”问题的回答 _ Shuhari的博客.html

开发一个IDE难度多大_ - 编程 - 知乎.html