Eclipse之各个版本的区别
经常用到的是前五个版本：
Eclipse IDE for Java EE Developers：是为J2EE开发的版本；
Eclipse Classic：是Eclipse的经典版本，没有安装任何插件，纯净版，需要什么插件可以自己安装，Java初学者建议使用该版本；
Eclipse IDE for Java Developers：适用于Java开发；
Eclipse IDE for C/C++ Developers：适用于C/C++开发；
Eclipse for Mobile Developers：适用于Java手机开发
Eclipse for RCP/Plug-in Developers：用于RCP和插件开发
那么它们之间到底有什么区别呢，最大的区别就是标题和解压包大小不同。下载解压后就会发现，不同的Eclipse版本之间就是plugins/features目录下的文件不同而已。
一个标准的Eclipse的，给它添加一些JEE开发需要的plugins，比如WTP，WST等等，它摇身一变就变成”Eclipse IDE for Java EE“了。其他的也一样。作为一个熟练的Eclipse使用者，选择哪一个都可以，需要的plugin可以从Eclipse官网轻松获取。
查看Eclipse的版本号：
1. 找到eclipse安装目录
2. 进入readme文件夹，打开readme_eclipse.html
3. readme_eclipse.html呈现的第二行即数字版本号，如：
Eclipse Project Release Notes
Release 4.3.0
Last revised May 29th, 2013
Eclipse各个版本简介（http://zh.wikipedia.org/wiki/Eclipse）
代号 平台版本 项目 主要版本发行日期 SR1发行日期 SR2发行日期
N/A 3.0 [1] N/A 2004年6月21日N/AN/A
N/A 3.1 N/A 2005年6月28日N/AN/A
Callisto 3.2 Callisto projects 2006年6月30日N/AN/A
Europa 3.3 Europa projects 2007年6月29日2007年9月28日2008年2月29日
Ganymede 3.4 Ganymede projects 2008年6月25日2008年9月24日2009年2月25日
Galileo 3.5 Galileo projects 2009年6月24日2009年9月25日2010年2月26日
Helios 3.6 Helios projects 2010年6月23日2010年9月24日2011年2月25日
Indigo 3.7 Indigo projects 2011年6月22日2011年9月23日2012年2月24日
Juno 4.2 [2] Juno projects 2012年6月27日2012年9月28日2013年2月22日
Kepler 4.3 Kepler projects 2013年6月26日2013年9月27日（计划）2014年2月28日（计划）
Luna 4.4 Luna projects 2014年6月25日（计划）N/AN/A
老版本老版本，仍被支持当前版本未来版本
2001年11月7日 ，Eclipse 1.0发布。半年之后，2002年6月27日Eclipse进入了2.0时代。2.0时代的Eclipse经历了2.0和2.1两个大的版本。其中2.0 在 之后又推出了2.0.1和2.0.2，而之后在2003年3月27日推出的2.1版本，也接连推出了2.1.1，2.1.2和2.1.3三个后续修订版本。
2004年6月25日 对Eclipse来说是一个值得记住的日子，进入3.0时代的Eclipse采用了OSGi运行时架构。这一 年 Eclipse基金会成立，这也标志着Eclipse即将进入一个新的时代。3.0后有两个小的修订版本3.0.1和3.0.2。详细的发布时间信息 请参 看Eclipse官网http://archive.eclipse.org/eclipse/downloads/index.php
2005年6月27日 Eclipse 3.1发布，之所以要特别提一下3.1，是因为从这个版本开始一直到还没有发布的3.5版，形成了一 个以木星卫星名称相关的系列。1610年，著名的科学 家伽利略通过对木卫1-木卫4的观察，提出了反驳地心说的证据，木卫1-木卫4因此也被称之为伽利 略四大卫星（木星还有很多之后发现的其它卫星）。这四大 卫星还被分别赋予了四个神话传说中人物的名字：
木卫1：IO，伊奥
木卫2：Europa，欧罗巴
木卫3：Ganymede，盖尼米德.(值得一提的是早于伽利略2000年前,有记录表明战国时期中国的甘德在公元前346年就已发现了木卫3)
木卫4：Callisto，卡里斯托
取这四个人的名字，一个很重要的原因可能就在于这四个人物都以俊美著称
但是Eclipse从3.1到3.4的命名（codename）并非按照木卫1-4的顺序，而是根据这四颗卫星距离木星从近到远的顺序，因 此 Eclipse 3.1就使用了木星已知卫星中第1近的木卫1——IO来命名，Eclipse 3.2就使用木卫4——Callisto距木星（所有 木卫中）第4近，Eclipse 3.3采用了木卫2——Europa（第6近），剩下最远的木卫3--Ganaymede就送给了 Eclipse 3.4。
下面是目前已知的版本代号：
Eclipse 3.1 版本代号 IO 【木卫1，伊奥】
Eclipse 3.2, 30-06-2006, Callisto projects, 版本代号 Callisto 【木卫四，卡里斯托 】
Eclipse 3.3, 29-06-2007, Europa projects, 版本代号 Eruopa 【木卫二，欧罗巴 】
Eclipse 3.4, 25-06-2008, Ganymede projects, 版本代号 Ganymede 【木卫三，盖尼米德 】
Eclipse 3.5, 24-06-2009, Galileo projects, 版本代号 Galileo 【伽利略】
Eclipse 3.6, 23-06-2010, Helios projects, 版本代号 Helios 【太阳神】
Eclipse 3.7, 22-06-2011, Indigo projects, 版本代号 Indigo 【靛青】[处于计划阶段]
Eclipse 4.2, 27-06-2012，Juno projects，版本代号Juno 【朱诺】（主神朱庇特的妻子）
Eclipse 4.3(计划中)，26 June 2013， 版本代号Kepler 【开普勒】
这里要详细介绍一下SDK版本和Runtime Binary的区别。
SDK，似乎是Software Development Toolkit的缩写，开发工具包，里面包含了source code。
Runtime Binary则仅仅是一个运行时环境。
换句话说，如果你下载的是Binary Runtime版本的Eclipse，在plugins目录下，只有”org.eclipse.ui.ide_3.6.2.M20101201-0800.jar“这些plugins，而SDK版本的则多了一些
”org.eclipse.ui.ide.source_3.6.2.M20101201-0800.jar“plugins，这些就是plugin对应的源码包。Eclipse 扩展了OSGI的MANIFEST文件，提供了一个自定义的Header，注明source plugin：
Eclipse-SourceBundle: org.eclipse.ui.ide;version="3.6.2.M20101201-0800
";roots:="."
很多时候，我们需要查看Eclipse Plartform 的API或者class source codes，对于SDK版本的eclipse，附带了source plugin的插件，eclipse会直接帮我们链接上，这对于开发人员来说是非常方便的。如果不幸你用的是Binary Runtime，Eclipse会提示你source 找不到，需要手动链接。
这时候选择一下带有source的包也行。不过建议去eclipse下载对应的source-plugin，放到plugins目录或者dropins目录下，重启下就可以查看源码了。
对于前面提到的下载版本，Eclipse Classic的是带有source的SDK版本，其他的好像都不带source，（估计是因为加了太多其他的plugin，节约空间）需要自己去下载。对于3.7版本的，所有的包都可以在这里http://download.eclipse.org/eclipse/downloads/drops/R-3.7-201106131736/index.php找到，其他版本类推。
个人一般使用Eclipse Classic，需要其他插件的，自己去配置好了。
SDK
SDK，Software Development Kit 的缩写，中文即“软件开发工具包”。广义上指辅助开发某一类软件的相关文档、范例和工具的集合。
SDK是一些被软件工程师用于为特定的软件包、软件框架、硬件平台、操作系统等创建应用软件的开发工具的集合，一般而言SDK即开发 Windows 平台下的应用程序所使用的SDK。它可以简单的为某个程序设计语言提供应用程序接口 API的一些文件，但也可能包括能与某种嵌入式系统通讯的复杂的硬件。一般的工具包括用于调试和其他用途的实用工具。SDK 还经常包括示例代码、支持性的技术注解或者其他的为基本参考资料澄清疑点的支持文档。
为了鼓励开发者使用其系统或者语言，许多 SDK 是免费提供的。软件工程师通常从目标系统开发者那里获得软件开发包，也可以直接从互联网下载，有时也被作为营销手段。例如，营销公司会免费提供构件SDK 以鼓励人们使用它，从而会吸引更多人由于能免费为其编程而购买其构件。
SDK 可能附带了使其不能在不兼容的许可证下开发软件的许可证。例如产品供应商提供一个专有的SDK可能与自由软件开发抵触。GPL能使SDK与专有软件开发近乎不兼容。LGPL下的SDK则没有这个问题。
API
API（Application Programming Interface，应用编程接口）其实就是操作系统留给应用程序的一个调用接口，应用程序通过调用操作系统的 API 而使操作系统去执行应用程序的命令（动作）。其实早在DOS时代就有 API 的概念，只不过那个时候的 API 是以中断调用的形式（INT 21h）提供的，在 DOS 下跑的应用程序都直接或间接的通过中断调用来使用操作系统功能，比如将 AH 置为 30h 后调用 INT 21h 就可以得到 DOS 操作系统的版本号。而在 Windows 中，系统 API 是以函数调用的方式提供的。同样是取得操作系统的版本号，在 Windows 中你所要做的就是调用 GetVersionEx() 函数。
可以这么说，DOS API 是“Thinking in 汇编语言”的，而 Windows API 则是“Thinking in 高级语言”的。
DOS API 是系统程序的一部分，他们与系统一同被载入内存并且可以通过中断矢量表找到他们的入口，那么 Windows API 呢？要说明白这个问题就不得不引入我们下面要介绍得这个概念——DLL。
DLL
DLL，即 Dynamic Link Library（动态链接库）。在windows环境下含有大量 .dll 格式的文件，这些文件就是动态链接库文件，其实也是一种可执行文件格式。跟 .exe 文件不同的是，.dll 文件不能直接执行，他们通常由 .exe 在执行时装入，内含有一些资源以及可执行代码等。其实 Windows 的三大模块就是以 DLL 的形式提供的（Kernel32.dll，User32.dll，GDI32.dll），里面就含有了 API 函数的执行代码。为了使用 DLL 中的 API 函数， 必须要有 API 函数的声明（.H）和其导入库（.LIB），导入库可以先这样理解：导入库是为了在 DLL 中找到 API 的入口点而使用的。
为了使用 API 函数，我们就要有跟 API 所对应的 .H 和 .LIB 文件，而 SDK 正是提供了一整套开发 Windows 应用程序所需的相关文件、范例和工具的“工具包”。
SDK 包含了使用 API 的必需资料，所以人们也常把仅使用 API 来编写 Windows 应用程序的开发方式叫做“SDK 编程”。而 API 和 SDK 是开发 Windows 应用程序所必需的东西，所以其它编程框架和类库都是建立在它们之上的，比如 VCL 和 MFC，虽然他们比起“SDK 编程”来有着更高的抽象度，但这丝毫不妨碍它们在需要的时候随时直接调用 API 函数
[plug-in 的基本结构]
每一个plug-in都用一个目录包起来, 而且起目录名也是有讲究的,比如plug-in的名字叫
edu.sjtu.bbs.eclipse,版本是1.0.0, 那这个目录名就是edu.sjtu.bbs.eclipse_1.0.0.
而且随便打开一个plugin目录,可以发现总有一个文件叫一个叫plugin.xml,这个文件对
于plugin来说十分重要, 它相当于定义了plugin的运行参数,没有这个,plugin无法启动,
就像你家的电冰箱如果不知道是用110V还是220V的,你也不敢乱往插座上插,所以总要有
个说明,这个说明就是plugin.xml. 至于这个文件有些什么具体结构,我想在以后介绍编
写插件的时候,我会详细介绍.
[什么是 feature]
feature是功能部件,它里面没有实际的运行的库,它只是eclipse用来管理plugins的一种
途径. 比如你家装了电灯,总要有开关控制把,比如大堂的灯有一个开关控制, 卧室的灯
也有一个开关控制, 它们分别用来控制灯的亮与灭.
同样,功能部件就是用来控制插件的启动与否. eclipse的update透视图可以设定各个功
能部件的启用或禁用状态, 所以你可以通过禁用功能部件,来禁止插件的启动. 这样有一
个好处,比如你装了很多插件在eclipse上,但是装的越多,加载就越多,启动也会变慢, 你
不信的话,可以玩玩wsad, 就知道我说的话不是假的了.
所以,我们可以把功能部件看作是插件或插件集合的开关, 用来控制插件的状态. 如果pl
ugins目录有插件没有被任何一个功能部件包络的话, 我称之为"野插件", 就是eclipse
启动,它也一定会启动, 就相当于没有开关, 电源一直连通一样.
Java中的Jar是如此的重要，以至于没有他们，我们就不能做出如此艺术的程序：封装、模块化、复用等等（无ant、marven方式） 。
今天，我就来整理一些有关项目中的jar包添加管理的方法以及常见问题的解决：
1、jar导入到我们的web项目中的classpath下
1）这里呢，一种方法是，直接用MyEclipse里自带的相关的项目jar包，右击项目“MyEclipse”菜单，选择对应的jar包就OK了，例 “Add Spring Capabilities”，并且可以设置Spring的一些配置信息，不错的可视化操作；
2）添加外部的jar包到web项目的lib包下，右击项目“Properties”-->“JavaBuild Path”-->“Libraries”选项卡（当然了，此操作下，不仅仅这一种添加jar包的方式）；
3）自己手动拷贝jar文件到项目的lib包下，具体操作只要把要添加的jar文件拷贝到MyEclipse中的workspace下的lib包里就好了；
至此，jar文件的添加就OK了，so easy!jar是加进去了，但这几种有什么区别，以后如何管理呢，接下来看看第2点
2、三种jar包添加方式，都行得通，很OK，那么要如何择决呢
1）这种方式，jar文件直接链接到MyEclipse的文件下，并没有拷贝到WEB-INF/lib目录下，不得用项目的发布、移植，可能会出现jar找不到的情形；
2）选择性比较的强，可以随意的加jar包，只要在你本机存在就可以了，链接的也是jar文件的绝对路径，缺点同1；
3）直接添加到WEB-INF/lib目录下，移植性强，可操作性也强。
总而言之，第3）种jar包导入方式，个人觉得还是不错的了！
3、显示/隐藏项目里的jar文件
不同的开发人员，都有着他固有的习惯，有的人就觉得把jar包显示在开发视图里太碍眼，看起来不舒服，复杂。而有些人呢，他就想研究看看到底运用了哪些技 术，导了哪些jar包，并且通过点击jar包里的class文件直接查看源码（假设先前有导入源码）。所以呢，这里就牵涉到了一个jar包的显示与隐藏问 题了：在Package Explorer这个窗体中，右上角有个下拉小三角，点击-->“Filters”-->“Name filter patterns（matching names will be hidden）”，在这一选项下填有*.jar，勾上复选框即表示这一类的文件不显示，多个类型之间可用“,”分隔。
4、在Eclipse工程的Java Build Path设置中，可以通过加入第三方的jar包，但是，我发现是有好几种方法来完成这个操作的，有“Add jars”，“Add Externel jars”，“Add library”，“Add Classes Loader”等，这几种方式有什么区别吗？
add jar是表示从你的工程里添加JAR，前提是你把jar已经放到自己的工程目录里。
add external jar表示这个jar的位置需要URI来定位，需要给出全路径。
add library 是一些已经定义好的jar的集合，因为它们经常是一起用，所以简化了些操作，比如你做RCP开发的时候就会有个plugin library包含了运行工程所需要的基本插件。
Add classes Loader －－ 这个应该是 add class folder吧？这个跟添加jar是一个意思，就是告诉ClassLoader去哪找class
5．当出现java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderListener类似这种找不到Listener的异常 时，要切记spring的jar包一定要放在工程的lib下这样才能避免这个错误的发生。
补充：虽说无论用什么方式导入包在本地运行都是一样的，但实事上我运行时，有的只有Java Build Path才起作用，有的只有导入到lib下才行。用Java Build Path导入包和把包复制到lib下是有区别的，它俩其实不会冲突，也没有什么关系的，Java Build Path是我们编译需要的包，在比如在import ***.***.***时如果没用Java Build Path导入包的话类里面就有红叉，说不识别这个类；导入到lib下是程序运行时需要的包，即便用Java Build Path导入过的包，没放到lib下，运行项目时会出现ClassNotFoundException的异常。
Eclipse IDE for Java EE Developers：是为J2EE开发的版本；
Eclipse Classic：是Eclipse的经典版本，没有安装任何插件，纯净版，需要什么插件可以自己安装，Java初学者建议使用该版本；
Eclipse IDE for Java Developers：适用于Java开发；
Eclipse IDE for C/C++ Developers：适用于C/C++开发；
Eclipse for Mobile Developers：适用于Java手机开发
Eclipse for RCP/Plug-in Developers：用于RCP和插件开发
那么它们之间到底有什么区别呢，最大的区别就是标题和解压包大小不同。下载解压后就会发现，不同的Eclipse版本之间就是plugins/features目录下的文件不同而已。
一个标准的Eclipse的，给它添加一些JEE开发需要的plugins，比如WTP，WST等等，它摇身一变就变成”Eclipse IDE for Java EE“了。其他的也一样。作为一个熟练的Eclipse使用者，选择哪一个都可以，需要的plugin可以从Eclipse官网轻松获取。
查看Eclipse的版本号：
1. 找到eclipse安装目录
2. 进入readme文件夹，打开readme_eclipse.html
3. readme_eclipse.html呈现的第二行即数字版本号，如：
Eclipse Project Release Notes
Release 4.3.0
Last revised May 29th, 2013
Eclipse各个版本简介（http://zh.wikipedia.org/wiki/Eclipse）
代号 平台版本 项目 主要版本发行日期 SR1发行日期 SR2发行日期
N/A 3.0 [1] N/A 2004年6月21日N/AN/A
N/A 3.1 N/A 2005年6月28日N/AN/A
Callisto 3.2 Callisto projects 2006年6月30日N/AN/A
Europa 3.3 Europa projects 2007年6月29日2007年9月28日2008年2月29日
Ganymede 3.4 Ganymede projects 2008年6月25日2008年9月24日2009年2月25日
Galileo 3.5 Galileo projects 2009年6月24日2009年9月25日2010年2月26日
Helios 3.6 Helios projects 2010年6月23日2010年9月24日2011年2月25日
Indigo 3.7 Indigo projects 2011年6月22日2011年9月23日2012年2月24日
Juno 4.2 [2] Juno projects 2012年6月27日2012年9月28日2013年2月22日
Kepler 4.3 Kepler projects 2013年6月26日2013年9月27日（计划）2014年2月28日（计划）
Luna 4.4 Luna projects 2014年6月25日（计划）N/AN/A
老版本老版本，仍被支持当前版本未来版本
2001年11月7日 ，Eclipse 1.0发布。半年之后，2002年6月27日Eclipse进入了2.0时代。2.0时代的Eclipse经历了2.0和2.1两个大的版本。其中2.0 在 之后又推出了2.0.1和2.0.2，而之后在2003年3月27日推出的2.1版本，也接连推出了2.1.1，2.1.2和2.1.3三个后续修订版本。
2004年6月25日 对Eclipse来说是一个值得记住的日子，进入3.0时代的Eclipse采用了OSGi运行时架构。这一 年 Eclipse基金会成立，这也标志着Eclipse即将进入一个新的时代。3.0后有两个小的修订版本3.0.1和3.0.2。详细的发布时间信息 请参 看Eclipse官网http://archive.eclipse.org/eclipse/downloads/index.php
2005年6月27日 Eclipse 3.1发布，之所以要特别提一下3.1，是因为从这个版本开始一直到还没有发布的3.5版，形成了一 个以木星卫星名称相关的系列。1610年，著名的科学 家伽利略通过对木卫1-木卫4的观察，提出了反驳地心说的证据，木卫1-木卫4因此也被称之为伽利 略四大卫星（木星还有很多之后发现的其它卫星）。这四大 卫星还被分别赋予了四个神话传说中人物的名字：
木卫1：IO，伊奥
木卫2：Europa，欧罗巴
木卫3：Ganymede，盖尼米德.(值得一提的是早于伽利略2000年前,有记录表明战国时期中国的甘德在公元前346年就已发现了木卫3)
木卫4：Callisto，卡里斯托
取这四个人的名字，一个很重要的原因可能就在于这四个人物都以俊美著称
但是Eclipse从3.1到3.4的命名（codename）并非按照木卫1-4的顺序，而是根据这四颗卫星距离木星从近到远的顺序，因 此 Eclipse 3.1就使用了木星已知卫星中第1近的木卫1——IO来命名，Eclipse 3.2就使用木卫4——Callisto距木星（所有 木卫中）第4近，Eclipse 3.3采用了木卫2——Europa（第6近），剩下最远的木卫3--Ganaymede就送给了 Eclipse 3.4。
下面是目前已知的版本代号：
Eclipse 3.1 版本代号 IO 【木卫1，伊奥】
Eclipse 3.2, 30-06-2006, Callisto projects, 版本代号 Callisto 【木卫四，卡里斯托 】
Eclipse 3.3, 29-06-2007, Europa projects, 版本代号 Eruopa 【木卫二，欧罗巴 】
Eclipse 3.4, 25-06-2008, Ganymede projects, 版本代号 Ganymede 【木卫三，盖尼米德 】
Eclipse 3.5, 24-06-2009, Galileo projects, 版本代号 Galileo 【伽利略】
Eclipse 3.6, 23-06-2010, Helios projects, 版本代号 Helios 【太阳神】
Eclipse 3.7, 22-06-2011, Indigo projects, 版本代号 Indigo 【靛青】[处于计划阶段]
Eclipse 4.2, 27-06-2012，Juno projects，版本代号Juno 【朱诺】（主神朱庇特的妻子）
Eclipse 4.3(计划中)，26 June 2013， 版本代号Kepler 【开普勒】
这里要详细介绍一下SDK版本和Runtime Binary的区别。
SDK，似乎是Software Development Toolkit的缩写，开发工具包，里面包含了source code。
Runtime Binary则仅仅是一个运行时环境。
换句话说，如果你下载的是Binary Runtime版本的Eclipse，在plugins目录下，只有”org.eclipse.ui.ide_3.6.2.M20101201-0800.jar“这些plugins，而SDK版本的则多了一些
”org.eclipse.ui.ide.source_3.6.2.M20101201-0800.jar“plugins，这些就是plugin对应的源码包。Eclipse 扩展了OSGI的MANIFEST文件，提供了一个自定义的Header，注明source plugin：
Eclipse-SourceBundle: org.eclipse.ui.ide;version="3.6.2.M20101201-0800
";roots:="."
很多时候，我们需要查看Eclipse Plartform 的API或者class source codes，对于SDK版本的eclipse，附带了source plugin的插件，eclipse会直接帮我们链接上，这对于开发人员来说是非常方便的。如果不幸你用的是Binary Runtime，Eclipse会提示你source 找不到，需要手动链接。
这时候选择一下带有source的包也行。不过建议去eclipse下载对应的source-plugin，放到plugins目录或者dropins目录下，重启下就可以查看源码了。
对于前面提到的下载版本，Eclipse Classic的是带有source的SDK版本，其他的好像都不带source，（估计是因为加了太多其他的plugin，节约空间）需要自己去下载。对于3.7版本的，所有的包都可以在这里http://download.eclipse.org/eclipse/downloads/drops/R-3.7-201106131736/index.php找到，其他版本类推。
个人一般使用Eclipse Classic，需要其他插件的，自己去配置好了。
SDK
SDK，Software Development Kit 的缩写，中文即“软件开发工具包”。广义上指辅助开发某一类软件的相关文档、范例和工具的集合。
SDK是一些被软件工程师用于为特定的软件包、软件框架、硬件平台、操作系统等创建应用软件的开发工具的集合，一般而言SDK即开发 Windows 平台下的应用程序所使用的SDK。它可以简单的为某个程序设计语言提供应用程序接口 API的一些文件，但也可能包括能与某种嵌入式系统通讯的复杂的硬件。一般的工具包括用于调试和其他用途的实用工具。SDK 还经常包括示例代码、支持性的技术注解或者其他的为基本参考资料澄清疑点的支持文档。
为了鼓励开发者使用其系统或者语言，许多 SDK 是免费提供的。软件工程师通常从目标系统开发者那里获得软件开发包，也可以直接从互联网下载，有时也被作为营销手段。例如，营销公司会免费提供构件SDK 以鼓励人们使用它，从而会吸引更多人由于能免费为其编程而购买其构件。
SDK 可能附带了使其不能在不兼容的许可证下开发软件的许可证。例如产品供应商提供一个专有的SDK可能与自由软件开发抵触。GPL能使SDK与专有软件开发近乎不兼容。LGPL下的SDK则没有这个问题。
API
API（Application Programming Interface，应用编程接口）其实就是操作系统留给应用程序的一个调用接口，应用程序通过调用操作系统的 API 而使操作系统去执行应用程序的命令（动作）。其实早在DOS时代就有 API 的概念，只不过那个时候的 API 是以中断调用的形式（INT 21h）提供的，在 DOS 下跑的应用程序都直接或间接的通过中断调用来使用操作系统功能，比如将 AH 置为 30h 后调用 INT 21h 就可以得到 DOS 操作系统的版本号。而在 Windows 中，系统 API 是以函数调用的方式提供的。同样是取得操作系统的版本号，在 Windows 中你所要做的就是调用 GetVersionEx() 函数。
可以这么说，DOS API 是“Thinking in 汇编语言”的，而 Windows API 则是“Thinking in 高级语言”的。
DOS API 是系统程序的一部分，他们与系统一同被载入内存并且可以通过中断矢量表找到他们的入口，那么 Windows API 呢？要说明白这个问题就不得不引入我们下面要介绍得这个概念——DLL。
DLL
DLL，即 Dynamic Link Library（动态链接库）。在windows环境下含有大量 .dll 格式的文件，这些文件就是动态链接库文件，其实也是一种可执行文件格式。跟 .exe 文件不同的是，.dll 文件不能直接执行，他们通常由 .exe 在执行时装入，内含有一些资源以及可执行代码等。其实 Windows 的三大模块就是以 DLL 的形式提供的（Kernel32.dll，User32.dll，GDI32.dll），里面就含有了 API 函数的执行代码。为了使用 DLL 中的 API 函数， 必须要有 API 函数的声明（.H）和其导入库（.LIB），导入库可以先这样理解：导入库是为了在 DLL 中找到 API 的入口点而使用的。
为了使用 API 函数，我们就要有跟 API 所对应的 .H 和 .LIB 文件，而 SDK 正是提供了一整套开发 Windows 应用程序所需的相关文件、范例和工具的“工具包”。
SDK 包含了使用 API 的必需资料，所以人们也常把仅使用 API 来编写 Windows 应用程序的开发方式叫做“SDK 编程”。而 API 和 SDK 是开发 Windows 应用程序所必需的东西，所以其它编程框架和类库都是建立在它们之上的，比如 VCL 和 MFC，虽然他们比起“SDK 编程”来有着更高的抽象度，但这丝毫不妨碍它们在需要的时候随时直接调用 API 函数
[plug-in 的基本结构]
每一个plug-in都用一个目录包起来, 而且起目录名也是有讲究的,比如plug-in的名字叫
edu.sjtu.bbs.eclipse,版本是1.0.0, 那这个目录名就是edu.sjtu.bbs.eclipse_1.0.0.
而且随便打开一个plugin目录,可以发现总有一个文件叫一个叫plugin.xml,这个文件对
于plugin来说十分重要, 它相当于定义了plugin的运行参数,没有这个,plugin无法启动,
就像你家的电冰箱如果不知道是用110V还是220V的,你也不敢乱往插座上插,所以总要有
个说明,这个说明就是plugin.xml. 至于这个文件有些什么具体结构,我想在以后介绍编
写插件的时候,我会详细介绍.
[什么是 feature]
feature是功能部件,它里面没有实际的运行的库,它只是eclipse用来管理plugins的一种
途径. 比如你家装了电灯,总要有开关控制把,比如大堂的灯有一个开关控制, 卧室的灯
也有一个开关控制, 它们分别用来控制灯的亮与灭.
同样,功能部件就是用来控制插件的启动与否. eclipse的update透视图可以设定各个功
能部件的启用或禁用状态, 所以你可以通过禁用功能部件,来禁止插件的启动. 这样有一
个好处,比如你装了很多插件在eclipse上,但是装的越多,加载就越多,启动也会变慢, 你
不信的话,可以玩玩wsad, 就知道我说的话不是假的了.
所以,我们可以把功能部件看作是插件或插件集合的开关, 用来控制插件的状态. 如果pl
ugins目录有插件没有被任何一个功能部件包络的话, 我称之为"野插件", 就是eclipse
启动,它也一定会启动, 就相当于没有开关, 电源一直连通一样.
Java中的Jar是如此的重要，以至于没有他们，我们就不能做出如此艺术的程序：封装、模块化、复用等等（无ant、marven方式） 。
今天，我就来整理一些有关项目中的jar包添加管理的方法以及常见问题的解决：
1、jar导入到我们的web项目中的classpath下
1）这里呢，一种方法是，直接用MyEclipse里自带的相关的项目jar包，右击项目“MyEclipse”菜单，选择对应的jar包就OK了，例 “Add Spring Capabilities”，并且可以设置Spring的一些配置信息，不错的可视化操作；
2）添加外部的jar包到web项目的lib包下，右击项目“Properties”-->“JavaBuild Path”-->“Libraries”选项卡（当然了，此操作下，不仅仅这一种添加jar包的方式）；
3）自己手动拷贝jar文件到项目的lib包下，具体操作只要把要添加的jar文件拷贝到MyEclipse中的workspace下的lib包里就好了；
至此，jar文件的添加就OK了，so easy!jar是加进去了，但这几种有什么区别，以后如何管理呢，接下来看看第2点
2、三种jar包添加方式，都行得通，很OK，那么要如何择决呢
1）这种方式，jar文件直接链接到MyEclipse的文件下，并没有拷贝到WEB-INF/lib目录下，不得用项目的发布、移植，可能会出现jar找不到的情形；
2）选择性比较的强，可以随意的加jar包，只要在你本机存在就可以了，链接的也是jar文件的绝对路径，缺点同1；
3）直接添加到WEB-INF/lib目录下，移植性强，可操作性也强。
总而言之，第3）种jar包导入方式，个人觉得还是不错的了！
3、显示/隐藏项目里的jar文件
不同的开发人员，都有着他固有的习惯，有的人就觉得把jar包显示在开发视图里太碍眼，看起来不舒服，复杂。而有些人呢，他就想研究看看到底运用了哪些技 术，导了哪些jar包，并且通过点击jar包里的class文件直接查看源码（假设先前有导入源码）。所以呢，这里就牵涉到了一个jar包的显示与隐藏问 题了：在Package Explorer这个窗体中，右上角有个下拉小三角，点击-->“Filters”-->“Name filter patterns（matching names will be hidden）”，在这一选项下填有*.jar，勾上复选框即表示这一类的文件不显示，多个类型之间可用“,”分隔。
4、在Eclipse工程的Java Build Path设置中，可以通过加入第三方的jar包，但是，我发现是有好几种方法来完成这个操作的，有“Add jars”，“Add Externel jars”，“Add library”，“Add Classes Loader”等，这几种方式有什么区别吗？
add jar是表示从你的工程里添加JAR，前提是你把jar已经放到自己的工程目录里。
add external jar表示这个jar的位置需要URI来定位，需要给出全路径。
add library 是一些已经定义好的jar的集合，因为它们经常是一起用，所以简化了些操作，比如你做RCP开发的时候就会有个plugin library包含了运行工程所需要的基本插件。
Add classes Loader －－ 这个应该是 add class folder吧？这个跟添加jar是一个意思，就是告诉ClassLoader去哪找class
5．当出现java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderListener类似这种找不到Listener的异常 时，要切记spring的jar包一定要放在工程的lib下这样才能避免这个错误的发生。
补充：虽说无论用什么方式导入包在本地运行都是一样的，但实事上我运行时，有的只有Java Build Path才起作用，有的只有导入到lib下才行。用Java Build Path导入包和把包复制到lib下是有区别的，它俩其实不会冲突，也没有什么关系的，Java Build Path是我们编译需要的包，在比如在import ***.***.***时如果没用Java Build Path导入包的话类里面就有红叉，说不识别这个类；导入到lib下是程序运行时需要的包，即便用Java Build Path导入过的包，没放到lib下，运行项目时会出现ClassNotFoundException的异常。
Eclipse官方文档：http://help.eclipse.org/mars/index.jsp
