本帖最后由 码小玩 于 2017-10-26 17:19 编辑[indent]原文：The Top 3 Blockchain Libraries for Java Devs 作者： Boyko Dimitrov 译者：Teixeira10 [/indent]【译者注】在本文中，作者介绍了三个使用区块链的Java项目，以及每个项目适用的场合，供开发者根据自己的需求进行选择。以下为译文： 大家应该都听说过比特币、以太币或其他加密货币，这些名字在新闻中经常出现，但是作为Java开发人员，你们知道如何轻松地与Blockchain技术进行交互吗?下面是可以利用Blockchain的三大Java项目。这个列表是基于GitHub存储库的星序排列的。非常感谢你的评论和意见。 BitcoinJ你有没有觉得这个名字很有描述性呢?如果你想知道如何创建一个比特币钱包，并且管理节点之间的事务，那么你应该尝试一下BitcoinJ。这个项目有一个不断扩大的社区，里面包含非常好的文档资料，这对每个开发人员都是非常有利的。当然，作为一个试图获得声望的开源项目，它也存在一定的局限性。现在已经有几个已知的开放漏洞的安全问题，以及可扩展性问题。不过，如果你想了解比特币协议是如何运作的，这个项目将是非常有帮助的。个人意见:这并不适用于生产应用。 Web3j一个词——Ethereum（以太币），这是基于尖端技术的第二大加密货币。Web3j项目允许你使用Ethereum区块链，同时不必为平台编写集成代码。同样，核心功能是创建钱包，管理事务，以及智能合约包装器。Ethereum项目的一部分是一种称为Solidity的特殊语言，它是创建智能合约的实际标准。如果你想避免使用智能合约的底层实现细节，那就使用Web3j的智能合约包装器。如果这对一名开发人员来说还不够，那我需要告诉你，它包含很多好的文档和大量的例子，这也是使web3j成为我个人最爱的原因。 HyperLedger FabricHyperLedger Fabric是企业会用到的。Linux基金会的框架是区块链解决方案的主干。所以无论你想创建一个简单的PoC，还是一个生产应用程序，它都是一个强大的工具。该项目正在由Linux基金会成员积极组织开发。它的重点是创建和管理智能合约。主要特点是: [indent]管理共享机密信息的渠道 支持政策事务 一致地向网络中的对等节点交付事务 [/indent]如果你在软件区块链堆栈中包括了HyperLedger Fabric，那么我的建议是熟悉其他的HyperLedger项目。根据你的需要，可以选择各种不同的HyperLedger项目，这些项目将保证一个连贯的、可扩展的、易于维护的区块链基础设施。对于许多人来说，区块链将改变整个互联网，难道你不想成为其中的一部分吗? 与其他Java区块链项目一起分享、评论和扩展这个列表!

