另一只眼看Eclipse，所谓的开源 博客分类： 所谓的开源 EclipseMyeclipseIBM.net企业应用
程序员文章站
2024-02-26 15:05:34
...
但凡有Java开发经验的同学，对Eclipse肯定不会陌生。出身名门IBM、精心设计的架构、强大的Community支持、Open Source、等等，这些数不尽的好处让Eclipse在短短几年之内横扫Java IDE领域，获奖无数，更是赢得了广大开发人员的尊重与爱戴。我自己就是和还算有经验的Java程序员，对Eclipse也算是比较熟悉。从Eclipse 2.1开始就一直密切关注着，不单单是使用，自己也做过Plug-in的开发，我想应该算有资格对Eclipse说两句。但是遗憾的是我要对Eclipse泼冷水了，虽然我打心眼儿里喜欢它，可这些话我还是要说。
仅仅从IDE的使用者角度上讲，Eclipse可以算是最接近完美的。虽然在其2.1和3.0版本上，会有狂吃内存、容易死机等缺点，但是到了如今稳定发布的3.1.x版本，这种现象已经很少，在即将发布的3.2版本中，还提供了手工激活垃圾回收的功能，我之前在Weblogic workshop中使用过这种功能，觉得是很实用的。
我今天的话主要是作为一个Eclipse Plug-in & RCP开发者而说的。Eclipse号称是一个开放的平台，任何人可以对其进行任何方面的扩展，这就是我们现在看到的成百上千的Plug-in；同时，Eclipse也允许用户裁减掉除核心模块外的任意组件，来构建自己的应用，这就是RCP。然而，这看似完美的flexibility后面隐藏着一些问题和不为人所知的秘密。
Eclipse Plug-in & RCP Development最大的问题就是版本不兼容性，在任意一个版本中开发的Plug-in都无法保证能在其他版本中正确运行。因此我们会发现，即使像MyEclipse和SWT-Designer这样的商业Plug-in也摆脱不了版本的噩梦，它们不得不为2.1，3.0，3.1以及即将发布的3.2版本单独维护相应版本的Plug-in。同样的事情还发生在Plug-in之间的依赖上，如果一个Plug-in对其它一些Plug-in有所以来，那么必须保证使用了正确的版本，而其它Plug-in并不保证会版本兼容。所以想象一下，同学A很辛苦的写了一个以来于GEF的图形建模插件，花去了他6个月的时间，当他很高兴的宣布终于可以release的时候，他发现GEF有了新的版本，且与之前的版本不兼容。GEF是Eclipse的官方项目，同时Eclipse也推出了基于新GEF的官方Plug-in（不是图形建模），那么当同学B想同时使用同学A的Plug-in和Eclipse的官方Plug-in时，他应该怎么做？把这个scenario放到一个商业Plug-in中去，可以想象会有多痛苦。
然而这还不是最大的问题，真正让我决心写这片文章的并不是版本兼容性的不尽如人意，而是Eclipse背后隐藏的一些不为人知的“秘密”。之所以加引号是因为它并不是真正的机密，而是各位Eclipse的*追逐者没有看到的地方。
前一段时间，我参加了一个Eclipse官方项目JWT的建设与讨论，因此可以更深入的探究Eclipse Community内部的一些东东。为了技术准备，我开始在EMF，GEF和GMF三个newsgroup上发贴，提问，并很据自己尝试使用的经验说出自己的感受。我以一个Eclipse爱好者和开发者的身份问了许多问题，得到了许多帮助，这些我不会省略。EMF是Eclipse Modeling Framework，GEF是Graphical Editing Framework，GEF是Graphical Modeling Framework，大家可以看出，它们都跟建模和图形操作有关，实际上，GMF还以来于EMF和GEF。这种依赖和重叠在Eclipse Community中比比皆是，所以我的问题是为什么不把它们做成一个项目。如果把这个问题退一步想，OK，现在是三个项目，那么它们可以无缝的交互衔接吗？答案是NO！这令我很惊讶，因为我觉得Eclipse作为一个设计如此之精巧的Platform理应有一个在后台一致的meta model，这也是.NET的做法。因此我在newsgroup上发贴说.NET有一致的meta model，就可以无缝的交互，为什么在Eclipse里面没有，为什么不设计一个，然后改变现在Eclipse及其Plug-in。
然后，令我伤心的事情发生了，我的Gmail收到了一封匿名信，信中充满了羞辱和漫骂。我很震惊，我从没想过会发生这样的事情。在我心中，Eclipse Community即使不算是氛围最好，也至少是个风气健康的地方。这封Email极大的打击了我对Eclipse Community的积极性，然而，随后的另一封Email却改变了我对Eclipse Community和整个Open Source的看法。那是在辱骂信的第二天，一位好心的Eclipse员工写Email，他告诉我，Eclipse本身，包括其重要的官方项目如EMF，GEF都在被一些大客户所以来，因此虽然你的建议是正确的，我们也无法作出任何改动。
就在那个时候，我明白了，所谓的Open Source，只是我们这些人的一厢情愿罢了。开源开源，开源并不仅仅是src-opened，当一个开源项目的代码积累的一定程度时，开放源代码其实没有任何意义，因为没有外人会读得懂它。我想，像MyEclipse这样以Plug-in为生的企业，一定花了不少钱在请Eclipse的人来培训和支持上面。开源更重要的是dev-opened，也就是说，左右开源项目发展方向的应该是任何一个参与开源项目的人的合理的、正确的idea，而不是依赖项目的客户。IBM现在的做法是把Eclipse的源代码开发出去，借此吸引广大的程序员为其免费开发Plug-in，而一些核心的东西，永远掌握在那么几个big fellow手中，他人无法触及。这就像一出滑稽的木偶戏，我们都是IBM手中的玩偶。
当我想到这些的时候，我开始问自己，世界上有真正的开源么？在当今的社会里，没有什么是永恒，只有商业价值，当我们再一次高呼开源的时候，是否应该想想自己是不是太疯狂了？
后记：这就是激起我学习.NET的直接原因。我关注.NET的有一阵子了，也告诉自己一定要学习.NET，然而无论怎样，这件事情算是导火索。
仅仅从IDE的使用者角度上讲，Eclipse可以算是最接近完美的。虽然在其2.1和3.0版本上，会有狂吃内存、容易死机等缺点，但是到了如今稳定发布的3.1.x版本，这种现象已经很少，在即将发布的3.2版本中，还提供了手工激活垃圾回收的功能，我之前在Weblogic workshop中使用过这种功能，觉得是很实用的。
我今天的话主要是作为一个Eclipse Plug-in & RCP开发者而说的。Eclipse号称是一个开放的平台，任何人可以对其进行任何方面的扩展，这就是我们现在看到的成百上千的Plug-in；同时，Eclipse也允许用户裁减掉除核心模块外的任意组件，来构建自己的应用，这就是RCP。然而，这看似完美的flexibility后面隐藏着一些问题和不为人所知的秘密。
Eclipse Plug-in & RCP Development最大的问题就是版本不兼容性，在任意一个版本中开发的Plug-in都无法保证能在其他版本中正确运行。因此我们会发现，即使像MyEclipse和SWT-Designer这样的商业Plug-in也摆脱不了版本的噩梦，它们不得不为2.1，3.0，3.1以及即将发布的3.2版本单独维护相应版本的Plug-in。同样的事情还发生在Plug-in之间的依赖上，如果一个Plug-in对其它一些Plug-in有所以来，那么必须保证使用了正确的版本，而其它Plug-in并不保证会版本兼容。所以想象一下，同学A很辛苦的写了一个以来于GEF的图形建模插件，花去了他6个月的时间，当他很高兴的宣布终于可以release的时候，他发现GEF有了新的版本，且与之前的版本不兼容。GEF是Eclipse的官方项目，同时Eclipse也推出了基于新GEF的官方Plug-in（不是图形建模），那么当同学B想同时使用同学A的Plug-in和Eclipse的官方Plug-in时，他应该怎么做？把这个scenario放到一个商业Plug-in中去，可以想象会有多痛苦。
然而这还不是最大的问题，真正让我决心写这片文章的并不是版本兼容性的不尽如人意，而是Eclipse背后隐藏的一些不为人知的“秘密”。之所以加引号是因为它并不是真正的机密，而是各位Eclipse的*追逐者没有看到的地方。
前一段时间，我参加了一个Eclipse官方项目JWT的建设与讨论，因此可以更深入的探究Eclipse Community内部的一些东东。为了技术准备，我开始在EMF，GEF和GMF三个newsgroup上发贴，提问，并很据自己尝试使用的经验说出自己的感受。我以一个Eclipse爱好者和开发者的身份问了许多问题，得到了许多帮助，这些我不会省略。EMF是Eclipse Modeling Framework，GEF是Graphical Editing Framework，GEF是Graphical Modeling Framework，大家可以看出，它们都跟建模和图形操作有关，实际上，GMF还以来于EMF和GEF。这种依赖和重叠在Eclipse Community中比比皆是，所以我的问题是为什么不把它们做成一个项目。如果把这个问题退一步想，OK，现在是三个项目，那么它们可以无缝的交互衔接吗？答案是NO！这令我很惊讶，因为我觉得Eclipse作为一个设计如此之精巧的Platform理应有一个在后台一致的meta model，这也是.NET的做法。因此我在newsgroup上发贴说.NET有一致的meta model，就可以无缝的交互，为什么在Eclipse里面没有，为什么不设计一个，然后改变现在Eclipse及其Plug-in。
然后，令我伤心的事情发生了，我的Gmail收到了一封匿名信，信中充满了羞辱和漫骂。我很震惊，我从没想过会发生这样的事情。在我心中，Eclipse Community即使不算是氛围最好，也至少是个风气健康的地方。这封Email极大的打击了我对Eclipse Community的积极性，然而，随后的另一封Email却改变了我对Eclipse Community和整个Open Source的看法。那是在辱骂信的第二天，一位好心的Eclipse员工写Email，他告诉我，Eclipse本身，包括其重要的官方项目如EMF，GEF都在被一些大客户所以来，因此虽然你的建议是正确的，我们也无法作出任何改动。
就在那个时候，我明白了，所谓的Open Source，只是我们这些人的一厢情愿罢了。开源开源，开源并不仅仅是src-opened，当一个开源项目的代码积累的一定程度时，开放源代码其实没有任何意义，因为没有外人会读得懂它。我想，像MyEclipse这样以Plug-in为生的企业，一定花了不少钱在请Eclipse的人来培训和支持上面。开源更重要的是dev-opened，也就是说，左右开源项目发展方向的应该是任何一个参与开源项目的人的合理的、正确的idea，而不是依赖项目的客户。IBM现在的做法是把Eclipse的源代码开发出去，借此吸引广大的程序员为其免费开发Plug-in，而一些核心的东西，永远掌握在那么几个big fellow手中，他人无法触及。这就像一出滑稽的木偶戏，我们都是IBM手中的玩偶。
当我想到这些的时候，我开始问自己，世界上有真正的开源么？在当今的社会里，没有什么是永恒，只有商业价值，当我们再一次高呼开源的时候，是否应该想想自己是不是太疯狂了？
后记：这就是激起我学习.NET的直接原因。我关注.NET的有一阵子了，也告诉自己一定要学习.NET，然而无论怎样，这件事情算是导火索。