目前支持HTTP/2的服务器端与客户端实现已有不少，探索HTTP/2系列的第二篇就分别以Jetty和curl作为服务器端和客户端，描述了HTTP/2测试环境的搭建过程。本文还将使用这个测试环境去展示Jetty在实现HTTP/2时的一个局限和一个Bug。(2016.09.22最后更新)

1. HTTP/2的实现
    目前已经有众多的服务器端和客户端实现了对HTTP/2的支持。在服务器端，著名的Apache httpd从2.4.17版，Nginx从1.9.5版，开始支持HTTP/2。在客户端，主流的浏览器，如Chrome，FireFox和IE，的最新版均支持HTTP/2，但它们都只支持运行在TLS上的HTTP/2(即h2)。使用Java语言实现的，则有Jetty和Netty，它们都实现了服务器端和客户端。此处有一份HTTP/2实现的列表：https://github.com/http2/http2-spec/wiki/Implementations
    另外，还有一些工具支持对HTTP/2的分析与调试，如curl和WireShark。这里也有一份此类工具的列表：https://github.com/http2/http2-spec/wiki/Tools

2. 服务器端
    作为Java程序员，选用一款使用Java语言编写的开源HTTP/2服务器端实现似乎是很自然的结果。实际上，在日后的研究中，我们也需要查看服务器端的源代码。这对于深入地理解HTTP/2，并发现实现中可能的问题，具有现实意义。
    本文选择Jetty的最新版本9.3.11作为服务器端。Jetty是一个成熟的Servlet容器，这为开发Web应用程序提供了极大便利。而本文第1节中提到的Netty是一个传输层框架，它专注于网络程序。可以使用Netty去开发一个Servlet容器，但这显然不如直接使用Jetty方便。
    安装和配置Jetty是一件很容易的事情，具体过程如下所示。
    假设此时已经下载并解压好了Jetty 9.3.11的压缩文件，目录名为jetty-9.3.11。在其中创建一个test-base子目录，作为将要创建的Jetty Base的目录。
在创建Base时，加入支持http，https，http2(h2)，http2c(h2c)和deploy的模块。
    注意，在上述过程中，会根据当前环境变量中使用的Java版本(此处为1.8.0_60)去下载一个对应的TLS-ALPN实现jar文件(此处为alpn-boot-8.1.5.v20150921.jar)，该jar会用于对h2的支持。当启动Jetty时，该jar会被Java的Bootstrap class loader加载到类路径中。
    创建一个最简单的Web应用，使它在根目录下包含一个文本文件index，内容为"HTTP/2 Test"。再包含一个简单的Servlet，代码如下：
web.xml主要是定义了一个Servlet，具体内容如下：
该应用的部署路径为jetty-9.3.11/test-base/webapps/test.war。在该WAR文件所在的目录下，创建一个test.xml，其内容如下所示：
启动Jetty服务器，使用默认的HTTP和HTTPS端口，分别为8080和8443。
    根据上述日志可知，Jetty启用了Web应用test.war，还启动了两个ServerConnector，一个支持h2c，另一个支持h2。值得注意的是，这两个ServerConnector还分别支持h2c-17, h2c-16, h2c-15, h2c-14和h2-17, h2-16, h2-15, h2-14。这是因为，HTTP/2在正式发布之前，先后发布了18个草案，其编号为00-17。所以，这里的h2c-XX和h2-XX指的就是第XX号草案。

3. 客户端
    其实最方便的客户端就是浏览器了。只要使用的FireFox或Chrome版本不是太老，肯定都已经支持了HTTP/2，而且这一功能是默认打开的。也就是说，当使用FireFox去访问前面所部署的Web应用时，就是在使用HTTP/2，但你不会感觉到这种变化。使用FireFox提供的Developer Tools中的Network工具查看服务器端的响应，会发现HTTP版本为HTTP/2.0。但此处希望这个客户端能够提供更为丰富的与服务器端进行交互的功能，那么浏览器就并不合适了。
    Jetty也实现了支持HTTP/2的客户端，但这个客户端是一个API，需要编写程序去访问HTTP/2服务器端。而且，目前该API的设计抽象层次较低，需要应用程序员对HTTP/2协议，比如各种帧，有较深入的了解。这对于初涉HTTP/2的开发者来说，显然很不合适。本文选择使用C语言编写的一个工具，其实也是HTTP/2的客户端实现之一，curl。
    curl在支持HTTP/2时，实际上是使用了nghttp2的C库，所以需要先安装nghttp2。另外，为了让curl支持h2，就必须要有TLS-ALPN的支持。那么，一般地还需要安装OpenSSL 1.0.2+。
    网络上关于在Linux下安装支持HTTP/2的curl的资源有很多，过程并不难，但有点儿繁，要安装的依赖比较多，本文就不赘述了。如果是使用Windows，笔者比较推荐通过Cygwin来安装和使用curl。在Windows中安装Cygwin非常简单，在Cygwin中执行各种命令时，感觉上就如同在使用Linux，尽管它并不是一个虚拟机。通过Cygwin安装curl，它会自动地安装所需的各种依赖程序和库。
    在笔者的机器上，通过查看curl的版本会出现如下信息：