本帖最后由 Jay 于 2017-10-13 10:48 编辑Java 是这个星球上最为流行的编程语言之一，但这方面的竞争正愈演愈烈。下面我们将讲述 Java 可能遭遇滑铁卢的地方，以及可以做些什么来预防它的衰退。2017 年 9 月的 TIOBE 指数将 Java 列为当月较为流行的语言。其实，它已经名列前三甲很多年了。Stack Overflow Developer Survey 2017将 Java 列为继 Javascript 和 SQL 之后第三常用的编程语言（实际上，过去四年它都保持着这名次）。不说这些结果是如何产生的，亦或者这结果是否反映了现实世界中的情况，我们不能否认的是，Java 在多个环境中仍然是一种流行语言。但是，Java 总有一天会死。世无定事，没有什么可以天长地久。编程语言死亡的真正定义是没有人再使用它——但这样的情况很难发生。即使是老朽且不被广泛使用的语言（例如，你是否听说过 Modula-3？），仍然在被使用、维护，或者至少会演变成其他的东西。当然，这是一个渐变的过程，怎么发生的方法不定。从实际出发，假设编程语言在它不再被用于新项目时，就意味着它的死亡，但是它可能依然存活在许多遗留项目上（COBOL 就是一个完美的例子）。最终这结局也将降临到 Java 头上，那么谁会杀死它？让我们来分析选项。在以《What Killed Smalltalk Could Kill Ruby Too》为主题的演讲中，Robert “Uncle Bob” Martin 说，Smalltalk 被杀的原因是，它太容易造成混乱，并且它的傲慢自大会导致不专业的实践方法，如缺乏测试驱动开发（TDD）。在任何语言中你都可以搞得一团乱。当然，在某些语言中，比其他语言更容易导致混乱——例如，在动态类型语言中，我们可以随时更改变量的类型——但是我们在 Java 中没有这个问题。此外，在 Java 社区中很多人采用的良好实践，比如设计模式和 TDD，有助于我们制作更好的软件。所以让我们来探讨另一个选项。Java 是面向对象的语言。如果其他（新的）范式接管了怎么办？如果面向对象的编程变得过时了怎么办？好吧，这可能性并不大——基本原理已经有很长一段时间没有真正改变过了。诸如结构化，功能性和面向对象编程的重大创新发生在 20 世纪 50 年代，60 年代以及甚至 70 年代，但从那以后，没有什么举足轻重的事发生。但是，在过去十年中，却有很多新的语言问世，这些语言有着现代的语法以及新功能的框架。那么，没有现代语法和新的功能是否会导致 Java 的死亡呢？不，我不这么认为。你还记得（或听说过）EJB 2.0 及其 Entity Beans 吗？它们很可怕，但是像 Rod Johnson 和 Gavin King 这些 Java 社区的成员却以 Spring 和 Hibernate 等框架回应。以类似的方式，虽然 Java 不是一个功能齐全的语言，但是由于有 Vavr 这样的库，我们可以使 Java 更加功能化。我的意思是，Java 缺少的某些东西，有人会通过创建（框架，工具，规范，无论什么）来填补这个空白。那么 Java 会不会因为另一种编程语言而死亡呢？我们以 JavaScript 为例。毕竟 JavaScript 正在占领这个世界，对吧？我们可以在后台使用 Node.js，类似于移动设备上的 React Native 或 Ionic，我们甚至不必提及在前端的所有竞争选项。但是，至少在企业软件中，我没有看到 JavaScript 将要替代 Java 的趋势。JavaScript 在企业领域中没有取得成功的框架或工具。它也没有与 Java 虚拟机（JVM）相当的东西，Java 虚拟机（JVM）依然是大型和关键任务软件的首选平台。那么 Kotlin 呢？Kotlin 语言首次出现在 2011 年，并且最近 Google 宣布在 Android 上对 Kotlin 提供一流的支持。Kotlin 正在逐渐被知名公司采用，并且不局限于在这些公司的 Android app 上（例子）。除了现代化的功能，Kotlin 也是一种开放源代码的语言，它由一家生产最佳 java ide 的公司提供支持。所以，如果你问我的话，我的回答是，是的，Kotlin 看起来像是（在遥远的未来）替代 Java 的一个很好的候选者。当然，Java 也可能被一种或多种语言所替代。哪些呢？我不确定，而且我敢说现在也没有人知道这个问题的答案。我所能确定的是，没有任何语言能够自主地杀死 Java。不借助任何外力，就此而言。能够杀死 Java 的刀子在于它无法满足市场的需求。编程语言是构建解决计算机问题的应用程序的工具。如果某编程语言提供抽象、模型、工具和框架，使你可以更有效率或创建比 Java 更高效的代码，你会选择哪种语言呢？即使是在 Java 版本之间，如果让你在 Java 1.4 和 Java 9 之间进行选择，那么你会选择 Java 1.4 吗？你会放弃用 lambdas 或泛型工作的机会吗？我不这么认为。你会需要较新版本的功能。在这些年来，由于已检查异常、内部类、getter 和 setter 等等方面，Java 被认为是一种冗长又笨拙的语言。直到 Java 7（有些人认为是 Java 8）才开始好转。然而，Java 7 于 2011 年发布，比 Java 1.4（2002 年发布）晚了九年。在这个时代，这是不能接受的，并且可能会导致恶性循环。仔细查看 TIOBE 页面上的 Java 图表。尽管 Java 大多数时候位居前三，但有明显的下降趋势，表明它正在失去市场份额。这种趋势在所有语言中都很普遍。最可能的原因是编程语言的数量在不断增加，应用程序越来越多地被以多种语言编写。因此，竞争比以往任何时候都要激烈。如果我们认为其他语言比这种语言更好，那么它就不再受欢迎，我们也不会将这种语言教给新一代的开发人员。新的教程、课程和书籍将不会再被创造。社区中的宝贵成员将被其他技术吸引走。该语言将不会用于新的环境。将导致减少语言的流行度。Mark Reinhold，Oracle Java 平台组首席架构师，提出的新的六个月发布计划，是向前推进 Java 并迈向未来的重大一步。用他的话说（就特征驱动的版本）：[indent]这种方法可以在早期采用者进行彻底的检查和测试后，以高水平的质量提供大的新功能。然而，不足之处在于，较小的 API、语言和 JVM 功能只有在大功能准备就绪时才能实现。这是在本世纪之交前后几十年时间里达成的一个可接受的折中方案，当时 Java 仅与几个以类似的步伐演进的平台竞争。然而，如今，Java 在与许多以更快速度发展的平台一起竞争。[/indent]最后一段话很多都是事实。但是，这不仅仅是 Oracle 的工作。社区也必须保护 Java。怎么做？我的一些想法：[*]不要傲慢（不要认为 Java 太大而不会失败） [*]促进良好的开发实践方法 [*]继续发布超棒的框架、工具等 [*]支持 JSR [*]帮助教学和推广 Java 语言 [*]在新环境中尝试 Java否则，Java 如果无法跟上时代的步伐，那么最终将会被后浪拍死在沙滩上。-译文链接：http://www.codeceo.com/article/what-will-kill-java.html翻译作者：码农网 – 小峰

