你可能觉得我不去社区发这些东西很奇怪，但是我不会在精力不充分的时候拿这些东西去接受群众的批判，我需要时间调整到自己认为的良好状态，而不是进行各种形式化的措辞。
还有一个最近在思考的问题，在缺少上下文的时候如何提高工作效率？这方面我原本是擅长的，但高中竞赛高压环境下练成的反应速度已经随着神经衰弱的加重失去了，早就没有了自恃无恐的资本。接下来，一方面持续归纳总结历史经验，一方面持续关注新兴技术。想在刚性环境下练出竞争力，不得不练出点过人之处，足以接受升职考核和街头卖艺的双重考验。
Guava并不是一个应用级框架。相反，它工作在和jdk以及jcommon差不多的层次上。但在这个层次上，它表现出Google人强悍的素质：简洁、高效、无懈可击。完备到无可挑剔的文档，高瞻远瞩的集合工厂和函数式接口，与jdk的无缝连接。我被它折服了，这是最适应java程序员需求的工具，只存在于理想中的工具。
先开个头，老大让学另一本书，自己这一摊先放一放。

就函数式风格来说吧，Function和Predicate，都和java8里的一模一样，一个字都不带差的。当然这一点都不奇怪，它们甚至很可能是一个人写的。尽管java8从语法层面上根除了guava函数接口代码偏啰嗦的问题，guava仍然在试水阶段发挥过关键作用。
我之前在实习单位接触过Erlang语言，那是个纯函数式语言，没有if没有for，刚学的时候简直要吐血。用当时头的比喻形容就是，命令式相对于函数式就是“被重力束缚了”。还是挺形象的，人一失重，虽然自由了，但也容易抓瞎，容易蒙圈。尤其java的函数接口刚刚起步，这个时期最容易被滥用，产生海量舍近求远、华而不实的代码。
guava在自己的类库中也大量使用了函数接口，可以用它们对集合进行过滤和转化之类的操作。尽管从今天看和lambda表达式一比它们已经逊色很多了，但在当时可以说是质变，并且就算是现在，1.8的普及程度远不及1.6，我在公司项目中也看到guava普遍存在（虽然没多少人用）。这些能确实提高工作效率的东西，为了可持续发现，短期内就算干活别扭点也得去适应，跨过学习门槛就够吃几年老本的，怎么也值了。

尝试使用了guava提供的参数化类型反射工具，发现一个多年前的疑问仍然不能解决：无法在运行时获得泛型类或泛型方法中参数化类型的class对象。既然Google都做不到，我只能猜测这个事可能根本实现不了。泛型的类型擦除导致在运行期分析中只能获取到参数化类型声明的字面值（就是T,E,K,V，没什么卵用）。
然后发现csdn上也有很多人提这方面的问题。我们这帮人迟早要跨越这一阶段，而这种问题只靠堆砌项目经验恐怕永无解决之日。还是得多动脑子，正确认识手头的工具，最后将其化为己用。
就拿guava来说吧，如果把它的集合工厂方法干掉让我写一份一样的，凭我现在的水平可能连一半都写不出来。直到自己能遵照其方法论将各方面细节落实之前，我还不能算学会了这个框架。

下周一在组内分享的空指针规范方案，主要采用Guava的Optional类

nice