由上可知，笔者使用的curl版本是7.50.2，nghttp2版本是1.14.0，而OpenSSL版本是1.0.2h。

4. 第一次尝试
    在第一次尝试中，只需要简单地访问第2节中部署的Web应用中的静态文本文件index，以感受下h2c，完整命令如下：
在输出中包含有如下的内容：
">"是客户端发送的请求，"<"是服务器端发送的响应，而"*"是curl对当前过程的说明。结合本系列第一篇文章中所简述的HTTP 2协议，可以有以下的基本理解。
[1]客户端发起了一个HTTP/1.1的请求，其中携带有Upgrade头部，要求服务器端升级到HTTP/2(h2c)。
[2]服务器端同意升级，返回响应"101 Switching Protocols"，然后客户端收到了101响应，HTTP/2连接进行确认。
[3]服务器端响应最终结果。状态行中出现的HTTP版本为HTTP/2，状态代码为200，且后面没有跟着"OK"。最后输出了index文件的内容"HTTP/2 Test"。

5. 一个局限
    这次，在发起的请求中包含体部，命令如下：
在输出中包含有如下的内容：
    和第4节中的输出进行比较，会发现缺少了"101 Switching Protocols"那一段，而且最终响应状态行中出现的HTTP版本是HTTP/1.1。这就说明服务器端不同意升级，后面继续使用HTTP/1.1。刚刚部署的Jetty未做任何改变怎么会突然不支持HTTP/2了呢？或者这是curl的问题？其实，这是因为Jetty服务器端在实现h2c时不支持请求中包含体部。另外，Apache httpd也有同样的问题。如果是使用h2，则没有这个限制。这背后的原因超出了本文的范畴，不作表述。

6. 一个Bug
    在这次尝试中，测试一下两端对100-continue的支持。如果请求中使用了头部"Expect: 100-continue"，那么正常地该请求要有体部。但由于在第5节中介绍的问题，此时不能再使用h2c，而只能使用h2。另外，这次不访问静态文件，而是访问Servlet(此处为/test)。完整命令如下：
在输出的最后出现了如下信息：
这其实是Jetty的一个Bug，正在开发中的9.3.12已经修复了它。

7. 小结
    HTTP/2依然算是新潮的技术，对各家的实现，无论是服务器端，客户端，还是分析工具，都要持有一份怀疑态度。这些实现和工具都是程序，都有可能存在bug。而且协议对许多细节没有作出规定，各家都会发挥自己的想像力。比如，Apache httpd和Jetty在实现服务器端推送时，其方式就不尽相同。
    在开发自己的HTTP/2实现或应用的时候，需要同时使用已有的不同服务器端和客户端去部署多套测试环境进行对比分析。

John Jiang 2016-09-20 16:42 发表评论

3. 覆盖Java核心API？
开发者们在使用主流IDE时会发现，如果工程有多个jar文件或源文件目录中包含相同的类，这些IDE会根据用户指定的优先级顺序来加载这些类。比如，在Eclipse中，右键点击某个Java工程-->属性-->Java Build Path-->Order and Export，在这里调整各个类库或源文件目录的位置，即可指定加载类的优先级。
当开发者在使用某个开源类库(jar文件)时，想对其中某个类进行修改，那么就可以将该类的源代码复制出来，并在Java工程中创建一个同名类，然后指定Eclipse优先加息自己创建的类。即，在编译时与运行时用自己创建的类去覆盖类库中的同名类。那么，是否可以如法炮制去覆盖Java核心API中的类呢？
考虑去覆盖类java.util.HashMap，只是简单在它的put()方法添加一条打印语。那么就需要将src.zip中的java/util/HashMap.java复制出来，并在当前Java工程中创建一个同名类java.util.HashMap，并修改put()方法，如下所示：
此时，在Eclipse环境中，SynchronizedHashMap使用的java.util.HashMap被认为是上述新创建的HashMap类。那么运行应用程序SyncMapTest后的期望输出应该如下所示：
但运行SyncMapTest后的实际输出却为如下：
看起来，新创建的java.util.HashMap并没有被使用上。这是为什么呢？能够"想像"到的原因还是类加载器。关于Java类加载器的讨论超出了本文的范围，而且关于该主题的文章已是汗牛充栋，但本文仍会简述其要点。
Java类加载器由下至上分为三个层次：引导类加载器(Bootstrap Class Loader)，扩展类加载器(Extension Class Loader)和应用程序类加载器(Application Class Loader)。其中引导类加载器用于加载rt.jar这样的核心类库。并且引导类加载器为扩展类加载器的父加载器，而扩展类加载器又为应用程序类加载器的父加载器。同时JVM在加载类时实行委托模式。即，当前类加载器在加载类时，会首先委托自己的父加载器去进行加载。如果父加载器已经加载了某个类，那么子加载器将不会再次加载。
由上可知，当应用程序试图加载java.util.Map时，它会首先逐级向上委托父加载器去加载该类，直到引导类加载器加载到rt.jar中的java.util.HashMap。由于该类已经被加载了，我们自己创建的java.util.HashMap就不会被重复加载。
使用java命令运行SyncMapTest程序时加上VM参数-verbose:class，会在窗口中打印出形式如下的语句：
从中可以看出，类java.util.HashMap确实是从rt.jar中加载到的。但理论上，可以通过自定义类加载器去打破委托模式，然而这就是另一个话题了。