本帖最后由 yd_87160914 于 2017-9-30 17:17 编辑Java 9 - 正式的名称是 Java 平台标准版版本号 9 - 终于发布了，Java 开发工具包（JDK） 也已经可供开发者下载。 新版本增加了几个重要且富有争议的功能，同时它也是一直以来遵循 Java 版本命名规范和发布周期的最后一个版本。 Java 9 的关键新特性 在 Java SE 8 发布将近三年后，Java SE 9 终于发布，它带来几个重大的架构变化，以及一系列的改进。 Java 9 的模块化是颠覆性 基于 Jigsaw 项目，这个新的富有争议性的模块化能力肯定会引来最前沿 Java 开发者的兴趣和尝试，即使会有更保守的开发者决定等待模块化的成熟。 模块化－以 Java 平台模块系统的形式－将 JDK 分成一组模块，可以在运行时，编译时或者构建时进行组合。模块化被称为一个“可传递”的更改，它支持对模块间依赖的理解。 Java 9 的模块化能让开发者更容易的组合和维护复杂的应用程序。同时，它也使 Java 在改进安全和性能的同时能够更好的适配到更小的设备中。 Java 9 的模块化包含应用打包，JDK 自身模块化，以及将源码重新组织成多个模块。构建系统在构建时编译模块和识别模块边界的能力也得到增强。JDK 和 Java 运行时环境（JRE）的镜像经过重构以处理模块化。另外，JavaFX UI 控件和 CSS APIs 现在也支持模块化方式访问。 Java 9 支持很多配置，因此，可伸缩性，安全性和应用程序性能应该得到改善。让 Java 更容易适配到小型设备中是模块化的关键推动力。 通过模块化，开发者将能够更好的使用 Java SE（标准版本）和 Java EE（企业版本） 构建和维护函数库和大型应用。但在 Java9 开发期间，Oracle，IBM，Red Hat 和其他公司关于如何在 Java 平台实施这样的重大改动有很大的分歧。模块化系统本身在五月份被否决，取得一定进展后，在六月份第二次投票中才获得批准。 即使主要的 Java 供应商之间已经取得了一致，但关于模块化能给 Java 开发者带来多大好处，专家们褒贬不一。无论如何，Java 9 现在已经支持模块化了。 为了更容易的将代码迁移到模块化的Java 9，Java 9 允许开发者对类路径中的代码进行非法的反射访问，这一能力被JRE 用来搜索类和资源文件，当然，这个能力在 Java 9 之后将会禁用。 改进的 Java 9 代码编译 Java 9 的升级带来了几个代码编译的新功能，其中最主要的是 AoT（ahead-of-time）编译。虽然仍处于试验阶段，但这个功能使得 Java 应用在被虚拟机启动之前能够先将 Java 类编译为原生代码。此功能旨在改进小型和大型应用程序的启动时间，同时对峰值性能的影响很小。 JIT（Just-in-time）编译器速度很快，但是 Java 项目现在变得很大很复杂，因此 JIT 编译器需要花费较长时间才能热身完，而且有些 Java 方法还没法编译，性能方面也会下降。AoT 编译就是为了解决这些问题而生的。 但是 Java 技术供应商Excelsior 的营销总监 Dmitry Leskov 担心 AoT 编译技术不够成熟，希望 Oracle 能够等到 Java 10 时有个更稳定版本才发布。 Java 9 同时还提供了 Oracle 智能编译部署的阶段二功能。这个功能包括改进了 s javac 工具的稳定性和可移植性，从而能够被 JVM 默认使用。这个工具也将会做得更通用，从而可以使用在除 JDK 之外的其他大型项目中。JDK 9 还更新了 javac 编译器以便能够将 java 9 代码编译运行在低版本 Java 中。 另一个新的同时也是试验性的功能是 JVMCI（Java-level JVM Compiler Interface）。通过这个接口，用Java 编写的编译器可以被 JVM 当作动态编译器使用。JVMCI的 API 提供访问虚拟机结构，安装编译过的代码，以及**JVM 编译系统中的机制。 使用 Java 编写的JVM 编译器相比已有的用 C 或者 C++ 编写的编译器，能够在保持高质量的同时更容易维护和改进。因此，使用 Java 编写的编译器本身应该更容易维护和改进。其他使用 Java 编写编译器的尝试包含 Graal 项目和 Metropolis 项目。 新的编译器控制能力旨在为 JVM 编译器提供细粒度和方法上下文相关的控制，让开发者在运行时不降低性能的前提下修改编译器控制选项。这个工具还支持为 JVM 编译器存在的 bug 提供解决方法。 Java 9 终于有了 REPL Java 9 的另一个特性是拥有了 REPL（read-eval-print loop）工具，这是另一个 Java 的长期目标，在 Kulia 项目中经过多年研发后终于在 Java 9 中得以实现。 Java 9 的 REPL 名为 jShell，以交互式的方式对语句和表达式进行求值。开发者只需要输入一些代码，就可以在编译前获得对程序的反馈。 命令行工具的功能包含 tab 自动补全和自动添加分号。jShell API 支持在 IDE 和其他工具中使用 jShell 功能，虽然这个工具本身不是 IDE。 REPL 的缺失是高校想要把 Java 从学校课程中剔除的一个原因（像 Python 和 Scala 之类的语言早就有 REPL 了）。但 Scala 语言的创始人 Martin Odersky 质疑 Java 中 REPL 的作用，他说Java 是面向语句的，而 REPL 是面向表达式的。 Java 9 增强了 Steam API Java 的 Steam 让开发者能够快速运算，从而能够有效的利用数据并行计算。Java 8 提供的 Steam 能力能够利用多核架构实现声明式的数据处理。 在 Java 9 中，StreamAPI 通过新增方法， 实现有限制的从 Stream 中添加或者移除元素，遍历 Stream 中的元素，以及通过扩展 Java SE API 集合实现从空值创建流的功能。 Java 9 支持代码缓存的分割 JDK 9 支持将代码缓存分割成段，从而提高性能并实现扩展功能，例如细粒度锁。由于使用专门的迭代器忽略非方法代码，分离非方法，剖析和非剖析代码，结果扫描时间将得到改进。某些基准的执行时间也得到改进。 通过 Nashorn 项目 Java 9 更好的支持 Javascript Nashorn 项目在 JDK 9 中得到改进，它为 Java 提供轻量级的 Javascript 运行时。Nashorn 项目跟随 Netscape 的 Rhino 项目，目的是为了在 Java 中实现一个高性能但轻量级的 Javascript 运行时。Nashorn 项目使得 Java 应用能够嵌入 Javascript。它在 JDK 8 中为 Java 提供一个Javascript 引擎。 JDK 9 包含一个用来解析 Nashorn 的 ECMAScript 语法树的 API。这个 API 使得 IDE 和服务端框架不需要依赖 Nashorn 项目的内部实现类，就能够分析 ECMAScript 代码。 Java 9 引入 HTTP/2 客户端API Java 9 引入了 beta 版的 HTTP/2 客户端API，升级了 Web 核心 HTTP 协议，这个 API 同时也支持 WebSocket。 HTTP/2 API 可以用来代替 HttpURLConnection API，后者存在一些缺点，包括当初是为现在已经失效的协议所设计，早于 HTTP/1，接口定义太抽象以及使用起来不容易。 Java 9 改进了对 HTML5 和Unicode 的支持 在 JDK 9 中，Javadoc文档工具经过增强现在支持生成 HTML5 标记文档。Unicode8.0 编码标准也得到支持，该标准新增 8000 个字符，10个块和 6 个脚本。 Java 9 新增 DTLS 安全API 为了安全，Java 9 新增支持 DTLS（Datagram Transport Layer Security）的 API。这个协议用来在客户端服务器通信中防止窃听，篡改，消息伪造等。客户端和服务端模式都提供了实现。 Java 9 废弃和移除的 API Java 9 废弃或者移除了几个不常用的功能。其中最主要的是 Applet API，现在是标记为废弃的。随着对安全要求的提高，主流浏览器已经取消对Java 浏览器插件的支持。HTML5 的出现也进一步加速了它的消亡。开发者现在可以使用像 Java WebStart 这样的技术来代替 Applet，它可以实现从浏览器启动应用程序或者安装应用程序。同时，appletviewer 工具也被标记为废弃。 Java 9 还废弃了并行标记扫描（CMS，Concurrent Mark Sweep）垃圾回收器，在未来的发布版本中将进一步停止支持。其目的是加速 **Spot 虚拟机中其他垃圾回收器的发展。低暂停 G1（low-pause G1） 回收器将是 CMS 的长期替代品。 同时，之前在 JDK 8 中废弃的垃圾收集组合在 JDK 9 中已经删除。这包括很少使用的组合，例如增量 CMS，ParNew + SerialOld，DefNew + CMS，这些给垃圾收集器的代码库增加了额外的复杂性。 Java 9 也忽略了 Java 导入语句的警告，以有助于大型代码库维持更干净的 lint 警告。在这些代码库中，废弃的功能通常还需要继续使用一段时间，代码中导入废弃类或者方法，如果是开发者有意为之，并且通过注解抑制这些警告信息，那么警告信息将不会显示出来。 在 Java 9 中同时移除的还有通过 Multiple JRE（mJRE）功能在启动时选择 JRE 版本 的功能。这个功能很少使用，同时使 Java 启动器的实现复杂化，自从在 JDK 5 开始出现以来，一直没有完整的文档描述。 Oracle 已经移除 JVM TI（Tool Interface）hprof（Heap Profiling） 代理，它在 JVM 中已经被代替。jhat 工具也被移除，它早已被更好用的堆栈可视化和分析工具所代替。 Java 9 是当前时间线的终结者，新的时间线从此展开 Java 9 的带来了很多新功能。Oracle 最近透漏 Java 9 将是最后一个遵循 Java 名称命名规范和主版本发布周期的版本。 从现在开始，Java 的计划发布周期是 6 个月，下一个 Java 的主版本将于 2018 年 3 月发布，命名为Java 18.3，紧接着再过六个月将发布 Java 18.9。 Java 新的发布周期也意味着 JDK 9 将不会被作为长期支持版本。相反，下一个长期支持发布版本是 Java18.9。 Java 更快的发布周期意味着开发者将不需要像以前一样为主要发布版本望眼欲穿。这也意味着开发者将可能跳过 Java 9 和它的不成熟的模块化功能，只需要再等待 6 个月就可以迎来新版本，这将有可能解决开发者的纠结，Simon Maple 这样说，他是 Java 工具供应商 ZeroTurnaround 的 Java 支持者。 来源：Java 9 is here: Everything you need to know 作者：Paul Krill 译者：顾浩鑫

