同不喜欢独显
但是你可以买 13 寸啊

@incompatible 其实为了减少编译环境的复杂性，还可以只保留一个 1.5 的 rt.jar ，然后通过编译参数 -bootclasspath 来指定基础类库，确保编译成完全二进制兼容的代码

ignore 掉？？？怎么可能。妥妥的 NoSuchClassDefFoundError 啊

今年买首选 13 寸，主打便携
主打性能的话还是等明年 15 吧，不厚道的是 intel

看样子商业模式改成广告了吧，其实这样也挺好的，广告更容易赚钱

1. 沟通
2. 至少要搭个 nexus mirror 解决 gfw 的问题，或者直接用国内现成的 mirror

这其实是正则的死穴吧
这种需求非常不适合用正则这种模式匹配的工具来解决
更别说很多正则的实现（如 js ）都不支持 backreference
如果仅仅是 xy 两个字符的话，比较简单的解决办法是
([^xz]|x[^z]|[^x]z)* 来代替，但如果要排除匹配的模式比较长的话就没什么好办法了

-P 不是所有 grep 都支持的吧，比如 macOS 就不支持
用 grep -o '&key=[^&]*' | cut -c5- 就好了

刚去淘宝搜了下理光 gr2 ，现在的正品还需要 4k ，估计 3k 不太可能了

楼上的
是年轻人的第一个 dick （好像哪里拼的不对）么？

养了 8 年的猫离开地球了

@tjf258 买新电脑的话不管带不带把都没法降级

不用
因为常用的外接键盘都没有 F 区
常用的快捷键早就用 Karabiner 映射成右 CMD 的组合了
现在最让我头疼的，是 Karabiner 不兼容 10.12 而不是什么 bar

你首先应该考虑的不是要性能还是要便携么，然后才是钱的问题啊
13 寸和 15 寸比性能是肯定比不过的
要性能因为你的不愿意花钱当然就只能选 15 年 15 了（只不过我觉得卖 2014 换 2015 基本上毫无意义）
要便携的话 13 寸当然爽的多，性能本来就是过剩的

差钱你应该选 13 寸低配， 12 寸适合当你的第二台电脑
当然如果你不打算淘汰你的老 MBP 的话， 12 寸作为第二台电脑还蛮合适的

@mind3x 我测试和你得出来的结论完全不一样
主要是循环次数 1000 造成的不确定性太多了，我把循环次数改为 20000 然后只取后 10000 次的结果平均值作为参考
无论怎么测试，顺序还是乱序的，结果几乎无差别（在 java 下）

但是，如果把累加的代码提取为一个方法，和直接内联进行比较，则差异巨大

测试环境
$ /usr/bin/java -version
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)

代码
class Untitled {
public static void main(String[] args) throws Exception {
long t = 0;
for (int loop = 0; loop < 20000; loop++) {
int[] data = new java.util.Random().ints(0, 256).limit(1024).toArray();
java.util.Arrays.sort(data); // <- 取消这行注释，对比运行结果

long start = System.nanoTime();
int sum = sum(data);
// int sum = 0;
// for (int num : data)
// if (num > 128) sum += num;
long end = System.nanoTime();
if (loop >= 10000) {
t += (end - start);
}
System.err.printf("%d\t%d\t%d%n", loop, end - start, sum);
}
System.err.printf("%.2f%n", t/10000d);
}

static int sum(int[] data) {
int sum = 0;
for (int num : data)
if (num > 128) sum += num;
return sum;
}
}


测试结果
手动内联（也就是你的原始代码），一万次累加的时间平均值是 36xx ~ 38xx 不等
提取方法（让 jvm 去内联），一万次累加的时间平均值是 117x ~ 12xx 的范围

当然我不否认分支预测所可能引起的副作用，但我认为这个在 java 下的影响是比较小不容易区分的

我觉得主要是因为 hostspot 是怎么优化你是无法预估的缘故
建议
1 - （最重要）把 sum 代码单独提取成一个方法
2 - 把循环次数增加到 2000 ，抛弃前 1000 次的执行结果，只统计后 1000 次的执行

你会发现其实结果是很接近的

RTFM

人家文档不是告诉你了吗

autoDownloadFontAwesome: If set to true, force downloads Font Awesome (used for icons). If set to false, prevents downloading. Defaults to undefined, which will intelligently check whether Font Awesome has already been included, then download accordingly.

或许是 ECMA1 兼容的 Reflect.construct 版本
function contract(f, arr)
var x = {}
x.__proto__ = f.prototype
f.apply(x, arr)
return x
}