John Jiang 2015-11-01 20:06 发表评论

John Jiang 2015-10-30 23:17 发表评论

利用Java SE 8流处理数据
-- 结合Stream API的高级操作去表示富数据处理查询

John Jiang 2014-08-15 19:57 发表评论

本文是Java Magazine 201403/04刊中的一篇文章，也是文章系列"利用Java SE 8流处理数据"中的第一篇，它概述了Java流的基本原理与基本应用，是一篇很好的Java Streams API的入门文章。(2014.07.27最后更新)

    没有集合对象，你会怎么样？几乎每个Java应用都会创建并处理集合。它们是许多编程任务的基础：集合使你能够对数据进行分组和处理。例如，你也许会创建一个关于银行交易的集合，该集合代表了某个用户的银行流水清单。然后，你可能想要处理整个集合去算出该用户花了多少钱。尽管数据处理十分重要，但Java在此方面表现的远不完美。
    首先，典型的集合处理模式与类SQL操作相似，诸如"查找"(如找出最大金额的那笔交易)或者"分组"(如，将与购买杂货相关的交易进行分组)。大部分数据库允许你以声明的形式去指定这些操作。例如，后面的SQL查询会让你找到那笔最大金额交易的ID："SELECT id, MAX(value) from transctions"。
    如你所见，我们并不需要去实现如何计算最大值(例如，使用循环和一个变量去追踪这个最大值)。我们仅需要表达什么是我们想要的。这种基本思想就意味着，你不太需要担心去显式地实现这些查询--它们已经为你处理好了。为什么我们不能在处理集合时也这样做呢？你发现自己有多少次都是在一遍又一遍地使用循环去重复实现这些操作呢？
    其次，我们如何才能更高效地去处理大型集合？理想情况下，在加速进行处理时，你会想到利用多核架构。然而，编写并行程序既困难又容易出错。
    Java SE 8赶来帮忙了！Java API的设计者们在升级API时引入了一种新的称之为Java流(流)的抽象，它允许你以声明形式去处理数据。另外，Java流可以利用到多核架构而不必编写一行多线程代码。听起来不错，不是吗？这就是本文章系列所要探究的主题。
    Java流能为我们做些什么呢？在探究这些细节之前，让我们先看一个例子，这样你才能对这种新的使用Java SE 8 Java流的编程风格有感觉。假设我们要找到所有类型为grocery的交易并返回它们的ID列表，并按交易金额的递减顺序对该列表进行排序。在Java SE 7中，我们应该会把清单1所示的程序那样去做。而在Java SE 8中，我们则会像清单2所示的那样去实现。
清单1

清单2

    图1形象地解释了那段Java SE 8程序。首先，我们调用List对象中的Java流()方法从交易列表(数据)中获取一个Java流对象。然后，多个操作(过滤，排序，映射，归集)链接在一起形成了一条线，这条线可以被看作构成了一条数据查询。


    那么如何并行地执行该程序呢？在Java SE 8中这很简单：只需要使用parallelJava流()方法去替换Java流()方法，如清单3所示。Java流 API会在内部对你的查询进行解构，并利用上你机器中的多核处理器。
清单3

    在该关于Java SE 8 Java流的文章系列结束时，你将能够使用Java流 API编写出像清单3那样的功能强大的查询程序。

Java流入门
    让我们先从一点理论开始。Java流的定义是什么？一个简短的定义就是"来自于一个数据源的能够支持聚合操作的一串元素"。让我们把它拆开来说：
    一串元素：Java流为一串特定类型值的集合提供了一个接口。然后，Java流实际上并不存储元素，它们会在需要时被用上。
    数据源：Java流要使用一个提供数据的源，诸如集合对象，数组或I/O资源。
    聚合操作：Java流支持类SQL的操作，以及来自于函数编程语言的通用操作，诸如过滤，映射，归一，查找，匹配，排序，等等。
    另外，与集合操作非常不同的是，Java流操作拥有两项基本特质：
    管道：许多Java流操作会返回它们自己，这就使得这些操作能够链接在一起以组成一个大型管道。这样就可以进行一些诸如惰性和短路之类的优化，后面我们会进行探究。
    内部遍历：集合是显式地进行遍历(外部遍历)，但不同于集合，Java流是在幕后进行遍历。让我们重新看看之前的示例代码来解释这些原理。图2形象地解释了清单2的更多细节。


    首先，通过调用Java流()方法，我们从交易列表中得到了一个Java流对象。那么数据源就是交易列表，它将向Java流中提供一串元素。然后，我们对该Java流应用了一系列的聚合操作：过滤(提供一个谓语去过滤元素)，排序(提供一个比较器去对元素进行排序)，以及映射(解析出信息)。所有的操作都会返回该Java流，以便能够链接这些操作去组成一个管道，这可被看作是对数据源的一个查询。
    在调用collect()操作之前，没有实际工作会被执行。collect()方法将开始处理这个管道以返回一个结果(某个不是Java流的对象，在此处，是一个List对象)。现在还不需要去关注collect()方法，我们会在以后的文章去一探究竟。此时，你会发现collect会将各种数据加工方法作为参数，将收集到的Java流元素归结为一个结果。此处，toList()就描述了一个将Java流对象转化为List对象的加工方法。
    在探究与Java流有关的各个方法之前，最好是停下来深入思考一下Java流和集合之间观念上的不同之处。