众多开发者期待的Java 9四次跳票后， 22号终于发布正式版！！！DK9 提供超过150项新功能特性，包括备受期待的模块化系统、可交互的REPL工具 jshell，以及安全增强、扩展提升、性能管理改善等。Java 9的模块化改变了游戏规则基于Project Jigsaw的模块化功能引起了广大程序开发人员的争议，Java商店对于模块化功能并没有立即更新，而是保守的决定等模块化日渐成熟后在进行更新。模块化是以Java平台模块系统的形式将JDK分为一组模块，用于运行、编译或构建时间组合的功能。模块化也被称为一次具有传递性的变更，有利于帮助人们进一步了解模块之间的依赖关系。模块化可以让软件开发人员更容易的组装和维护复杂的应用程序，此外，Java 9中的模块化可以使得Java更好的缩小模块化到更小的设备，同时提高安全性和性能。模块化主要包括应用程序打包、模块化JDK本身、将源代码重新组合成模块以及重构JDK和Java运行环境映像等。JavaFX UI控件和CSS API现在可用于模块化。模块化支持多种配置，可以提高可扩展性、安全性和应用性能，将Java 9轻松的扩展到小型设备是模块化的关键驱动力。来源：51CTO 作者：王雪燕

本帖最后由 码小玩 于 2017-9-29 14:19 编辑一口不吃了一个胖子，心急吃不了热豆腐。当你点开这篇文这句话送给你。 0基础学Java只需办法适合，仍然有机遇进修好Java编程。初学Java就像交同伙从生疏到认识再到铁杆错误平生相伴，跟着进修的深刻，你会发明学Java并非设想的那样死板和艰苦，乃至另有一些美好之感，本文就为零根基学java的10个筹划，对初学java的你必定有帮助： 筹划一：透辟理解面向工具 只有理解了面向工具能力感知Java编程的绝妙，面向工具是Java中很紧张的一个概念，假如理解不透辟的话，你可以或者在前期编程时会仍然遵守面向进程的形式，理解概念很紧张，但并不能赞助你太多，最紧张的是要学会有面向工具概念来计划一个办理计划，以是你应当精确的控制并能应用工具创立、多态、计划形式等常识。 筹划二：控制焦点的API 看着轻易做着难，能理解的不必定会做，学Java也是如许，理论常识控制的再纯熟，假如不理解说话组成焦点API那统统都是0!就Java说话而言，你应当对它的API有异常强的实战履历，比方java.lang.*,IO,Exception(异常)，Collections(聚集),Generics(泛型)，Threads(线程)，JDBC(数据库衔接)等等。假如你妄想是成为一个精彩的收集应用法式的开辟者，不论你用甚么范例的框架，你都必需要认识Servlet和JSP。 筹划三：锲而不舍写代码 理论是查验理论的独一尺度，只有写代码能力让你真正意想到成绩的深刻度，赓续发明编程说话的局限性和办理成绩的计划。对初学者来讲晋升编程品质的独一道路便是不绝的敲代码，哪怕是一个很简略的成绩，将它用代码实现并运转，这才是进修编程独一可行的道路。靠眼睛是学不会编程的，对付初学者除演习别无它法! 筹划四：加入好的交换服装论坛 记着，你不是一个人在战役，有许多人他们和你同样，在统一个起跑线上斗争着。应用框架实现一个简略的法式不是真正的挑衅，当你真正成为一个开辟工程师的时刻，你会发明许多奇怪的成绩是靠阐明办理不了的，你必要寄托一些人给你供给进修线索，哪怕是只言片语都有可以或者帮你走出逆境，领你戴德不已。 孔子曰：三人行，必有我师，在开辟范畴这句话绝被奉为经典并赓续的获得验证，作为初学者，不要放过一个可以或者领你晋升的机遇，探求一些好的服装论坛，不懂就问，成绩办理一个少一个，本身也会赓续进步。固然你也要学会分享，把本身的履历和设法主意分享给和到和你已经碰到同样成绩的人，赞助他们的同时也坚固了本身的常识，理解分享亦是进步。 筹划五：探求经典技巧博客 上一条刚说了，你不是一个人在战役，在收集上有许多技巧牛人都经由过程博客来分享本身的技巧履历和编程心得，你只必要勤恳一些去发明如许的博客，天天去浏览他们的技巧文章，能吸收到不同人对统一技巧的履历可见地，或者他们会为某一项功效而争执不休，你不必要去理睬，在“观战”的时刻要去阐发各类概念，逐渐形成本身的思惟，一朝一夕你会显著感觉到本身在法式计划上的晋升，这便是进步。 筹划六：浏览开源框架源码 一个及格的开辟者必先能灵活的应用各类框架，而要想成为一个精彩的开辟者，就应当赓续的去进修风行框架的源码，如许在深刻理解框架外部机制的同时还能获得大批的演习，慢慢丰硕本身的代码计划思惟，做一个代码的创造者而不是代码的复制者。 筹划七：接收指点或加入培训 在编程的路上别人的指点有着相当紧张的感化，有用的指点可以或者让你免走弯路，更快的获得自我晋升。优良的开辟工程师为甚么报酬高并且在项目中有着举足轻重的感化，紧张是因为他们不只可以或者掌握项目开辟的正确方向，还能率领团队别的成员晋升本身的开辟程度，这是任何一个企业都希求的也是老成持重的Java职员所盼望的。 在Java的进修阶段，业余的Java培训可以或者大大延长进修光阴，进步进修效力。Java初学者眼中弗成逾越的艰苦，很可以或者是一个Java开辟履历丰硕的人几句话就能够搞定的。你所学的常识弗成以或者都来自教科书，培训可以或者接触到更多人，人脉的积聚便是履历的积聚还可以或者转化为财产的积聚。 筹划八：理解未来技巧发展方向 两耳不闻窗外事，在如今是不合适的，分外是在顷刻万变的互联网期间，作为一个开辟者技巧跟不上可以或者去专研，思惟要跟不上，你辛辛苦苦刚做进去的产物可以或者已经后进了，或者只是一个眇乎小哉的小功效，思惟跟不上，就不能控制自动，还可以或者会被产物司理埋怨技巧后进甚么功效都实现不了，这相对是一个袭击!以是在垂头看代码的时刻，必定要关上双耳，洞察技巧的发展方向，坚持抢先能力立于不败。 筹划九：收集有用代码和工具 软件的日趋风行和Java的丰硕的资本，注定一些代码要反复应用，伴跟着你的事情履历的积聚，如许的反复性事情可以或者愈来愈多，以是你要学会收拾并收集一些罕用代码。想要朝这方面发展或者真心有兴趣的。可以找我要一些基础的学习视频，Q号码：3300863615，这个是免费的，希望同学找我要的时候不要有理所应当的态度，毕竟都是我的心血，希望你是真的有一颗想要学好java的心，我也会尽所能的去帮助你成为一名优秀的程序员。在好比：log4j的设置装备摆设文件(log4j.properties)，JDBC设置装备摆设，框架的设置装备摆设等，另有工具类的比方StringUtils(字符串工具)，DBUtils(数据库工具)等等，这会对给你以后的事情带来极大的方便，固然做这些还不敷让你成为一个精彩的开辟者，但试想一下假如你的共事或者同伙让你协助写一个功效代码，你只需复制粘贴而后轻微做做改动就能够或者实现，这个进程可以或者不敷5分钟，那时刻你的共事和同伙必定会对你另眼相看，不只如此你还节俭了本身的光阴，走一个捷径帮你省去很多费事，还赚到了品德。 筹划十：记载你的设法主意和创意 在进修中你可以或者灵光一闪，有了一个分外好的设法主意，或者忽然想明确了一个不绝困扰本身的费事，用笔记载上去，光阴长了你的思想愈来愈辽阔，你会清晰的发明本身属于甚么范例的进修者，在碰到艰苦时又因此何种心态何种办法办理的，它便是你的发展日志。同时，作为一个酷爱分享的人，你的履历和设法主意不要忘怀拿进去分享到你的服装论坛t.vhao.net和博客，赞助一些曾和你同样必要赞助的人，在Java的天下里，资本共享是推进技巧进步的紧张力气。 总之，Java是一门轻易上手的编程说话，但想要死记硬背，除控制良好的进修办法以外，尽力是必弗成少的。进修java要对本身有充足的信念，调剂进修办法和立场。 最后，愿你成为一名优秀的程序员，愿你所有努力都不会白费。 来源：程序人生

