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

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方案。推荐第一种，因为更简单。