Java流 vs. 集合
    已有的Java集合概念与新的Java流概念都为一串元素提供了接口。那它们有何不同吗？简单地说，集合是关于数据的，而Java流是关于计算的。
    想想这种情况，一部存储在DVD中的电影。这就是一个集合(可能是字节，可能是帧--在此处，我们不必关心这些)，因为它包含有全部的数据结构。现在再想想这种情况，这部电影被转化成了数据流，通过互联网去观看它。此时它就是一个(字节或帧的)流。流视频播放器只需要下载一些晚于用户当前所观看位置的帧就可以了。这样，你就可以在大部分值被计算出来之前先展示流开头处的值(想想流化一场现场直播的足球比赛)。
    粗看之，集合与流的区别就是与何时处理数据有关。集合是内存中的数据结构，它包含有当前数据结构中的全部值--将所有元素加入到集合之前，必须先对所有元素进行处理，相反地，Java流只是逻辑上固定的数据结构，它里面的元素只会根据需要进行处理。
    使用Collection接口，要求用户实现遍历(例如，使用增强的for循环，即foreach)；这被称之为外部循环。相反地，Stream类库使用内部遍历--它已经为你实现好了遍历，它会关心存储流的结果值的位置；你仅需要提供一个函数告诉它要做些什么就行了。清单4(对集合的外部遍历)和清单5(对Java流的内部遍历)中的代码形象地展示了这一不同之处。
清单4

清单5

    在清单4中，我们显式且顺序地遍历了交易列表，抽取了每个交易ID，然后将它加到一个收集器中。相反地，当使用流时，没有显式的遍历。清单5中的代码构建了一个查询，其中的map操作被设定为一个参数，它会抽取交易ID，然后collect操作会把结果Stream对象转化成一个List对象。
你现在应该知道什么是Java流，以及如何去使用它。现在让我们看看Java流所支持的操作之间的区别，这样你就能构建自己的数据查询了。

Java流操作：使用流去处理数据
    java.util.stream.Stream接口定义了许多操作，它们可被归集为两类。在图1所示的例子中，你可以看到如下操作：
    过滤，排序和映射，它们可被连接在一起组成一个管道
    收集，它关闭了这个管道并返回结果
    能够被连接在一起的Java流操作被称为中间操作。这些操作之所以能被连接在一起，是因为它们都会返回Stream对象。这些操作从这个管道中返回结果，结果的类型可以是List，Integer，甚至是void(任何Stream以外的类型)
    你也许很好奇为什么这种区别很重要。是这样的，在这个Java流管道的最终操作被调用之前，中间操作并不会执行任何处理；它们是"惰性"方法。这是因为中间方法经常会被"合并"，在最终操作中它们会被合成为单一的执行路径。
清单6

    例如，思考下清单6中的程序，它是从给定的数列中计算奇数的平方。你可能会很惊讶，它打印出如下结果：

    这是因为limit(2)使用了短路；我们只需要处理流的一部分，而不是全部，去得到一个结果。这就类似于测评一个由and操作符关联起来的大型布尔表达式链：一旦某个表达式返回了false，那么就可以认为整个表达式链就是false，而不必测评所有的表达式了。在这个例子中，limit()方法将返回的Java流的长度限定为2。另外，filter与map被合并在了同一条执行路径中了。

    归纳一下到目前为止，在使用Java流时我们所学到的内容，总言之，涉及三个方面：
    一个数据源(例如一个集合)，对它执行查询
    一个中间操作的链，它组成一个流的管道
    一个最终操作，它执行流的管道并产生结果
    现在让我们看看Java流所支持的一些操作。参考java.util.stream.Stream接口可以得到这些方法的完整清单，再看看本文末尾所给出的资源，它包含有更多的例子。

    过滤。有多种方法可以对流中的元素进行过滤：
    filter(Predicate)：使用一个谓语(java.util.function.Predicate)作为参数，它会返回一个包含所有匹配给定谓语条件元素的Java流。
    distinct：返回一个包含有唯一元素的Java流。
    limit(n)：返回的流的长度不能超过n。
    skip(n)：返回的流将不包括前n个元素。

    查找与匹配。一个通用的数据处理模式就要考虑一些元素是否匹配给定的属性。你可以使用anyMatch，allMatch和noneMatch方法帮你做到这一点。这些方法都会使用一个谓语参数并返回boolean值作为结果(所以，它们是最终操作)。例如，使用allMatch去查出交易流中所有金额大于100的交易，如清单7所示。
清单7

    另外，Stream接口提供了方法findFirst和findAny，以取出流中任一元素。它们可以与其它的流操作，如filter，结合起来使用。findFirst和findAny都会返回一个Optinal对象(见清单8)。
