Question

java编程开发语言与其他编程语言的区别？

Answer 1

我们都知道，java编程无论是在软件开发或者是说其他编程方面，使用范围都是非常广泛的，所以，今天java课程就一起来了解一下，java编程开发语言与其他编程语言的区别和优势都有哪些。

现代JavaWeb开发

因为JavaWeb服务器与Web一样老，因此在JavaWeb上长期存在的成功传统和实践很快就要扔掉，现在可能是一个好的时候来解释这一系列中“现代”意思。

在本文中，我说“现代”的意思，就是“与现代主流软件开发趋势一致”。这些趋势并不是完全任意的堆砌，他们一个一个契合在一起。出现于这个期间大量小型快速发展的创业公司更偏爱精益开发方法。这些都要求一个更好使用，更少安装、部署和配置，集开发和运维于一体的工具。广受欢迎的云计算通过资源管理，也就虚拟化(无论是工具上还是在系统级)鼓励这些方法。系统级部署和资源分配也支持异构架构的发展。所谓异构架构就是指寻找适合的工具(也有可能是不同的工具)做合适的事。

传统的JavaWeb服务器，也就是典型的应用服务器，都有一个特别的特性：支持在一个JVM上运行多汪笑汪个应用。这个应用服务器提供能分开应用的运行时环境，而且升级，安装和启动都是独立的。一个应用可能运行在一个配置好的，已经运行的环境中，这种方法很多时候都工作良好，你也有理由继续使用这种方案，但是这种方案，离“现化”太远了。在不同的应用中分配不同的资源这件事是并不简单，而且在一定程度上跟现在使用hypervisor和os容器来运行应用的方案是矛盾的。因为现在针对hypervisor和os容器设计的工具和技术在多应用服务器上效率并不高，即使这些多应用服务器只是用来运行一个应用，而且这些多应用服务器的运维也不“现代”：安装配置web或者app服务器是不可缺少的，部署应用需要很多步，每一步可能都很麻烦。

现代的方法，就是在其它语言和运行平台使用的方法--单应用服务器。单应用服务器中，web容器是嵌入到应用中(而不是把应用部署到web容嚣中)。这样做就可以简单的部署，管理，配置和在系统级进行资源的分配。这就是为什么，一但现代的方法被引入Java中，传统的应用服务器(我的意思是任何打算运行多个应用的servlet或者全功能困仔的J2e服务器)就死了。

在这里，我们调研的工具和技术并非覆盖全部的的领域。特别是在web和web相关的领域中，开发，工具，库和框架激增。这种增长部分原因是，不像嵌入式开发和大型机开发，web开发在初创公司和开发爱好者中广受欢迎。这类人是新技术的早期采纳者和体验者，有时也会为了探索技术的边界，或者学习，还有自我证明发明一种新的择术。这样的结果就是数以百计的库被发明出来，全都为了解决同样的目标，只是使用的方法略有不同。这种事情发生在Java的世界里，也发生在其他的语言生态中。

同时，我们不会讨论那种有巨大的MVC结构，模板系统或者设计来就是在服务器端渲染html的“全功能”的web框架。有很多理由不这么做，一个就是，我从来没有使用过那种框架，所以我不会评论他们的适用性或“现化化”，二，这个主题就非常复杂，需要更多的讨论，而在别的地方已经有了(这里,这里),三，web开发正在朝客户端渲染和SPA方向发展(如angular)，本质上正在朝着以前c/s的架构发展，数据和命令都通过http对服务器进行交互。这种转变没太完全，特别的，它依靠手机浏览器的js效率的提升，但是可以肯定的讲，我们将会看到越来越少HTML在服务器端生成。因此，我们会只讨论http“数据”服务的库和框架。

http服务和JAX-RS与Dropwizard

Java与其他语言不同的一点是JCP(JavaCommunityProcess)的工作，它的工作是标准化API(即使对于不属于语言规范升悔或甚至标准运行时的库)也是如此，然后由各种商业或开源组织实现。这些JSR(JavaSpecificationRequests)是由专家组制作的，它能把一项技术从普遍变成成熟并成为标准。当JSR通过时，就会非常有用，因为几乎所有迎合相关领域的库都将实现这个标准API，这使得切换实现不那么痛苦。

对于服务器实现(代码中框架更为普遍)来说，标准对于客户端(每个调用或多或少都是独立的并且可以被替换)而言更重要。您可以使用三个不同的HTTP客户端和3个不同的JDBCAPI，但是您的服务器通常运行在单个框架中。出于这个原因，。单纯的API美学不应该倾向于支持非标准的API。

相比于客户端(每次请求或多或少比较独立和能被替代)，标准化对服务器应用更重要(因为框架代码无处不在)。你可以使用三个不同的http客户端和三个不同的JDDCapi在同一个方法中，但是你的服务器通常运行在一个框架中。出于这个原因，你应该更喜欢标准服务器API而不是非标准服务器API，除非非标准服务器API为你的应用提供了一些非常重要的优势，或者更适合您的特定用例。单纯的API美学不应该倾向于支持非标准的API。