请问如何解决jar名不能转换成module名的问题，比如hibernate-persistence-jpa-2.1-api-1.0.0.Final.jar？目前很多库都不是模块的。。。

工作快一年了，接触的只有增删改差的功能，应该看哪些专业的书来提升自己，求大神指教。

Oracle近日宣布，他们将加快 Java 的发布频率，改为每六个月一次。也就是说，Java的下一个版本将在 2018 年 3 月发布，也就是本月 Java 9 发布后的六个月。 Java当前的发布周期为两年一次，但是，Java 9因为模块化系统（Jigsaw）问题一再延期，已经比预期晚了18个月，GA 版本将在9月21号发布。此前，Java 8也因为安全问题延期了8个月左右。新的发布周期严格遵循时间点，将在每年的3月份和9月份发布，相应的版本号为18.3、18.9、19.3等。与现在的发布周期不同，新的发布计划不会为了等待某个主要特性完成而延期。如果一个特性还没有完成，它就不会被合并到发布用的代码仓库里。如果错过了一个版本，就要等待下一次发布。编译自：infoworld.com

本帖最后由 DevCloud 于 2017-9-22 14:46 编辑

Java EE 在其 GitHub 上的账号发布了 Java EE 8 最终规范，并提供了 PDF 格式的文件下载。按照此前公布的计划，Java EE 8 最终规范会在今年夏天结束前发布。现在看来，他们并没有食言。在 JCP 主页上，我们可以看到，在 8 月 21 日，JCP 执行委员会以 24 票赞成票通过了 JSR #366 的最终批准投票。其中，英特尔公司放弃了投票Java EE 8 规范从 2014 年 8 月开始接受 JSR 评审，到现在推出最终规范，整整经历了 3 年多的时间。去年，我们曾报道过，负责 Java EE 和 WebLogic Server 的甲骨文副总裁 Anil Gaur 表示预计在 2017 年年底发布的 Java EE 8 会具备基本的微服务和云功能。Gaur 计划 Java EE 8 的扩展会包含增强的安全性（以 secret 管理的形式，并且要支持 OAuth 和/或 OpenID）、独立（self-contained）配置的 API 以及健康检查（可能会支持应用监控）。前些日子，甲骨文表示将要把 Java EE 移交给开源组织。现在，Java EE 8 的最终规范已推出，不知道有可能将要移交给开源组织的 Java EE 会有怎样的发展。

