jdk1.7(java se development kit7) 7u67 64位 官方正式安装版
jdk1.7 64位下载
软件大小：129MB
软件语言：简体中文
软件类型：
软件授权：免费软件
更新时间：
软件类别：编程工具
软件官网：
网友评分：
应用平台：
2.5GB | 简体中文
1.5GB | 简体中文
1.2MB | 简体中文
137.8MB | 简体中文
825MB | 简体中文
78.3MB | 简体中文
200MB | 简体中文
156.3MB | 英文软件
1.17GB | 简体中文
下载错误？
jdk1.7(java se development kit7) 7u67 64位 官方正式安装版笔者在观看过Devoxx关于Jigsaw的一段演示后，我很兴奋，觉得它应该会是针对复杂类路径版本问题和JAR陷阱等问题的解决方案。开发者最终能够使用他们所期望的任何Xalan版本，而无需被迫使用授权机制。不幸的是，通往更加有效的模块系统的征途并不是很清晰。 在研究确实问题之前，我们先来看一些基本概念： 模块化 模块化 是解决复杂性问题很重要的工具。把应用分成不同的部分(模块、库、包、子项目和组件)，再分别进行计算，是行之有效的方式。模块化的最终目的是能定义出一套API用于模块间的沟通。 如果模块间所有的通讯都只通过这种API来实现，那么模块是松耦合的，于是： 改变某个模块的实现会很容易 开发和测试各个模块能很容易独立开来 面向对象模式也是类似的道理。在OOP中，理想的状况是拥有大量小的、可重用的、简单并分离良好的对象。在模块系统中，就可以完美地实现小的、可重用的、简单并分离良好的模块。它们的想法和最初的动机是完全一样的，只是规模有所不同。 逻辑分离 传统上，Java中有两种办法来实现模块化。逻辑分离是最自然的方式。它包括将应用程序分割成逻辑模块(子项目)，最后再部署成一个完整的应用。通过定义正确的包来实现逻辑分离也是可能的，但更通用的办法是把应用分割成一些存档文件(也就是JAR包)。逻辑分离里能促进模块的重用，有助实现模块间的松耦合。你甚至有可能定义一个API，然后宣布所有模块间的通讯都要通过这个给定的API来实现。这样的想法有个大问题，那就是你很难强破大家都采用这种限制性用法，而且没有任何一种机制能够确保这个API的用法。你也没法把那些应用通过给定模块来使用的类和作为公共API一部分的类区分开来。如果一个类是“公共的”，那它就可以被任何其他类使用，无论调用它的那个类属于哪个模块。另一方面，受保护的或者包级可见性的类在其模块内部的调用也有限制。通常来说，涵盖了一些包以及包中类的模块需要能够互相调用。因此即使某个应用是由一些逻辑模块组成，但如果这些模块是耦合的，那么分离也根本没有用处。 物理分离 另外一个传统的办法就是物理上的分离。你可以通过将应用分割成不同的组件，然后把每个组件部署到不同的JVM上而实现分离。这些组件间通过远程访问机制进行通讯，比如RMI、CORBA或者WebServices。物理分离实现了分离，也实现了松耦合，但负面影响是开支很大。为实现分离而专门采用远程访问机制，有点杀鸡用牛刀的味道。这会增加开发和部署不必要的复杂性，性能上所受到的影响也不能忽视的。 模块系统 模块系统 的作用位于逻辑分离和物理分离之间。它强调模块分离，但各个模块仍然部署到同一个JVM中，而且模块间的通讯由简单传统的方法调用组成，因此不会有运行时的开支负担。在Java生态系统中最流行的模块框架是OSGi。它是一个成熟的规范，具有几个不同的实现。在OSGi中，模块被称作bundle，每个bundle等同于一个JAR。每个bundle也包含一个META-INF/MANIFEST.MF文件，这个文件会宣布导出哪些包(package)以及导入哪些包。只有那些导出包中的类才能被其他bundle所使用，而其他包都只面向包的内部成员，包里的类也只能在自身bundle中使用。 比如下面这个声明： Manifest-Version: 1.0 Import-Package: net.krecan.spring.osgi.common Export-Package: net.krecan.spring.osgi.dao Bundle-Version: 1.0.0 Bundle-Name: demo-spring-osgi-dao Bundle-SymbolicName:net.krecan.spring-osgi.demo-spring-osgi-dao 这个规范指定了名叫demo-spring-osgi-dao的bundle，它要导入包名为net.krecan.spring.osgi.common中的类，并导出包名为net.krecan.spring.osgi.dao中的类。换句话说，这段声明表明其他模块只能使用net.krecan.spring.osgi.dao包。相反地，这个模块要使用的则只是net.krecan.spring.osgi.common包，而且也可能会由OSGi来提供专门的模块负责导出这个包。当然你完全可以在导入和导出声明中定义多个包名。 需要特别注意的是，OSGi的模块化是构建在Java之上的。它不是语言的一部分!这里的模块分离虽然可以由GUI来执行，但不可以由编译器来执行。运行基于OSGi的应用时，你会需要一个OSGi的容器。这个容器可能是运行时环境的一部分，比如在SpringDM服务器中，也可能是嵌入在应用程序中的。这个容器不仅负责提供分离，也提供了其他诸如安全、模块管理和生命周期管理之类的服务。OSGi还提供大量其他有趣的特性，但这些并不是本文所要关注的。 关于JSR-277曾经有很多争议，这个JSR一度跟OSGi有部分重复。连续好几个月，双方的专家都极力辩论谁更优秀，直到JSR-277被宣布放弃，而新的模块系统将会是Java7的一部分。 JSR-294 这个新的模块系统的第一部分就是JSR-294，即所谓的超级包。也正是这个规范阐释了Java语言的模块部分的概念。 JSR-294 引入了新的可见性关键字“module”。如果一个成员拥有这样的可见性，那就意味着它只对同一模块中的成员可见。它会创建一个内部的API，只有模块本身能调用。就此看来，“public”关键字应当只在声明一个公共的API时才用。而在其他情况下，应当使用“module”或者有更多限制的可见性关键字。当然，一旦语言中有了“module”关键字，那么模块之间的可见性限制将会由编译器来负责检查。 JSR-294 也允许定义依赖性。你可以在某个给定版本中，定义某个模块依赖于另一模块。比如： //org/netbeans/core/module-info.java @Version("7.0") @ImportModule(name="java.se.core", version="1.7+") module org.netbeans. 最后一句表明“org.netbeans.core”模块依赖“java.se.core”的1.7版本或者更高。这类似于Maven的依赖性或者OSGi的导入。你也可以暂时不要管这些语法，因为将来语法可能会另有变化。重要的是，这儿的依赖是在module-info.java中定义的，会被编译成class文件。而OSGi中，依赖则是在普通的文本文件中定义的。 Jigsaw项目 Jigsaw项目 是这个新模块系统的第二部分。我预计它会是JSR-294特定于Sun的实现，也会是SunJDK的模块化实现。既然创建完整的JDK模块化是有必要的，Sun就希望把标准库分装成模块。这直接简化了JRE中的内容整合。整个JRE除了Swing之外的所有内容因此都能够在移动设备上运行。它还有可能为语言引入新的标准API，而无需再等待整个平台的新版本发布。目前看起来，这个项目绝对有希望实现。 但我对此还有个担忧，那就是，ahref="http://blogs.sun.com/mr/entry/jigsaw">专有的Jigsaw和JSR标准之间的关系并不清晰，正如MarkReinhold所说的： 对Jigsaw的投入无疑会创建出一个简单的、低层次的模块系统，它的设计会严格地朝着JDK模块化的目标而发展。开发人员可以把这个模块系统运用到他们的代码中去，Sun对这个模块系统也会是绝对的支持，但它不会是JavaSE7平台规范的官方部分，也可能不会被其他SE 7实现所支持。 这段话说的不是很清楚，当中有很多疑问。他的意思是说创建的模块只能在SunJRE中运行吗?还是想说，如果开发者写了“@ImportModule(name="java.se.core",version="1.7+")”，那么这个模块只能在SunJRE中运行，而不能在IBMJRE环境中运行吗?或者他的意思是不是说Sun会以某种方式把它的JRE分割成许多模块，而Oracle会选择另外的方式去分割吗?(译者注：至少现在看来，不太会有这样的可能了，因为Oracle刚刚收购了Sun)。我们希望都不是，因为还有“编写一次，到处运行”的原则。 细究起来问题更多。我们并不清楚Jigsaw项目的主要目标是什么。据项目本身所宣布的主要目标来看，它要实现的是SunJRE的模块化，但如果纯粹是要实现模块化的话，就不需要对语言做任何改变。Sun可以对JRE进行模块化，而不修改Java语言本身。 这些语言上的变化会不会成为SunJRE模块化带来的副产品?如果是，那就彻底错了!语言变化必须是一等公民，而不是专属的副产品。 依赖 我的另外一个担心在于依赖性。如果依赖性由模块系统来管理，那就不再需要classpath了。一方面这很不错，因为classpath经常会导致所谓的JAR地狱问题。但另一方面，classpath也是极度灵活的，我恐怕这种灵活性是不可能由一个静态的模块依赖能够拥有的。让我们来看看为什么： 部署时依赖 Java中有两种类路径(classpath)。一个是构建路径(buildpath)，它用在构建时。另外一个是类路径，用在运行时。两者几乎相同，但又不完全是。经典的例子就是JDBC驱动。在构建时，你不需要指定JDBC驱动，JDBC接口是Java核心库的一部分。但在运行时，你就有必要确保类路径中有JDBC的驱动。如果某个编程人员需要修改数据库连接，他只需要在配置文件中修改驱动类的名称，并把驱动jar文件添加到类路径就可以了。如果所有的依赖需要在编译时指定，开发者很明显无法做到这点。当然，在JavaEE中，他可以使用JNDI数据源，但在JavaSE中没有类似的东西，一旦修改JDBC驱动，就不得不重新编译整个应用，这明显很不靠谱。 通常来说，重新编译不太可能。在一些组织中，最终的应用是由所谓的应用装配器的模块组装而成的。开发者没有源代码，他只是把一些JAR放在一起，修改一下配置文件，然后创建最终的包。应用装配器的角色甚至在JavaEE的规范中都有提到。 可选依赖 类似的问题就是可选依赖。我们假设我们要做一个像log4j这样的日志框架。这个库可以对JMS记录日志，因此JMS包必须涵盖在构建路径中。但99%的用户并不使用JMS日志，因此他们不需要把依赖放在类路径中。对于这样的问题，必须要有某种机制来解决。我们需要一个库来构建这个模块，这种依赖对最终用户来说则是可选的。当然，完美的情况是，JMS功能会是个独立模块，可我们并不是生活在一个完美的世界，而且某些时候用这种方式来分割项目也不太现实。 依赖冲突 另外一个大问题就是依赖冲突。如果你用过Maven，就不难理解我在说什么了。大多数企业应用都会用到大约十几个第三方库，它们之间的互相依赖有时就会发生冲突。比如，一个开发者想要使用Hibernate，它依赖commons-collections2.1.1，他还想用commons-dbcp，却需要依赖commons-collections2.1。开发者自己或者应用装配器需要决定怎样解决此类问题。他要么决定在应用中只用某个特定版本的库，要么决定在应用的不同部分采用不同版本的类库。重要的是，这些问题无法自行解决。它总需要由某个了解各个模块在应用中如何运作的人来作决定，而这个人又要能识别不同版本间可能存在的不兼容性。 关于Java依赖性，还有许多东西本文不展开讨论，但需要铭记的一点是，它们不是静态的。一个应用的构件可能采用了某套类库，而它的运行却需要另外一套完全不同的库。所有模块系统必须以某种方式把这些问题解决掉。Maven具有大量关于如何配置依赖，以及如何处理依赖冲突等等的选项，但它只是个构建系统。最糟糕的情况是需要手动配置类路径。OSGi则是另外一种情形。它只处理运行时(部署时)依赖，不管构建时。新的Java模块系统会同时支持构建时和运行时依赖(我猜测)，甚至会把既有的复杂问题变得愈加复杂。 总结 当然，我相信Sun的工程师并不想要破坏Java本身。我想他们也是为了让Java变得更好、更易于使用，但我担心政治和市场因素会远大于技术影响。再次声明，这不会仅仅是个API的变化或者是特定于Sun的变化。这会是语言级别的变化!一旦语言被改变了，一旦添加了“module”关键字，就不会再有回头路。到那时，Java中会有个模块系统，无论喜不喜欢，我们都非得要用到这个模块系统。真得很难想象带模块化的JVM，也很难想像Java语言中会有个“module”关键字，而我们还要在这之上使用OSGi。 编辑推荐 Java 7路线图更新 未包含闭包特性 Java 7.0中值得期待的新功能预览 Java程序开发中的简单内存分析
周一至周日 9:00-18:00（全国免费咨询）
您正在使用移动设备访问,是否切换到手机版?
欢迎访问APISTORE
免费试用,在线咨询
工作时间:& 9:00-24:00Java SE Development Kit(JDK7) 1.7.0 7u67 官方版
当前位置：
请输入预约的手机号码
3412人已预约此游戏
第七下载这个版本的Java平台Java SE Development Kit，是标准版的开发工具包（jdk）。JDK是用于构建应用程序，应用程序开发环境，使用Java编程语言和组件。JDK包括用于开发和测试用Java编程语言和Java平台上运行程序的工具。
如果你想开发Java的应用程序，下载Java开发工具包（Java Development Kit），或JDK。你想运行Java程序，还是要开发Java程序？如果你想运行Java程序，而不是开发他们，下载Java运行时环境（Java Runtime Environment），或JRE。JDK包含JRE，所以你不必单独下载两个。
JDK包含的基本组件包括：
javac & 编译器，将源程序转成字节码
jar & 打包工具，将相关的类文件打包成一个文件
javadoc & 文档生成器，从源码注释中提取文档
jdb & debugger，查错工具
java & 运行编译后的java程序（.class后缀的）
appletviewer：小程序浏览器，一种执行HTML文件上的Java小程序的Java浏览器。
Javah：产生可以调用Java过程的C过程，或建立能被Java程序调用的C过程的头文件。
Javap：Java反汇编器，显示编译类文件中的可访问功能和数据，同时显示字节代码含义。
Jconsole: Java进行系统调试和监控的工具
JDK常用的包
java.lang： 这个是系统的基础类，比如String等都是这里面的，这个包是唯一一个可以不用引入(import)就可以使用的包。
java.io： 这里面是所有输入输出有关的类，比如文件操作等。
java.nio：为了完善io包中的功能，提高io包中性能而写的一个新包 ，例如NIO非堵塞应用java.net: 这里面是与网络有关的类，比如URL，URLConnection等。
java.util： 这个是系统辅助类，特别是集合类Collection，List，Map等。
java.sql： 这个是数据库操作的类，Connection， Statement，ResultSet等。
javax.servlet：这个是JSP，Servlet等使用到的类。
JDK常用基本工具编辑
1. Javac: Java源程序编译器，将Java源代码转换成字节码。2. Java: Java解释器，直接从字节码文件，又称为类文件.执行Java应用程序的字节代码。3. appletviewer.exe Java applet浏览器。appletviewer命令可在脱离万维网浏览器环境的情况下运行applet4. jar: java应用程序打包工具，可将多个类文件合并为单个JAR归档文件。5.Javadoc: Java API文档生成器从Java源程序代码注释中提取文档，生成API文档HTML页。6. jdb: Java调试器(debugger),可以逐行执行程序.设置断点和检查变Md
59.44 MB69.27 MB
其他下载地址：
7.09 MB2.69 MB102.98 MB210.36 MB320 MB15.32 MB213.62 MB526 KB240 KB240 KB240 KB12.3 MB
240 KB316.69 MB4.43 MB38.59 MB19.86 MB3.25 GB3.25 GB82.58 MB82.58 MB78.35 MB1.09 GB1.09 GB继上一篇文章中说的区别，其实分析的不够彻底，因此再次在这里做详细的分析。
零、Java与Sun、Oracle发展历史：
1、说明：最开始Java是Sun公司的，然后是Oracle（甲骨文）收购了Sun（太阳微系统/Sun Microsystems），最后就是Java变成Oracle了，收购时间为：；所以下文中提到的Sun和Oracle都是具有历史上的关系。
一、从JDK 1.0到J2SE 1.2，最原始的版本发展历史
1、JDK 1.0版本于日发布，叫做为Oak。而真正第一个稳定的版本JDK 1.0.2，被称作Java 1。
2、到J2SE 1.2版本，代号为Playground。 这个在日的发布的版本和其到J2SE 5.0的后续版本被重改名为Java 2，而版本名称&J2SE&（Java 2平台，标准版）取代JDK以区别出来自J2EE（Java 2平台，企业版） 和J2ME（Java 2 Platform，Micro Edition）的基础平台。
3、也就是说，更改为Java 2之后再细分了三个版本出来，以区分Java 2平台级别。
（Java版本历史）
二、从J2SE到Java SE说起，也就是发展历史
不管是J2SE还是J2EE，关注的点是J2，也就是Java 2。
1、Java 2介绍：
Java 2平台包括：标准版（J2SE）、企业版（J2EE）和微缩版（J2ME）三个版本。J2SE、J2ME和J2EE，这也就是SunONE（Open NetEnvironment）体系。J2SE就是Java2的标准版，主要用于桌面应用软件的编程；J2ME主要应用于嵌入式系统开发，如手机和PDA的编程；J2EE是Java2的企业版，主要用于分布式的网络程序的开发，如电子商务网站和ERP系统。
2、J2SE改为Java SE：
Java SE 6，代号为Mustang。版本发布于日，Sun把原本的名称&J2SE&改为&Java SE&，然后再从版本号中去掉&.0&，而开发者内部编号仍然是1.6.0。这个版本是根据JSR 270开发的。
（J2SE介绍）
（Java版本历史）
三、J2SE 1.4到J2SE 5.0再到Java SE 6的版本编号发展历史
以上三个是比较具有代表性的版本编号；
1、标红的数字叫做版本编号。
2、而从J2SE 5.0开始，改编了这个原始版本编号，采用数字辈进行代替，但内部还是使用版本编号，所以还可以对这些数字这么说：内部版本编号。
3、官方变更说明：J2SE 5.0版本，代号为Tiger。这个在日发布的版本原本以1.5编号，也就是仍然使用内部版本编号。这个数字辈改变是为了&更好地反映成熟度、稳定性、可扩充性和J2SE的安全水准&。这个版本是在JSR 176底下被开发。
4、而5.0到6版本编号的变更，经历了两大改变，1为版本编号，2为J2SE改为Java SE；
5、以上变更的官方说明：Java SE 6版本，代号为Mustang。版本发布于日，Sun把原本的名称&J2SE&改为&Java SE&，然后再从版本号中去掉&.0&，而开发者内部编号仍然是1.6.0。这个版本是根据JSR 270开发的。
6、这个内部版本编号使用非常广泛，比如我们安装的JDK上，全部使用内部版本编号，需要注意的是，在安装包的文件夹版本编号是以三位进行命名的，比如：1.6.0_x，1.6.0大体不改变，除非新大版本发布，而后面的x是bug修复的补丁级别的。在比如Windows下的JDK安装目录：C:\Program Files\Java\jdk1.8.0_131
7、通过以上的解释，也就可以推断出这些内部版本编号对应数字辈，比如即将发布的Java SE 9，如果官方没明确规定，那么就是1.9.0。
（Java版本历史）
四、Java 8与Java SE 8有什么区别
1、其实没有什么区别，Java 8就是Java SE 8。
2、如果更深入的解释，Java 8代表技术的更新点，在JSR的便准下通过的新技术点，而这些更新的技术放在了Java SE 8的安装包JDK 8下。
3、比如：从J2SE 5.0开始就叫做Java 5，到Java SE 6叫做Java 6；这些特点足以说明，这两个就是同一个东西。
（Java版本历史）
五、JDK 8与Java SE 8、Java EE 8有什么区别
1、从上面的发展历史来说明，JDK就是Java SE，这两者就是同一个东西。
2、更有力的证据，在JDK下载页面，如下所示：
3、还可以这么说，JDK就是Java平台，同样也是Java SE。如果要使用Java语言进行开发，包括开发Web，那么一定要装JDK。
六、开发Java EE的Web，需要安装Java SE还是Java EE，或者说是JDK
1、先解释Java EE，Java EE平台构建于Java SE平台之上，Java EE平台提供一组API和运行环境来开发和运行大规模的，多层的，可扩展的，可靠的和安全的网络应用程序。
2、也就是说Java EE是一个标准而已，而这些标准的实现是Web容器提供的，比如Servlet-API，在Tomcat这个Web容器下的lib文件夹就集成了servlet-api.jar的包。
3、在官方上的下载页面上，有提供开发Java EE的SDK下载，我需要下载吗？
下载下来的是glassfish的Web容器，里面是按照Java EE的标准API开发的，能运行Java EE的Web程序，同时这个容器还提供了对EJB的支持。
4、不管开发Java EE还是Java SE，只要开发与Java语言有关的程序，都必须安装JDK。比如在开发Web程序，就是与Java EE有关的，那就必须引入Web容器提供的API。比如servlet-api.jar就是Tomcat提供的，在不用POM管理的情况下，就必须导入这个JAR包。而Java SE一般代表了Application类型，比如开发桌面应用，一般是包含在了Java SE中，也就是JDK中，只需要这个JDK里买的包即可，与Java EE无关。
5、再者，如果要开发Web应用，而且要使用EJB，那么必须引入glassfish的Web容器提供的EJB的API的JAR包。
七、Java EE有独立的版本发展历史
1、首先可以肯定的是，Java EE有自己独立的版本发展历史，这一点与Java SE是区分开的。不要这样错误的认为Java SE 8就代表了Java EE 8，这两个是不同的东西。
2、从上面的观点中可以解释的一点是，Java EE提供了一组标准的API，而Web容器是实现这组API，然后提供JAR包给开发人员。那么在Web容器去实现这组API时，比如实现Java EE 7的API时，可能会使用Java 8的新语言特性去实现；那么此时，开发人员在引入这个JAR包时，就必须安装支持Java 8的安装包，也就是Java SE 8，JDK 8。那么这种联系关系可以说明是有联系，但功能却是区分的。
（Java EE API文档）
（Java EE发展历史）
八、Java EE下的Servlet和JSP发展历史
1、在Java EE的发展历史下，具有代表性的是Servlet和JSP这两个，这两个也是有发展历史的，不过这些发展历史都同一归到了Java EE下，当一个提案被JCP通过时，那么新的版本就会收入到Java EE的新版本中。各大Web容器厂商就会按照标准API进行开发。
（Servlet发展历史）
（JSP发展历史）
九、对于实现Java EE标准API的Web容器有哪些？
1、在Web容器方面，主要围绕两大方面的技术支持：Servlet和EJB。有些容器是不支持EJB的，所以在使用上需要注意。
2、下面是Web容器的相关介绍：
Apache鼎力支持的Java Web应用服务器（Servlet容器），稳定性比较强和文档资源比较全面，在开源领域受到众多追捧。
当之无愧的Java EE容器，同时支持Servlet和EJB，企业级开发人员广泛使用，因为毕竟弥补了Tomcat只支持Servlet的遗憾。
Resin也仅仅是一个Servlet容器，运行速度非常优秀，使得它在轻量级Java Web领域比较受欢迎，特别是互联网Web领域，而且他们有提供商业版本支持，一些知名商业公司使用他们的服务比较多，例如163、ku6等。Resin4支持不同的Web App分配不同的端口。
WebLogic和WebSphere
来自BEA公司的WebLogic和IBM的WebSphere，跟Resin比较类似，同样是只支持Servlet容器的商业级应用。WebLogic 支持企业级的、多层次的和完全分布式的Web应用，并且服务器的配置简单、界面友好。IBM的WebSphere可以细分为WebSphere Performance Pack、Cache Manager 和WebSphere Application Server等系列，其中WebSphere Application Server是基于Java的应用环境，可以运行于Sun Solaris、Windows NT等多种操作系统平台，用于建立、部署和管理Internet和Intranet Web应用程序。
Sun公司自己发行的Java EE服务器，开源社区比较活跃，经过v1\v2到目前的v3，它已经逐步走向成熟。作为一款免费、开放源码的应用服务，她实现了Java EE 5. Java EE 5平台涵盖了EJB 3.0、JSF 1.2、Servlet 2.5、JSP 2.1、JAX-WS 2.0、JAXB 2.0、 Java Persistence 1.0、Common Annonations 1.0、StAX 1.0等。
Glassfish支持通过内存会话状态复制，拥有良好的部署体系结构的可用性和可扩展性。对于集群的支持也很强大，简单添加机器，即可轻松实现网站的负载能力。
对于HTML生成解析能力吞吐量与Apache不相上下。我们通常用Tomcat会作为后端去处理JSP内容，就是因为它对于HTML解析吞吐量比较吃紧。
Glassfish还支持目录部署，热部署，这些都是Tomcat的缺陷。版本也比较人性化，有开发环境的简化版，部署Web项目的版本。
（Web常用容器）
十、JCP和JSR是什么&
1、JCP（Java Community Process）（Java社区进度）成立于1998年，是使有兴趣的各方参与定义Java的特征和未来版本的正式过程。
2、JCP使用JSR（Java规范请求，Java Specification Requests）作为正式规范文档，描述被提议加入到Java体系中的的规范和技术。
3、JSR变为final状态前需要正式的公开审查，并由JCP Executive Committee投票决定。最终的JSR会提供一个参考实现，它是免费而且公开源代码的；还有一个验证是否符合API规范的Technology Compatibility Kit。
4、可以这么理解，每一个Java的规范都是通过JCP进行投票通过的，而这些标准的编号有JSR进行管理的。
（JCP解释）
（JCP社区，可以自由注册，并且可以提交自己的意见，如果通过了，将收录进去）
（这个是Java 9的提案）
（这个是Java 9的投票结果）
十一、JDK与OpenJDK区别
1、JDK： Java Development Kit（JDK）是太阳微系统针对Java开发人员发布的免费软件开发工具包（SDK，Software development kit）。自从Java推出以来，JDK已经成为使用最广泛的Java SDK。由于JDK的一部分特性采用商业许可证，而非开源。因此，2006年太阳微系统宣布将发布基于GPL的开源JDK，使JDK成为自由软件。在去掉了少量闭源特性之后，太阳微系统最终促成了GPL的OpenJDK的发布。
2、OpenJDK：OpenJDK原是Sun Microsystems公司为Java平台构建的Java开发环境（JDK）的开源版本，完全自由，开放源码。Sun Microsystems公司在2006年的JavaOne大会上称将对Java开放源代码，于日正式发布OpenJDK。甲骨文在2010年收购Sun Microsystem之后接管了这个项目。
3、由于发展历史关系，OpenJDK的发展大于JDK，所以之后JDK的开发会遵循OpenJDK的步伐。为什么这么说，之前OpenJDK是JDK的一个分支，现在OpenJDK成为了主干。
4、同样的，OpenJDK也是遵循JCP的JSR标准。或者这种方式不应该这么说，不管OpenJDK还是JDK，都叫做Java，那么只要是Java就是受JCP的JSR标准约束。
（JDK说明）
（OpenJDK说明）
（OpenJDK与JDK区别分析）
（OpenJDK官网）
（JDK下载）
十二、EJB是什么？
十三、JDK与JRE区别，安装哪个
1、JRE（Java Runtime EnvironmentJDK）：JRE顾名思义是Java运行时环境，包含了Java虚拟机，Java基础类库。是使用Java语言编写的程序运行所需要的软件环境，是提供给想运行Java程序的用户使用的。JRE根据不同操作系统（如：Windows，Linux等）和不同JRE提供商（IBM,ORACLE等）有很多版本，最常用的是Oracle公司收购Sun公司的JRE版本。
2、JDK（Java Development Kit）：JDK顾名思义是java开发工具包，是程序员使用Java语言编写Java程序所需的开发工具包，是提供给程序员使用的。JDK包含了JRE，同时还包含了编译Java源码的编译器javac，还包含了很多Java程序调试和分析的工具：jconsole，jvisualvm等工具软件，还包含了Java程序编写所需的文档和demo例子程序。如果你需要运行Java程序，只需安装JRE就可以了。如果你需要编写Java程序，需要安装JDK。
十四、其它
（Java SE API文档）
，通过下方的入口进行查询
阅读(...) 评论()}