A*a
2 楼
不知是是分了丈夫的财产，还是被丈夫分了财产
b*p
3 楼
最近的升级是不是马上就要来了啊？多谢！
Y*G
4 楼
诸位道友，reactive编程最近貌似很火啊，先是node.js，后来的vert.x 2.0，最近貌
似netty也很火，不过传统的JavaEE和Spring结合的很好，整个echosystem很成熟，各
种工具，类库也很完善。不知到vert.x和netty是否会取代传统的Web Stack，亦或只是
坛花一现的短命技术，不过我觉得JavaEE也会早晚把这些东西吸收进去的，只是现在时
机未到。JavaEE进化比较慢，那是应为用户群体巨大，一旦改动很难有回头路。
似netty也很火，不过传统的JavaEE和Spring结合的很好，整个echosystem很成熟，各
种工具，类库也很完善。不知到vert.x和netty是否会取代传统的Web Stack，亦或只是
坛花一现的短命技术，不过我觉得JavaEE也会早晚把这些东西吸收进去的，只是现在时
机未到。JavaEE进化比较慢，那是应为用户群体巨大，一旦改动很难有回头路。
t*s
5 楼
没问题。很多人这样。
P*e
6 楼
如果早年没造的话 应该比小白脸有钱
不过婚前有没有财产协议就不知道了
这几年小白脸应该多些
【在 A*****a 的大作中提到】
: 不知是是分了丈夫的财产，还是被丈夫分了财产
不过婚前有没有财产协议就不知道了
这几年小白脸应该多些
【在 A*****a 的大作中提到】
: 不知是是分了丈夫的财产，还是被丈夫分了财产
C*n
7 楼
理论上本月就要有新的。不过这个本现在也是薛定谔状态。
Y*G
8 楼
还有那种可以把模块拆分放在网络上分布式运行，靠消息总线通讯，会不会效率比较低
啊？本来一个本地的调用，延时是指令级别的，现在要走网络栈，差别不是一个数量级
的啊，这种灵活性的代价也太大了吧。
【在 Y**G 的大作中提到】
: 诸位道友，reactive编程最近貌似很火啊，先是node.js，后来的vert.x 2.0，最近貌
: 似netty也很火，不过传统的JavaEE和Spring结合的很好，整个echosystem很成熟，各
: 种工具，类库也很完善。不知到vert.x和netty是否会取代传统的Web Stack，亦或只是
: 坛花一现的短命技术，不过我觉得JavaEE也会早晚把这些东西吸收进去的，只是现在时
: 机未到。JavaEE进化比较慢，那是应为用户群体巨大，一旦改动很难有回头路。
啊？本来一个本地的调用，延时是指令级别的，现在要走网络栈，差别不是一个数量级
的啊，这种灵活性的代价也太大了吧。
【在 Y**G 的大作中提到】
: 诸位道友，reactive编程最近貌似很火啊，先是node.js，后来的vert.x 2.0，最近貌
: 似netty也很火，不过传统的JavaEE和Spring结合的很好，整个echosystem很成熟，各
: 种工具，类库也很完善。不知到vert.x和netty是否会取代传统的Web Stack，亦或只是
: 坛花一现的短命技术，不过我觉得JavaEE也会早晚把这些东西吸收进去的，只是现在时
: 机未到。JavaEE进化比较慢，那是应为用户群体巨大，一旦改动很难有回头路。
N*O
9 楼
哦！！！
谢谢！！！
那个B2要不要改成B1/B2呢？
【在 t**s 的大作中提到】
: 没问题。很多人这样。
谢谢！！！
那个B2要不要改成B1/B2呢？
【在 t**s 的大作中提到】
: 没问题。很多人这样。
S*a
10 楼
她应该从布鲁斯威利斯那儿得了不少
【在 P*******e 的大作中提到】
: 如果早年没造的话 应该比小白脸有钱
: 不过婚前有没有财产协议就不知道了
: 这几年小白脸应该多些
【在 P*******e 的大作中提到】
: 如果早年没造的话 应该比小白脸有钱
: 不过婚前有没有财产协议就不知道了
: 这几年小白脸应该多些
z*e
11 楼
java最好一点就是不会动不动闹革命
把已经解决过的问题再解决一遍
这个绝对不是java整个eco的哲学
所以j2ee, spring, vert.x, netty, groovy, scala这些东西
互相之间有一些交集，但是基本上都不是直接竞争关系
而是互相补充，j2ee是最大的一个集合
但是j2ee并不管很多事情，只负责制定一些high level的标准
netty相比之下则只负责一些底层的api封装
并不负责high level的标准，实际上jee早就已经把vert.x的哲学吸收进去了
undertow就是一个代表，vert.x则侧重于传统jee所不涉及的部分
比如对于其他脚本的兼容性，比如兼容其他网络协议，比如tcp&udp
远不像servlet container那样侧重http
同样j2ee并不怎么搭理persistence的部分，spark, hadoop这些就负责完善这部分
所以问取代不取代，毫无意义，你用vert.x和netty一样可以搞出j2ee来
看你自己怎么做了，问题在于，vert.x和netty并不侧重j2ee那些标准
虽然有重合，实际上vert.x也已经实现了部分j2ee的标准，比如jca
所以这不太可能是昙花一现，因为这些东东开拓了新的领域
而不是把以前做过的东西再做一遍
跟php->node.js这种改变是截然不一样的
把已经解决过的问题再解决一遍
这个绝对不是java整个eco的哲学
所以j2ee, spring, vert.x, netty, groovy, scala这些东西
互相之间有一些交集，但是基本上都不是直接竞争关系
而是互相补充，j2ee是最大的一个集合
但是j2ee并不管很多事情，只负责制定一些high level的标准
netty相比之下则只负责一些底层的api封装
并不负责high level的标准，实际上jee早就已经把vert.x的哲学吸收进去了
undertow就是一个代表，vert.x则侧重于传统jee所不涉及的部分
比如对于其他脚本的兼容性，比如兼容其他网络协议，比如tcp&udp
远不像servlet container那样侧重http
同样j2ee并不怎么搭理persistence的部分，spark, hadoop这些就负责完善这部分
所以问取代不取代，毫无意义，你用vert.x和netty一样可以搞出j2ee来
看你自己怎么做了，问题在于，vert.x和netty并不侧重j2ee那些标准
虽然有重合，实际上vert.x也已经实现了部分j2ee的标准，比如jca
所以这不太可能是昙花一现，因为这些东东开拓了新的领域
而不是把以前做过的东西再做一遍
跟php->node.js这种改变是截然不一样的
s*d
12 楼
没关系，她虎狼之年得到小白脸滋润，已经赚了。
z*e
13 楼
另外标准的制定，一般都比较缓慢
vert.x, spark这些现在做的，就像当年spring做的那样
走在标准的前面，而且标准本身是否有意义
也很值得商榷，因为vert.x现在搞的很多东西
并不是说特别有意义，比如polyglot
如果j2ee要采纳vert.x这种搞法
那就要求所有的ejb container比如websphere,weblogic
全部支持用ruby，js，python，groovy，scala这些写ejb的逻辑代码
我实在看不出来有这个必要
虽然某些app server比如websphere也支持ruby
但是那都是optional，并不是强制要求
如果j2ee什么都管，那就太大了，变得过于笨重了
实际上现在已经很大了，新标准出来，两三年之后都没有几个公司全部impl
以前ibm和bea是最积极的两个，现在都磨磨蹭蹭
vert.x, spark这些现在做的，就像当年spring做的那样
走在标准的前面，而且标准本身是否有意义
也很值得商榷，因为vert.x现在搞的很多东西
并不是说特别有意义，比如polyglot
如果j2ee要采纳vert.x这种搞法
那就要求所有的ejb container比如websphere,weblogic
全部支持用ruby，js，python，groovy，scala这些写ejb的逻辑代码
我实在看不出来有这个必要
虽然某些app server比如websphere也支持ruby
但是那都是optional，并不是强制要求
如果j2ee什么都管，那就太大了，变得过于笨重了
实际上现在已经很大了，新标准出来，两三年之后都没有几个公司全部impl
以前ibm和bea是最积极的两个，现在都磨磨蹭蹭
g*g
14 楼
It will not. 99% of applications are too simple to take advantage of the
async model. But the other 1% apps will.
【在 Y**G 的大作中提到】
: 诸位道友，reactive编程最近貌似很火啊，先是node.js，后来的vert.x 2.0，最近貌
: 似netty也很火，不过传统的JavaEE和Spring结合的很好，整个echosystem很成熟，各
: 种工具，类库也很完善。不知到vert.x和netty是否会取代传统的Web Stack，亦或只是
: 坛花一现的短命技术，不过我觉得JavaEE也会早晚把这些东西吸收进去的，只是现在时
: 机未到。JavaEE进化比较慢，那是应为用户群体巨大，一旦改动很难有回头路。
async model. But the other 1% apps will.
【在 Y**G 的大作中提到】
: 诸位道友，reactive编程最近貌似很火啊，先是node.js，后来的vert.x 2.0，最近貌
: 似netty也很火，不过传统的JavaEE和Spring结合的很好，整个echosystem很成熟，各
: 种工具，类库也很完善。不知到vert.x和netty是否会取代传统的Web Stack，亦或只是
: 坛花一现的短命技术，不过我觉得JavaEE也会早晚把这些东西吸收进去的，只是现在时
: 机未到。JavaEE进化比较慢，那是应为用户群体巨大，一旦改动很难有回头路。
z*e
15 楼
用在listener就非常合适
：It will not. 99% of applications are too simple to take advantage of the
：async model. But the other 1% apps will.
：It will not. 99% of applications are too simple to take advantage of the
：async model. But the other 1% apps will.
c*f
16 楼
netty4的thread model不错
之前很烂
之前很烂
Y*G
17 楼
目前react programming的确不是主流，而且还是以牺牲复杂性为代价的。不知道未来5
年会怎样。
【在 g*****g 的大作中提到】
: It will not. 99% of applications are too simple to take advantage of the
: async model. But the other 1% apps will.
年会怎样。
【在 g*****g 的大作中提到】
: It will not. 99% of applications are too simple to take advantage of the
: async model. But the other 1% apps will.
g*g
18 楼
最火的 1%的互联网公司，用户千万起，异步是很有意义的。可以提高性能，增强鲁棒
性。但其他应用对性能要求没那么高，传统的同步模式足够了，简单容易维护很重要。
未来几年也看不出商业模式会有改变。当然这不是说你不该学这个，互联网业再火十年
毫无问题。
来5
【在 Y**G 的大作中提到】
: 目前react programming的确不是主流，而且还是以牺牲复杂性为代价的。不知道未来5
: 年会怎样。
性。但其他应用对性能要求没那么高，传统的同步模式足够了，简单容易维护很重要。
未来几年也看不出商业模式会有改变。当然这不是说你不该学这个，互联网业再火十年
毫无问题。
来5
【在 Y**G 的大作中提到】
: 目前react programming的确不是主流，而且还是以牺牲复杂性为代价的。不知道未来5
: 年会怎样。
z*e
19 楼
infoq前一段有一个跟tim的访谈
可以看看，里面解释了很多东西，比如跟spring, jee的关系
node, akka etc.
http://www.infoq.com/articles/vertx-3-tim-fox
可以看看，里面解释了很多东西，比如跟spring, jee的关系
node, akka etc.
http://www.infoq.com/articles/vertx-3-tim-fox
相关阅读
有谁可以帮忙写个小小小软件怎样清理不要的C代码算法求教请问如何可以像run SAS， R一样的run python？ (转载)如何写入版本信息贡献一c++面试题C code参数传递出错可能的原因question on Excel VBAmerge two Binary search tree in O(n) time and O(1) space在帮忙看看这个吧 C： int->char*a c++ question.请教：matlab三维图文件太大怎么改小?DJGPP下怎样用pthread.h？如果我有一些.mp3文件，怎样用Java把这些音频文件按照不同时间间隔来合成一个mp3文件？问个nontrivial Java问题Multilanguage Support?容器里边放指针怎么办？请问个老的COMBINATION题问C++文件路径的问题有人用 boost::property_tree 吗?