清单8

    Optional<T>类(java.util.Optional)是一个容器类，它代表一个存在或不存在的值。清单8中的程序，findAny方法可能没有找到任何类型为grocery的交易。Optional类包含多个方法去测试一个元素是否存在。例如，如果交易存在，通过使用ifPresent方法，我们可以选择一个操作去应用这个Optaional对象，如清单9所示(此处只是打印交易)。
清单9

    映射。Java流支持map方法，它使用一个函数(java.util.function.Function)作为参数，将流元素投影到其它形式。这个函数会被应用到每个元素，并将元素"映射"到新的元素。
    例如，你可能会想到使用它去抽取流中每个元素的信息。在清单10的例子中，我们返回了一个列表中每个字的长度。
清单10

    归一。到目前为止，我们已见过的最终操作会返回boolean(allMatch等等)，void(forEach)或Optaional对象(findAny等等)。我们也使用collect方法将Stream对象中的所有元素放到一个List对象中。
    然而，你也可以将流中的元素放到一个查询中，该查询可表达更为复杂的数据处理，例如"拥有最大ID"或者"算出所以交易金额的和"。这就可能对Java流用上reduce方法，该方法会对每个元素重复地应用一个操作(例如，加上两个数字)，直到生成结果。在函数式编程中，这常被称为折叠操作。因为该操作可被看作重复地"折叠"一张很长的纸(Stream对象)，直到这张纸的面积变得只有一点儿了。这就是折叠操作的结果。
    看看我们是如何使用循环去计算一个组数字的和会有助于理解这个问题：

    列表中的每一个数字元素都被迭代地组合在一起，并使用一个额外的操作符去产生结果。本质上，我们就是把一组数字"归一"成一个数字。在这段代码中有两个参数：数字和变量的初始值，即该例中的0，以及用于合并所有元素的操作符，即本例中的+。
清单11

    对Java流使用reduce方法，我们可以计算出流中的所有元素值之和，如清单11所示。reduce方法使用两个参数：
    初始值，0
    BinaryOperation<T>，合并两个元素，并产生一个新值
    reduce方法本质上就是重复应用模式的抽象。其它的查询，如"计算产量"或"计算最大值"(如清单12所示)则是reduce方法的特别实例。
清单12

数字流
    你已经看到可以使用reduce方法去计算整数流的和。然后，这也是有成本的：我们重复执行了许多拆箱操作以将Integer对象加到一起。如果我们能调用一个sum方法，使程序的意图更为明显，就像清单13那样，岂不是更好？
清单13

    Java 8引入的三个特定的基本数据类型的流接口来应对这个问题--IntStream，DoubleStream和LongStream--它们专注于元素分别为int，double和long型的Java流。将一个流转化为特定类型的流，你最常使用的方法就是mapToInt，mapToDouble和mapToLong。这些方法与我们较早前看到的map方法是一样的，但它们会返回特定类型的Stream对象，而不是Stream<T>对象。例如，我们可以改进下清单13中的代码，如清单14所示那样。你也可以使用装箱操作将一个基本数据类型的流转化成一个使用包装对象的流。
清单14

    最后，数字流的另一种有用的形式是数字区间。比如，你可能想生成介于1到100之间的所有数字。为了帮助生成这种区间，Java SE 8在IntStream，DoubleStream和LongStream中分别引入了两个静态方法：range和rangeClosed。
    这两个方法都会使用两个参数，第一个参数是起始值，第二个参数是终止值。但是range方法生成的区间不会包含终止值本身，但rangeClosed生成的区间则会包含。清单15是一个使用rangeClosed方法的例子，它返回一个包含有全部介于10到30之间奇数的流。
清单15

构建流
    有多种途径可以去构建一个流。你已经看过如何从集合对象中构建流。另外，我们还操控过数字流。你也可以从值，数组或文件中去创建流。另外，你甚至于可以从一个函数中生成无限流。
    可以直截了当地从值或数组中创建流：只需要使用一些静态方法即可，对于值，是Stream.of()；而对于数组，则要调用Arrays.stream()。如清单16所示。
清单16

    你也可以将一个文件转化为其内容行的流，使用静态方法Files.lines()即可。清单17就使用该方法计算了文件中行的数量。
清单17

    无限流。最后，在总结本文之前，有一个令人非常兴奋的主意。到现在为止，你应该理解到流中的元素是按需生成的。有两个静态方法--Stream.iterate()和Stream.generate()--可以让你从一个函数中创建流。然而，因为被使用的元素是按需生成的，所以这两个方法可以"永远地"生成元素。这就是为什么我们称它为无限流：它就是没有固定大小的流，但它做的事情与一个从固定集合生成的流是一样的。
    清单18就是一个使用iterate方法的例子，它会包含10的所有倍数。iterate方法使用一个起始值(此处的0)和一个Lambda表达式(类型为UnaryOperator<T>)去顺序地生成每一个新值。
清单18

    我们也可以使用limit方法，以从一个无限流中得到一个固定流。如清单19所示，可以将流的长度限制为5。
清单19

结论
    Java SE 8引入了Streams API，它让你能够表达更为复杂的数据处理查询。在本文中，你已见到流可以支持许多操作，诸如过滤，映射，归一和迭代，把它们结合在一起可以写出简洁的、更富表现力的数据处理查询。这种新的编程方法远不同于Java SE 8之前的集合处理。但是，它有许多好处。首先，它利用到了诸如惰性或短路这样的技术，以优化数据处理查询的性能。其次，能够自动地利用上多核架构，以并行地处理流。在本文章系统的第二部分中，我们将探索更高级的操作，例如flatMap和collect。请继续关注。