Java反射机制可以让我们在编译期(Compile Time)之外的运行期(Runtime)检查类，接口，变量以及方法的信息。反射还可以让我们在运行期实例化对象，调用方法，通过调用get/set方法获取变量的值。Java反射机制功能强大而且非常实用。举个例子，你可以用反射机制把Java对象映射到数据库表，就像Butterfly Persistence（译者注：原作者所编写的框架）所做的那样，或者把脚本中的一段语句在运行期映射到相应的对象调用方法上，就像 Butterfly Container（译者注：原作者所编写的框架）在解析它的配置脚本时所做的那样。目前在互联网上已经有不胜枚举的Java反射指南，然而大多数的指南包括Sun公司所发布的反射指南中都仅仅只是介绍了一些反射的表面内容以及它的潜能。在这个系列的文章中，我们会比其他指南更深入的去理解Java反射机制，它会阐述Java反射机制的基本原理包括如何去使用数组，注解，泛型以及动态代理还有类的动态加载以及类的重载的实现。同时也会向你展示如何实现一些比较有特性的功能，比如从一个类中读取所有的get/set方法，或者访问一个类的私有变量以及私有方法。在这个系列的指南中同时也会说明一些非反射相关的但是令人困惑的问题，比如哪些泛型信息在运行时是有效的，一些人声称所有的泛型信息在运行期都会消失，其实这是不对的。

