都是是人的问题，具有选型决策权的人（研发主管）个人能力 hold 不住新版本
JDK6 这个关键字让我想起一段旧时光，当时公司指定的研发用 JDK 版本号一定是 1.6.0_18 差一位都不行。如果问研发主管一嘴为什么新项目也不切新版，得到的回复总是几句看似基于技术选型思索的诡辩，引入可能带来的风险，还不忘加几句当年前辈们可是也能找出 jdk bug 之类的话来稳定军心。
那阵子，各种充满魔幻现实主义的情节不停地上演：
主管在敦促研发人员如何针对文件分片传输的场景进行优化，讲起了为什么应该在这个场景实现tcp三次握手的机制，下面几个黑盒测试的妹子听得津津有味不明觉厉。
主管经常一边办公室里抽着烟一边大谈特谈“优先级队列”，曰：虽然我这个消息后进入了队列，但是优先级可以最高，这样在另一端可以第一时间出来。
还有一天主管按捺不住手痒，把团队里水平最高的小伙子批判了一通，说你这个代码实现的太慢。然后用一种鸠占鹊巢的姿势一屁股坐在他工位上教他怎样用 JDK BIO 的 API 拷贝文件。敲着敲着发现自己也不会写了，然后当场百度来一段效率最低的实现(while循环一次复制一个byte那种)，反复调试半小时终于得以圆场。
终于，这样的日子迎来高潮。某天主管与新来的架构师两人，就新项目究竟该采用 jdk 1.6.0_18 还是 jdk 1.5 吵得不可开交，激烈舌辩后以主管的压倒性胜利告终。FTP 服务器目录里的 jdk1.6.0_18-linux-x32, jdk1.6.0_18-linux-x64, jdk1.6.0_18-windows-x32, jdk1.6.0_18-windows-x64 四个压缩包在那一刻合四为一，熠熠生辉。
不久后团队迎来离职潮
再后面
只听说主管被另一个空降的大龄女高管一巴拍成普通员工，现在还在基层岗位发光发热
回到问题，遇到坚持使用 JDK6 这个现象本身已经说明公司主流研发的能力欠缺，偏差的技术品位，担心研发能力无法应付当前主流版本带来的新特性。这样的公司往往也没有研发竞争力，靠早年的成熟产品或者其他壁垒，吃老本苟延残喘。
对个人发展来说，这样的公司基本遇不到高水平的前辈，更可能是遇到上文里那样现在实际上不搞技术，别的又没搞好，只能仍然幻想自己在搞技术的主管。跑路为宜。