John Jiang 2014-07-27 20:54 发表评论

John Jiang 2014-04-19 23:48 发表评论

John Jiang 2014-02-28 15:25 发表评论

本文是发布在java.net上的一篇摘自于<Gradle in Action>一书中的节选，介绍了使用Gradle构建Java Web应用的过程。刚刚接触Gradle，看到了这篇小文，随手译了出来:-) (2014.01.23最后更新)

当今世界，一派繁忙。在职业生涯和私人生活中，我们中间的许多人要同时管理多个项目。你可能常常发现自己处于不知所措及失控的状态。保持规整并专注于价值的关键是一个维护良好的工作清单。当然，你可能总是把你的任务写在一张纸上，但是你也许不可能在你所处的任何地方都可方便地获得这些工作条目？对互联网的访问几乎是无处不在的，无论是通过你的移动电话，还是公共的网络接入点。在<Gradle in Action>一书中，如图1所示的说明性示例是一个很有吸引力的可视化Web应用。

图1 To Do应用可以通过互联网进行访问，并使用它去管理数据存储中的工作条目

Gradle插件表现的如同一个使能器，它会自动地执行这些任务。一个插件通过引入特定领域的规范以及对缺省值敏感的任务去对工程进行扩展。随Gradle发布的插件之一就是Java插件。该Java插件绝不仅仅是提供了源码编译和打包这样的基础功能。它为工程建立了一整套标准的目录布局，它会确保以正确的顺序去执行任务，这样，这些任务在Java工程环境中才是有意义的。现在是时候为我们的应用去创建一个构建脚本并去使用这个Java插件了。

构建Java应用
一开始，每个Gradle工程都会创建一个名为build.gradle的构建脚本。为了创建该脚本，并告诉该工程使用Java插件，应该像这样去做：
为了构建你的Java代码，一行代码就够了。但Gradle怎么知道去哪儿找你的源文件呢？该Java插件引入的规范之一就是源代码的路径。默认地，该插件会到目录src/main/java中搜寻产品的源代码。

构建Web应用
通过War插件，Gradle也提供了构建Web应用的扩展支持。War插件扩展了Java插件，它加入了针对Web应用程序开发的规范，并支持归集WAR文件。让我们也在这个工程中用用War插件：
Web应用源文件的默认路径是src/main/webapp。假设你已经明确了该应用所必要的Java类。那么要使产品的全部源代码和Web资源文件处于正确路径下，该工程的目录布局应该像下面这样：

声明外部依赖
在实现这个Web应用的过程，我们使用的一些类，例如javax.servlet.HttpServlet，并非Java标准版(Java SE)的一部分。在构建工程之前，我们需要确保已经声明了这些外部依赖。在Java系统中，依赖类库是以JAR文件的形式去发布和使用的。许多类库可以从仓库，如一个文件系统或中央服务器，中获得。为了使用依赖，Gradle要求你至少定义一个仓库。出于一些考虑，我们将使用公共的可通过互联网进行访问的Maven Central仓库。
在Gradle中，依赖是通过配置项来进行分组的。我们将来Servlet依赖使用的配置项是providedCompile。该配置项用于那些在编译时而非运行时所需的依赖。像JSTL这样的运行时依赖，在编译时不会被用到，但在运行时则会被用到。它们都会成为WAR文件的一部分。下面的配置语句块声明了我们应用所需的外部类库：

构建工程
我们已经准备好构建这个工程了。另到工程中的一个Java插件任务名为build。该任务将编译源代码，运行测试程序并归集WAR文件--所有的这些任务都将以正确的顺序被执行。执行命令gradle build之后，你可能会得到形如下面的输出：

上述输出的每一行都代表执行了一个由Java或War插件提供的任务。你可能会注意到，有一些任务被标记为UP-TO-DATE。它的意思是指该任务被跳过去了。Gradle的增量构建支持策略会自动识别不需要执行的工作。特别是在大型商业项目中，该特性会极大地节省时间。
在该工程的根节目录中，你将会发现一个名为build的子目录，它包含有执行构建之后的全部输出，包括类文件，测试报告，归集的WAR文件，以及像manifest这样的在打包时需要的临时文件。如下就是执行构建工作之后的工程目录结构：
你已经知道如何从一个基于标准目录结构的Web工程去构建WAR文件。现在是时候将它布署到一个Servlet容器中去了。在下一节中，我们将在本地开发机器中启动Jetty去运行这个Web应用。

运行应用
在本地机器中运行一个Web应用应该很容易，能够实践快速应用开发(RAD)，并能够提供快速的启动时间。最棒地是，它不要求你部署一个Web容器运行时环境。Jetty一个流行的轻量级开源Web容器，它支持前面提到的所有特性。在这个Web应用中加入一个HTTP模块，它就变成了一个嵌入式实现。Gradle的Jetty插件扩展了War插件，它提供的任务可以将一个Web应用部署到嵌入式容器中，并能够启动该应用。在你的构建脚本中，可以像如下那样使用这个插件：
这个将被我们用于启动Web应用的任务名为jettyRun。它甚至可以在无需创建WAR文件的情况下启动一个Jetty容器。执行上述命令后会得到如下形式的输出：
在上述输出的最后一行中，该插件告诉了你Jetty即将侦听的请求地址。打开一个你喜欢的浏览器，并输入上述地址。最后，我们会看到这个To Do Web应用的行为。图2展示在一个浏览器中查看到该应用界面的截屏。

