- 在 Java 中对于下面最简单的泛型类
class A<T> {
设想我们使用时
public void foo() {
//如何在此处获得运行时 T 的具体类型呢？
}
}new A<String>().foo();
是否能在foo()方法中获得当前的类型是 String 呢？答案是否定的，不能。在foo()方法中 this 引用给不出类型信息，this.getClass()就更不可能了，因为 Java 的泛型不等同于 C++ 的模板类，this.getClass()实例例是被所有的不同具体类型的 A 实例(new A<String>(), new A<Integer>() 等) 共享的，所以在字节码中类型会被擦除到上限。
我们可以在 IDE 的调试时看到这个泛型类的签名
Read More 
在上一篇中尝试了 使用 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 - Java 1.5 有了 Future, 可谓是跨了一大步，继而 Java 1.8 新加入一个 Future 的实现 CompletableFuture, 从此线程与线程之间可以愉快的对话了。最初两个线程间的协调我采用过 Object 的
wait()和notify(), Thread 的join()方法，那可算是很低级的 API 了，是否很多 Java 程序都不知道它们的存在，或根本没用过它们。
如果是简单的等待所有线程完成可使用 Java 1.5 的 CountDownLatch, 这里有一篇介绍 CountDownLatch 协调线程, 就是实现的 waitAll(threads) 功能。而 Java 8 的CompletableFuture的功能就多去，可简单使用它实现异步方法。虽说CompletableFuture实现了Future接口，但它多数方法源自于CompletionStage, 所以还里氏代换，用Future来引用CompletableFuture实例就很牵强了; 这也是为什么 PlayFramework 自 2.5 开始直接暴露的类型是CompletionStage而非其他两个。
顾名思义，CompletableFuture 代表着一个 Future 完成后该干点什么，具体大致有：- Future 完成后执行动作，或求取下一个 Future 的值。then...
- 多个 Future 的协调; 同时完成该怎么，其中一个完成该如何。allOf, anyOf
有时候可以把 Future 想像成与线程是一一对应的。 Read More - 在前一篇 Scala 的参数检查与断言: require, assert, assume 和 ensuring，捉摸 Scala 的断言时提到了 JDK 内置对断言的粗略支持，也就是
assert语句，并且默认该特性是被关掉，需-ea开启。assert object != null;
还进一步接触了 Scala 的
assert object != null : "object can't be null";Predef方法require,assert,assume, 和ensuring是怎么检验参数与断言运算结果的，Scala 的这些方法在校验失败时相应的抛出IllegalArgumentException和AssertionError异常。
JDK 7 引入了 Objects 工具类，它的三个T requireNotNull(T object)方法能对参数进行 null 值检查，null 时抛出NullPointerException
Read More
