在上一篇中尝试了 使用 Javassist 运行时生成泛型子类，这里要用另一个更方便的字节码增加组件 Byte Buddy 来实现类似的功能, 但代码上要直白一些。就是运用 Byte Buddy 在运行时生成一个类的子类，带泛型的，给类加上一个注解，可生成类文件或 Class 实例，不过这里更进一步，实现的方法是带参数的。
用 Byte Buddy 操作起来更简单，根本不需要接触任何字节码相关的，诸如常量池等概念。与 Javassist 相比，Byte Buddy 更为先进的是能生成的类文件都是可加载运行的，不像 Javassist 生成的类文件反编译出来是看起来是正常的，但一加载执行却不那回事。
本例所使用的 Byte Buddy 的版本是当前最新的 1.6.7，在 Maven 项目中用下面的方式引入依赖<dependency>
下面是几个需要在本例中用到的类定义 Read More
<groupId>net.bytebuddy</groupId>
<artifactId>byte-buddy</artifactId>
<version>1.6.7</version>
</dependency>
Java 8 之前如何重复使用注解
在 Java 8 之前我们不能在一个类型重复使用同一个注解，例如 Spring 的注解@PropertySource不能下面那样来引入多个属性文件@PropertySource("classpath:config.properties")
上面的代码无法在 Java 7 下通过编译，错误是: Duplicate annotation
@PropertySource("file:application.properties")
public class MainApp {}
于是我们在 Java 8 之前想到了一个方案来规避 Duplicate Annotation 的错误: 即声明一个新的 Annotation 来包裹@PropertySource, 如@PropertySources1@Retention(RetentionPolicy.RUNTIME) 2public @interface PropertySources { 3 PropertySource[] value(); 4}
然后使用时两个注解齐上阵 Read More
最初接触 Mockito 还思考并尝试过如何用它来 mock 返回值为 void 的方法，然而 Google 查找到的一般都会说用doThrow()的办法doThrow(new RuntimeException()).when(mockObject).methodWithVoidReturn();
因为无法使用常规的when(mockObject.foo()).thenReturn(...)的方法。
当时我就纳闷，为何我想 mock 一个返回值为 void 的方法，却是在模拟抛出一个异常，现在想来如果一个返回值为 void 的方法，为何要去 mock 这个方法呢？
回想一个我们要 mock 一个方法的意图是什么：- 在特定输入参数的情况下期待需要的输出结果(返回值)
- 在方法抛出某种类型异常调用者作出的反应
对于 void 返回值的方法，如果要验证有没有被调用过几次可以在事后用verify()方法去断言。所以基本上对于 void 返回值的方法一般可不用去 mock 它，只需用 verify() 去验证，或者就是像前面一样模拟出现异常时的情况。
所以本文并不像是去直接回答标题所示的问题: Mockito 如何 mock 返回值为 void 的方法，而是如何应对 mock 对象的 void 方法 Read More- Mockito 可以帮助我们创建 Mock 对象，mock 被调用的方法，断言调用次数，在方法参数不易确定的情况下还能帮我们捕获参数。下面是我们第一个问题:
为什么要捕获调用参数
在被 mocker 方法调用参数明确的情况下可无需捕获参数，例如，下面的情景：1@Test 2public void dontCaptureArgument() { 3 UserDao userDao = Mockito.mock(UserDao.class); 4 UserService userService = new UserService(userDao); 5 6 User user = new User(1, "Yanbin"); 7 userService.saveUser(user); //假如它的实现是 userDao.save(user) 8 9 verify(userDao, times(1)).save(user); //断言了 userDao.save(user) 操作的还是 user 对象 10}
如果 UserService 的 save(user) 最终操作的不是同一个对象，它的实现稍加变化如下 Read More 
Vim(Vi Improved) 早已替代了 Vi, 它存在于大多数的 Linux 发行版中。所以基本上 Vi 和 Vim 在你的系统中就是同一个程序，我用的 Mac, vi 命令就是一个指向到 vim 的链接
ls -l $(which vi)
lrwxr-xr-x 1 root wheel 3 Sep 20 23:47 /usr/bin/vi -> vimmacOS Sierra 自带的 Vi/Vim 版本仍然是 7.4，我用
Read Morebrew install macvim安装了最新版的 Vim 8.0, 由于只想启动 MacVim 控制台的 Vim, 所以把 vi/vim 命令链接到新版 Vim 上。Vim 的东西时而学一点，但很快又会忘记，就是最简单的 h, j, k, l 来移动光标都会有所迟疑，因为一直未强迫自己完全脱离方向键来使用 Vim，下个目标是 87 键的键盘都嫌多，打算入一个 61 键的 WSAD 键盘, HHKB 还是有些极端了。
找到了一本学习 Vim 的好书 《Practical Vim》第二版，阅读时把对自己有用的东西仅当笔记记下来备忘，这个其实更应该记录在我的 Evernote 中作为私有笔记。重点的东西我在书中注解了，这里的笔记只能算是一个补充。 Read More
- 用 Java 进行编码基本还是离不开 IntelliJ IDEA 或 Eclipse, 看别人完全用 Vim 进行 Javascript 项目编程很是眼红，估摸着能不能把 Vim 打造成一个更强的 Java IDE。语法高亮是不在话下，最主要是给它加上自动完成功能，不光对当前类，项目中的方法或变能能提示，而且必须像 Java IDE 那样理解所有的项目依赖。这就是今天试用的一个 Vim 插件 vim-javacomplete2，另种可能更好的方案 YouCompleteMe + Eclim 还会再研究。
提到 Vim 的自动完成功能，有必要了解 Vim 自带的提示功能- ctrl - n/p: Vim 根据当前缓冲区的关键字来提示，像 Sublime 或 Visual Studio Code 中的关键字提示
- ctrl - x 进行自动自动完成模式，接着一些操作如 ctrl - l/n/t/i 完成类似于 ctrl - n/p 的操作; ctrl - k 能基于字典自动完成，完整按键是 ctrl - x ctrl -k
- ctrl - x ctrl - o, 这个单独拉出来，是使用 Vim 的 Omni Completion 功能来自动完成，因为将要用到的 vim-javacomplete2 就依赖于这个功能
除 YouCompleteMe 插件外，另外还两个 Vim 下的自动完成插件是 NeoComplete 和 VimCompleteMe。
摘要部分算是说完了，现在开始体验 vim-javacomplete2 对 Java 项目的自动完成功能。它所有完成的代码提示不仅要支持基本的 Java 类库, 当前项目的类, 手动添加的 jar 包 ，还能支持maven,gradle和 Eclipse 的.classpath文件中定义的 classpath, 这完全能应付我们实际中的项目了。实际运作也是一个 C/S 结构，这个插件会启动一个 javavi server, 用 javaparser 来解析依赖, 然后 Vim 中用 omnifunc 经 socket 连接到 javavi server 获得提示列表的。 Read More 
今天继续探讨CompletableFuture的特性，它并发时的性能如何呢？我们知道集合的stream()后的操作是序列化进行的，parallelStream()是能够并发执行的，而用CompletableFuture可以更灵活的控制并发。
我们先可以对比一下 parallelStream() 与 CompletableFuture 的性能差异
假设一个这样的耗时 1000 毫秒的计算任务1private static int getJob() { 2 try { 3 Thread.sleep(1000); 4 } catch (InterruptedException e) { 5 } 6 return 50; 7}
分别用下面两个方法来测试，任务数可以通过参数来控制 Read More- 继续对 CompletableFuture 的学习，本然依然不对它的众多方法的介绍，其实也不容易通过一篇述说完所有 CompletableFuture 的操作。此处重点了解下 CompletableFuture 几类操作时所使用的线程，CompletableFuture 的方法重点在它的静态方法以及实现自 CompletionStage 接口的方法，如果是意图异步化编程，反而自我标榜的 Future 中的方法用的少了。
CompletableFuture 根据任务的主从关系为- 提交任务的方法，如静态方法 supplyAsync(supplier[, executor]), runAsync(runnable[, executor])
- 回调函数，即对任务执行后所作出回应的方法，多数方法了，如 thenRun(action), thenRunAsync(action[, executor]), whenComplete(action), whenCompleteAsync(action[, executor]) 等
根据执行方法可分为同步与异步方法，任务都是要被异步执行，所以提交任务的方法都是异步的。而对任务作出回应的方法很多分为两个版本，如- 同步方法，如 thenRun(action), whenComplete(action)
- 异步方法，如 thenRunAsync(action[, executor]), whenCompleteAsync(action[, executor]), 异步方法可以传入线程池，否则用默认的
因此所要理解的 CompletableFuture 的线程会涉及到任务与回调函数所使用的线程。 Read More