图2 To Do应用的Web界面及其行为

在你通过组合键CTRL+C去停止这个应用之前，Gradle会让它一直运行。Jetty如何知道使用哪个端口和上下文环境去运行这个Web应用？再说一遍，这就是规范。Jetty运行Web应用所使用的默认端口就是8080。

总结
只需要较少的努力，你就可以使用Gradle去构建并运行一个Java Web应用。只要你严格遵循标准目录结构，那么你的构建脚本仅需要两行代码。

John Jiang 2014-01-23 21:22 发表评论

John Jiang 2013-12-29 20:19 发表评论

John Jiang 2013-12-07 17:45 发表评论

John Jiang 2013-10-23 23:27 发表评论

相应地修改应用程序的代码，如代码清单9所示，

John Jiang 2013-10-07 16:55 发表评论

John Jiang 2013-09-21 19:11 发表评论

John Jiang 2013-02-06 00:04 发表评论

John Jiang 2013-01-17 22:39 发表评论

John Jiang 2013-01-01 16:26 发表评论

关于Object类中的equals()方法与Comparable接口中的compareTo()方法之间有何种关联，之前还真没考虑过。通过java.net看到此文之后，收获了一点儿新知识，希望大家也能如此。(2012.12.09最后更新)

    方法equals()与Comparable接口中的compareTo()方法是Java中最基本的两个方法之一，然而它们的定义却围绕着"与相等一致"这一有趣的概念。

equals()方法
    Java中的equals()方法既明确，又模糊。Java清楚地定义了如何准确地检验一个equals()方法是可用的。一个恰当的equals()方法必须是自反的，对称的，可传递的，一致的，并能处理null引用。
    然而equals()方法又是不清晰的。Javadoc说到，该方法指定了其它对象是"等于"这个对象的。注意，"等于"是放在引号中的。此处的关键就是，它没有定义如何去判定这种相等性。

• 对象的一致性(==)默认是继承自Object类
• 对象的整体可观测的状态，例如，若两个对象是相等的，那么在应用的其它部分可以用一个对象去替代另一个对象。
• 对象信息中的某些部分，如ID，使得检验对象相等性在逻辑上是有意义的。

compareTo()方法
     Comparable接口定义了可比较性的概念。Javadoc指出compareTo()方法"强制设定了每个实现了该接口的类的对象的全部顺序"。
     实现了Comparable接口的类有一个天然的排序，这可便于存储，也能在不使用单独的Comparator的情况下，用于像TreeSet和TreeMap这样的集合对象。
     该接口的定义明晰，它要求其实现必须确保对称性与传递性，就像equals()方法那样。

一致性/非一致性相等
Comparable接口有如下描述：
    类C的天然排序意味着要与equals()方法保持一致，只有当且仅当e1.compareTo(e2) == 0与e1.equals(e2)有相同的布尔值。
    基本上，这就要求由compareTo()定义的相等性与equals()方法定义的相等性具有相同的概念(除去有null的情况)。乍一看，该要求很简单，但实际上它有其复杂性，后面将会讨论到。
    当考虑到操作符重载时，这种定义就特别有用。若我们假设有一种类Java语言，在这种语言中，==并不表示对象的同一性，而是通过方法去进行比较，大于/小于操作符也是如此，问题是调什么样的方法。在类Java语言中大于/小于天然地就要基于compareTo()方法，而==则要调用equals()方法。
    但如果compareTo()方法不是"一致性相等"，那么上述代码将会抛出异常，因为当a.equals(b)为false时，a.compareTo(b)会返回0。
    在集合，如TreeMap，中还会发生其它问题：
    当使用equals()方法时，这两个对象不相等，但使用compareTo()时，它们却相等。在这种情况下，该Map的元素个数将为1，而非0。
    由于这些"一致性相等"的问题，Javadoc说道"强烈建议(尽管并不要求)天然排序规则要与equals()方法保持一致"。
    JDK中的许多类为了符合"一致性相等"这一规范而实现了Comparable接口。这些类包括Byte，Short，Integer，Long，Character和String。

还有些更有趣的类：
    BigDecimal--肯定是"非一致性相等"，比如4.00与4.0不一致，但进行比较时，认为它们是一样的。
    Double/Float--该类显式地提供了排序规则，并为正零和负零，以及NaN都提供了相等性检查，以确保它的compareTo()方法符合"一致性相等"。
    CharSet--该类基于ID或名称。equals()方法对待字段串是大小写敏感的，但compareTo()方法却不这样。虽然名称一般会符合某种标准，但这是一种值得怀疑的"一致性"。
    *Buffer(nio)--该簇类的比较基于缓冲存放的内容，在我的测试中equals()和compareTo()是"一致的"。
    Rdn(ldap)--该类的比较基于状态的标准化格式，因此也是"一致性相等"。
    ObjectStreamField(序列化)--该类的比较基于名称，但会首先对基本数据类型进行排序。因为没有覆盖equals()方法，所以是"非一致性相等"。
    ...
    注意：对于大多数的例子，我都不得不查看其源代码或编写测试程序以确定该类是不是符合"一致性相等"。这儿有一个不错地清理Javadoc和检验UUID equals()方法的Adopt-a-JDK任务。