概要创建一个用于将一组模块和它们的依赖组装与优化到一个自定义运行时镜像中去的工具，此运行时镜像的细节在 JEP220 中定义动机JEP261 在编译时（javac命令）和运行时（java命令）之间定义了一个可选阶段：链接时。链接时需要一个链接工具用于组装和优化一组模块以及它们的可传递依赖，以建立一个运行时镜像，或可执行文件。运行时是一个对全局进行优化的较好时机，因为在编译时进行优化会比较困难，而在运行时进行优化代价高昂。一个例子是，在一个计算的所有输入成为常量（亦既非未知）时对其进行优化。还有一个例子是把不再会被执行到的代码移除。描述$ jlink --module-path 模块路径> --add-modules 模块名> --limit-modules 模块名> --output 输出路径>[*]–module-path 是链接器将要发现可观测模块的路径。这些模块可以是以 JAR 文件，JMOD 文件或 exploded 模块的形式存在 [*]–add-modules 将要被加入运行时镜像的模块名。这些模块还会通过传递依赖，导致更多的模块被加入 [*]–limit-modules 对可观测模块的**进行限制 [*]–output 用于存放产生的运行时镜像的路径–module-path， –add-modules 和 –limit-modules 选项在 JEP261 中进行了详细描述。其余 jlink 将会支持的选项包含： [*]–help 打印使用/帮助信息 [*]–version 打印版本信息

在数据的页面录入或者Excel导入的过程中，字段的值在**数据库之前，一般都会进行去前后空格的处理，常见的处理方式无非是在前端页面调用jQuery的trim方法，或者在服务端调用Java的String.trim方法，或者在**的SQL语句中，调用数据库的函数trim，这三种方式，无论采用哪一种，都会有一个严重的漏洞：该方法只针对半角的空格起作用，对全角的空格一点用都没用。 为此，我们开发了一个工具类，专门用于处理这个问题，其基本的原理，就是找到全角空格的Unicode码，然后替换掉前后的全角、半角空格。具体代码如下： ]- Java 代码 01public class StringUtils {0203/**04* 全角空格05*/06private static final String CHINESE_EMPTY_STRING = String.valueOf('\u3000');0708/**09* 半角空字符串10*/11private static final String EMPTY_STRING = "";1213/**14* 去除字符串前后的中英文空格15* @author z003159051617* @param string18* @return19*/20public static String trim(String string){21if(string == null || string.isEmpty()){22return string;23}2425String tmpString = string;26tmpString = tmpString.replaceFirst("^(" + CHINESE_EMPTY_STRING + "|\\s)+", EMPTY_STRING);27tmpString = tmpString.replaceFirst("(" + CHINESE_EMPTY_STRING + "|\\s)+$", EMPTY_STRING);2829return tmpString;30}31}