JSR-310
    一直看到许多关于BigDecimal的问题，已有计划将JSR-310中的类改造成"一致性相等"，最近的一些帖子显示这将造成多么大的争议。
    基本上，为某些类定义equals()和compareTo()看起来很容易。LocalDate表示某单一日历系统中的某个日期，所以它有一个显而易见的排序算法和相等规则。LocalTime则表示某个时刻，所以它也有一个明显的排序算法和相等规则。Instant表示时间线上的某个时刻，那么它的排序与相等也是显见的。
    但在其它的情况下，这就不是那么显而易见了。考虑这样一个类OffsetDateTime：
    这样的两个日期-时刻对象代表时间线上一个相同的时刻点，但它们有不同的本地时，而且相对的UTC/格林威治时间的偏移量也不相同。
    那么就有一个问题要留给读者们...你更倾向于如下哪种观点...
    1. dt1不等于dt2，compareTo()分别比较本地时与偏移量，使用"一致性相等"(使用独立的Comparator基于时刻对其进行排序)。
    2. dt1不等于dt2，compareTo()基于时间线的上时刻点，使用"非一致性相等"。
    3. dt1等于dt2，compareTo()基于时间线的上时刻点，使用"一致性相等"。
    4. dt1等于dt2，且不实现Comparable接口。
    5. dt1不等于dt2，且不实现Comparable接口。
    我个人更倾向于让dt1.equals(dt2)返回true这种方案，但我仍持开放态度。
    顺便地，也可以将这个问题提给BigDecimal，如果你能修改这个类，使其符合"一致性相等"，你会修改它的equals()方法，还是compareTo()方法？

John Jiang 2012-12-06 23:14 发表评论

John Jiang 2012-11-26 23:41 发表评论

    已有太多关于自定义部局管理器的文章了。本文仅是一篇学习笔记，描述了如何实现一种像堆金字塔似的部局管理器，很简单，也有点儿意思，可能你也会感兴趣的。(2012.07.17最后更新)   

    I have developed Swing application for several years, although I'm not professional GUI developer, I'm shamed of never creating any custom layout manager. Maybe the existing Swing layout managers are too powerful to create new ones. At least, GridBagLayout is powerful enough for my real works. And we have much more flexible GroupLayout and SpringLayout, of course, both of them are too complex, in fact I never use them directly. However I indirectly take advantage of GroupLayout due to using NetBeans' GUI designer Matisse.

1. Layout Manager basics
    Let's start with some layout manager foundation. Before this time I learn to customize layout, I always think layout manager is very mysterious. Layout is like a magic player that put a variety of components to right positions in containers. I haven't browsed any code of any layout, event the simplest one. That's why I think layout is mystery. But it's simple for me now.
    Generally, all of layout implements one or both of LayoutManager and LayoutManager2 interfaces. LayoutManager2 is LayoutManager's sub-interface, then if someone implements LayoutManager2 that means it really implements LayoutManager. Mostly all modern layouts implements LayoutManager2.
    Interface LayoutManager defines the basic methods must be implemented by every layout, all of them are intuitional: add new component--addLayoutComponent(); remove component--removeLayoutComponent(); calculate preferred size--preferredLayoutSize(); calculate minimum size--minimumLayoutSize(); how to layout the components--layoutContainer(). Absolutely, the layoutContainer() method is essential, you must instruct the parent container how to allocate space(bounds) for every component.
    The extension interface LayoutManager2 introduces more methods that if you have to: support constraints--addLayoutComponent(Component, Object); specify maximum size--maximumLayoutSize(); specify alignment--getLayoutAlignmentX() and getLayoutAlignmentY(); destroy specific caches or reset some variables when invaliding container--invalidateLayout().

2. PyramidLayout
    Now let's feature a simple and funny layout manager--PyramidLayout. The layout allows container to add components like building a Pyramid, as shown as the image below,

    As the above, PyramidLayout puts the first component on the bottom, then puts the second on top of the first, but its bounds is smaller, ... It looks like a Pyramid, doesn't it? Here is the full codes,
    Collection instance "comps" manages all of components, in this case, I take a LinkedList object to add and remove UI components. The layout doesn't concern any constraint, so the two addLayoutComponent() methods have the same actions. Please see the codes for details.
    As aforementioned, layoutContainer() method really takes charge of layouting the components. The key work is allocating space for each component, namely, specifying the bounds. Calculating bounds values just applies the simplest arithmetic operations.
    According to the intention, the bottom component fills the whole parent container, so it determines the preferred and the minimum sizes. For details, please take a look at methods preferredLayoutSize() and minimumLayoutSize(). Since the layout manager doesn't take care of the maximum size, the maximumLayoutSize() method simply returns a constant value.