本帖最后由 HW Developer 于 2017-8-30 17:01 编辑关于Java中的资源关闭，是一个常见的问题，也是最容易被初级程序员忽略的一个问题，这个问题的严重性，吃过亏的人都知道，不需多说。之所以会出现这个问题，主要还是在Java 7之前，语言没有很好地提供资源管理的语法。我们先看下面的代码： Java 代码01InputStream inputStream = null;02Workbook wb = null;03Connection con = null;04PreparedStatement ps = null;05try {06inputStream = new FileInputStream("c:/tmp/a.txt");07wb = new XSSFWorkbook(inputStream);08con = ServiceLocator.getInstance().getDataSource("jdbc/xxxDS").getConnection();09ps = con.prepareStatement(sql);10//do business process11} catch (Exception e) {12logger.error(e.getMessage());13throw e;14} finally {15if(inputStream != null){16try {17inputStream.close();18} catch (Exception e) {19logger.error("Exception "+e.getMessage(),e);2021}22}23if(wb != null){24try {25wb.close();26} catch (IOException e) {27logger.error("Exception " + e.getMessage(), e);28}29}30if(ps != null){31try {32ps.close();33} catch (SQLException e) {34logger.error("Exception "+e.getMessage(),e);35}36}37if(con != null){38try {39con.close();40} catch (SQLException e) {41logger.error("Exception "+e.getMessage(),e);42}43}44}声明的资源必须放在try语句块的外面，最后在finally中关闭。这里存在很多容易导致问题的地方： 1、声明的资源在try语句块中打开后，忘记在finally中关闭； 2、关闭资源的代码没有放在try-catch块中，一旦牵涉到多种资源的关闭，前面的抛异常，后面的被跳过，导致对应的关闭代码没有执行； 3、如果资源的关闭没有放在finally中，也会导致打开的资源没有正常关闭。 这些问题比较隐蔽，如果代码相对比较复杂，就非常容易被忽略。还有一个问题，就是代码很长，非常丑陋，非常不利于维护。当然，这个问题很容易想到解决方案，就是把资源关闭的代码抽出来，形成一个公共的工具方法，就像下面这样： - Java 代码01InputStream inputStream = null;02Workbook wb = null;03Connection con = null;04PreparedStatement ps = null;05try {06inputStream = new FileInputStream("c:/tmp/a.txt");07wb = new XSSFWorkbook(inputStream);08con = ServiceLocator.getInstance().getDataSource("jdbc/xxxDS").getConnection();09ps = con.prepareStatement(sql);10//do business process11} catch (Exception e) {12logger.error(e.getMessage());13throw e;14} finally {15close(inputStream);16close(wb);17if (ps != null) {18try {19ps.close();20} catch (SQLException e) {21logger.error("Exception " + e.getMessage(), e);22}23}24if (con != null) {25try {26con.close();27} catch (SQLException e) {28logger.error("Exception " + e.getMessage(), e);29}30}31}3233public static void close(Closeable cloneable) {34if (cloneable != null) {35try {36cloneable.close();37} catch (Exception e) {38logger.error("Exception " + e.getMessage(), e);39}40}41}由于java.sql.Connection，java.sql.PreparedStatement都没有实现java.io.Closeable接口，所以，这个公共的方法使用不了，当然，我们重新再定义带这两种参数的重载方法就行了，就像下面这样： - Java 代码 01public static void close(Connection cloneable) {02if (cloneable != null) {03try {04cloneable.close();05} catch (Exception e) {06logger.error("Exception " + e.getMessage(), e);07}08}09}1011public static void close(PreparedStatement cloneable) {12if (cloneable != null) {13try {14cloneable.close();15} catch (Exception e) {16logger.error("Exception " + e.getMessage(), e);17}18}19}最后，我们的代码像下面的样子： - Java 代码01InputStream inputStream = null;02Workbook wb = null;03Connection con = null;04PreparedStatement ps = null;05try {06inputStream = new FileInputStream("c:/tmp/a.txt");07wb = new XSSFWorkbook(inputStream);08con = ServiceLocator.getInstance().getDataSource("jdbc/xxxDS").getConnection();09ps = con.prepareStatement(sql);10//do business process11} catch (Exception e) {12logger.error(e.getMessage());13throw e;14} finally {15close(inputStream);16close(wb);17close(ps);18close(con);19}OK，这已经比开始简化了不少，如果没有更进一步的追求，到此打住也无可厚非。但我们再仔细研究下就会发现依然存在以下问题： 1、待关闭的资源必须要在最外层声明，有多少种就要声明多少次，这和Java变量声明的原则（哪里用哪里声明）不一致； 2、声明多少次，就要调用多少次close，还是容易遗漏。 那最好的方案是什么呢？请看下面的代码： - Java 代码 01MyCloser closer = MyCloser.create();02try {03InputStream inputStream = closer.register(new FileInputStream("c:/tmp/a.txt"));04Workbook wb = closer.register(new XSSFWorkbook(inputStream));05DataSource dataSource = ServiceLocator.getInstance().getDataSource("jdbc/xxxDS");06Connection con = closer.register(dataSource.getConnection());07PreparedStatement ps = closer.register(con.prepareStatement(sql));08// do business process09} catch (Exception e) {10logger.error(e.getMessage());11throw e;12} finally {13closer.close();14}引入MyCloser，变量用的时候再声明，不用放到最外面，资源的关闭，在finally中一行代码解决。下面是MyCloser的代码： - Java 代码001import java.io.Closeable;002import java.io.IOException;003import java.sql.Connection;004import java.sql.ResultSet;005import java.sql.SQLException;006import java.sql.Statement;007008import com.google.common.io.Closer;009010/**011* com.google.common.io.Closer的扩展，对常见的非java.io.Closeable资源012* 进行了适配，实现资源的注册和集中关闭，以简化客户端代码。013*014* @author z00315905015* @since 2016-10-12016*/017public class MyCloser {018private final Closer closer;019020private MyCloser(Closer closer) {021this.closer = closer;022}023024public static MyCloser create(){025return new MyCloser(Closer.create());026}027028public Connection register(final Connection connection) {029closer.register(new Closeable() {030@Override031public void close() throws IOException {032try {033connection.close();034} catch (SQLException e) {035throw new IOException(e);036}037}038});039return connection;040}041042public S register(final S statement) {043closer.register(new Closeable() {044@Override045public void close() throws IOException {046try {047statement.close();048} catch (SQLException e) {049throw new IOException(e);050}051}052});053return statement;054}055056public ResultSet register(final ResultSet resultSet){057closer.register(new Closeable() {058@Override059public void close() throws IOException {060try {061resultSet.close();062} catch (SQLException e) {063throw new IOException(e);064}065}066});067return resultSet;068}069070public void close() throws IOException {071closer.close();072}073074public C register(C closeable) {075return closer.register(closeable);076}077078public RuntimeException rethrow(Throwable e) throws IOException {079return closer.rethrow(e);080}081082public RuntimeException rethrow(Throwable e, Class declaredType) throws IOException, X {083return closer.rethrow(e, declaredType);084}085086public RuntimeException rethrow(Throwable e, Class declaredType1,087Class declaredType2) throws IOException, X1, X2 {088return closer.rethrow(e, declaredType1, declaredType2);089}090091public boolean equals(Object o) {092return closer.equals(o);093}094095public int hashCode() {096return closer.hashCode();097}098099public String toString() {100return closer.toString();101}102}这是一个典型的适配器模式，因为Google的Guava框架提供的Closer资源管理器只支持实现了java.io.Closeable的资源，对于像java.sql包中的资源，都没有实现该接口，因此，MyCloser提供了对应的适配，使所有的资源管理模式一致。在Java 7之前，这应该是最优雅的资源管理方案。 在Java 7及之后，我们可以使用最新的资源管理语法try-with-resource，上面的代码可以这么写： - Java 代码01try(02InputStream inputStream = new FileInputStream("c:/tmp/a.txt");03Workbook wb = new XSSFWorkbook(inputStream);04Connection con = ServiceLocator.getInstance().getDataSource("jdbc/xxxDS").getConnection();05PreparedStatement ps = con.prepareStatement(sql);){06//do business process07}catch (Exception e) {08logger.error(e.getMessage());09throw e;10}可以看到，我们不用关心资源的关闭了，只要在try()中声明即可，这样的代码是最简洁也是最具表现力的，如果生产环境支持Java 7，最先考虑的应该是这个方案。 当然，由于历史原因，我们可能用到了一些第三方的包，牵涉到资源关闭，但对应的类却没有实现java.lang.AutoCloseable接口，当然也就不能使用try-with-resource语法来操作了，这时，有两种办法，一是提供一个适配的子类，实现java.lang.AutoCloseable接口，在其close中实现资源关闭逻辑，这样就能使用try-with-resource语法了；第二种就是使用MyCloser方案。推荐第一种，因为更简单。