s***o
发帖数: 2191 | |
s***o
发帖数: 2191 | |
p*****2
发帖数: 21240 | |
g*****g
发帖数: 34805 | 4 grails也罢了，gradle这么火，groovy肯定有人接的。 |
s***o
发帖数: 2191 | 5 敢骂groovy，来打击你一下：
JDK9's modularization effort sends Scala into dismay
https://issues.scala-lang.org/browse/SI-9103
You can't run Scala on JDK9
【在 p*****2 的大作中提到】
: groovy就是个joke
|
l**********n
发帖数: 8443 | 6 how about jruby?
【在 p*****2 的大作中提到】
: groovy就是个joke
|
d****i
发帖数: 4809 | 7 哈哈，我的偶像公司终于对屎卡拉动手了，“谁让你来榜我来着，一边凉快去”。
【在 s***o 的大作中提到】
: 敢骂groovy，来打击你一下：
: JDK9's modularization effort sends Scala into dismay
: https://issues.scala-lang.org/browse/SI-9103
: You can't run Scala on JDK9
|
d****i
发帖数: 4809 | |
c******o
发帖数: 1277 | 9 没用的，scala本质上是一个大的java library.
除了legal, 技术上没啥可以阻止scala在jvm上的
【在 s***o 的大作中提到】
: 敢骂groovy，来打击你一下：
: JDK9's modularization effort sends Scala into dismay
: https://issues.scala-lang.org/browse/SI-9103
: You can't run Scala on JDK9
|
w***g
发帖数: 5958 | 10 牛！有人知道sponsor grail和groovy一年要多少钱吗？估计一下也行。
【在 s***o 的大作中提到】
: 敢骂groovy，来打击你一下：
: JDK9's modularization effort sends Scala into dismay
: https://issues.scala-lang.org/browse/SI-9103
: You can't run Scala on JDK9
|
|
|
g*****g
发帖数: 34805 | 11 估计20个人的团队，1000万左右。
【在 w***g 的大作中提到】
: 牛！有人知道sponsor grail和groovy一年要多少钱吗？估计一下也行。
|
l**********n
发帖数: 8443 | 12 groovy应该没戏。除了gradle,就没啥价值了
【在 g*****g 的大作中提到】
: 估计20个人的团队，1000万左右。
|
b***e
发帖数: 1419 | |
W***o
发帖数: 6519 | |
d****i
发帖数: 4809 | 15 其实说白了就是，web框架前端没得说只有JavaScript，后端基本上就是PHP, Python,
Perl, NodeJS, Ruby来几分天下，JVM的话有点嫌重多余，ASP.NET又逐渐被人唾弃，所
以grail死了也正常，真要JVM的话还是老老实实的JSP的那一套吧。 |
e*******o
发帖数: 4654 | 16 为啥要那么多？ 20个人全部全职？
Perl 10万就是顶级sponsor了。
【在 g*****g 的大作中提到】
: 估计20个人的团队，1000万左右。
|
g*****g
发帖数: 34805 | 17 说的就是维护一个项目全速开发，如果没钱了小打小闹修几个bug，没钱也问题不大。
【在 e*******o 的大作中提到】
: 为啥要那么多？ 20个人全部全职？
: Perl 10万就是顶级sponsor了。
|
g*****g
发帖数: 34805 | 18 Gradle已经too big to fail了。
【在 l**********n 的大作中提到】
: groovy应该没戏。除了gradle,就没啥价值了
|
j********x
发帖数: 2330 | 19 糙快猛说的是
东西糙
搞得快
方法猛
跟那个东西没有关系
【在 b***e 的大作中提到】
: 我一早就说，Grails就是一坨。糙是够糙了，一点也不快，一点也不猛。到处是漏洞。
: 连个像样的ORM也没有。早死早超生。
|
s***o
发帖数: 2191 | |
|
|
s***o
发帖数: 2191 | 21 下个月敢不敢砍掉spring，不挣钱的统统干掉 |
p*****2
发帖数: 21240 | |
g*****g
发帖数: 34805 | 23 grails也罢了，gradle这么火，groovy肯定有人接的。 |
s***o
发帖数: 2191 | 24 敢骂groovy，来打击你一下：
JDK9's modularization effort sends Scala into dismay
https://issues.scala-lang.org/browse/SI-9103
You can't run Scala on JDK9
【在 p*****2 的大作中提到】
: groovy就是个joke
|
l**********n
发帖数: 8443 | 25 how about jruby?
【在 p*****2 的大作中提到】
: groovy就是个joke
|
d****i
发帖数: 4809 | 26 哈哈，我的偶像公司终于对屎卡拉动手了，“谁让你来榜我来着，一边凉快去”。
【在 s***o 的大作中提到】
: 敢骂groovy，来打击你一下：
: JDK9's modularization effort sends Scala into dismay
: https://issues.scala-lang.org/browse/SI-9103
: You can't run Scala on JDK9
|
d****i
发帖数: 4809 | |
c******o
发帖数: 1277 | 28 没用的，scala本质上是一个大的java library.
除了legal, 技术上没啥可以阻止scala在jvm上的
【在 s***o 的大作中提到】
: 敢骂groovy，来打击你一下：
: JDK9's modularization effort sends Scala into dismay
: https://issues.scala-lang.org/browse/SI-9103
: You can't run Scala on JDK9
|
w***g
发帖数: 5958 | 29 牛！有人知道sponsor grail和groovy一年要多少钱吗？估计一下也行。
【在 s***o 的大作中提到】
: 敢骂groovy，来打击你一下：
: JDK9's modularization effort sends Scala into dismay
: https://issues.scala-lang.org/browse/SI-9103
: You can't run Scala on JDK9
|
g*****g
发帖数: 34805 | 30 估计20个人的团队，1000万左右。
【在 w***g 的大作中提到】
: 牛！有人知道sponsor grail和groovy一年要多少钱吗？估计一下也行。
|
|
|
l**********n
发帖数: 8443 | 31 groovy应该没戏。除了gradle,就没啥价值了
【在 g*****g 的大作中提到】
: 估计20个人的团队，1000万左右。
|
b***e
发帖数: 1419 | |
W***o
发帖数: 6519 | |
d****i
发帖数: 4809 | 34 其实说白了就是，web框架前端没得说只有JavaScript，后端基本上就是PHP, Python,
Perl, NodeJS, Ruby来几分天下，JVM的话有点嫌重多余，ASP.NET又逐渐被人唾弃，所
以grail死了也正常，真要JVM的话还是老老实实的JSP的那一套吧。 |
e*******o
发帖数: 4654 | 35 为啥要那么多？ 20个人全部全职？
Perl 10万就是顶级sponsor了。
【在 g*****g 的大作中提到】
: 估计20个人的团队，1000万左右。
|
g*****g
发帖数: 34805 | 36 说的就是维护一个项目全速开发，如果没钱了小打小闹修几个bug，没钱也问题不大。
【在 e*******o 的大作中提到】
: 为啥要那么多？ 20个人全部全职？
: Perl 10万就是顶级sponsor了。
|
g*****g
发帖数: 34805 | 37 Gradle已经too big to fail了。
【在 l**********n 的大作中提到】
: groovy应该没戏。除了gradle,就没啥价值了
|
j********x
发帖数: 2330 | 38 糙快猛说的是
东西糙
搞得快
方法猛
跟那个东西没有关系
【在 b***e 的大作中提到】
: 我一早就说，Grails就是一坨。糙是够糙了，一点也不快，一点也不猛。到处是漏洞。
: 连个像样的ORM也没有。早死早超生。
|
d*******r
发帖数: 3299 | 39 Grails 和 Groovy 现在如何了, 挖个坟
JVM 成熟点的 web framework 只有 Spring 和 Play? |
z*******3
发帖数: 13709 | 40
grails不知道
但是我知道palantir和netflix都在大规模应用groovy
另外scala的很多framework并不成熟，play 1->2有很大区别
【在 d*******r 的大作中提到】
: Grails 和 Groovy 现在如何了, 挖个坟
: JVM 成熟点的 web framework 只有 Spring 和 Play?
|
|
|
d*******r
发帖数: 3299 | 41 我在帮搞Java的找一个比较成熟的 web framework, 你有啥建议
比如有如下目的
倾向1: 主要做 full stack, 前后一起做
倾向2: 主要做 RESTful API over traditional SQL database
【在 z*******3 的大作中提到】
:
: grails不知道
: 但是我知道palantir和netflix都在大规模应用groovy
: 另外scala的很多framework并不成熟，play 1->2有很大区别
|
p*****2
发帖数: 21240 | 42 干嘛用java？
现在也就dw play vx吧
【在 d*******r 的大作中提到】
: 我在帮搞Java的找一个比较成熟的 web framework, 你有啥建议
: 比如有如下目的
: 倾向1: 主要做 full stack, 前后一起做
: 倾向2: 主要做 RESTful API over traditional SQL database
|
z*******3
发帖数: 13709 | 43
restful多半是http
jaxrs，jaxws，用tomcat就可以host，然后jdbc
这种做法网络上各种傻瓜教程比较多
各种ide可以做到比较强力支援，不用async的话可以做到异常傻瓜化
如果用async的话，可以用undertow
如果是我自己做，肯定用vert.x
用JDBC client和web
语言groovy, java, js, ruby随便选一个
主要是vert.x的web，ide等傻瓜工具比较少
【在 d*******r 的大作中提到】
: 我在帮搞Java的找一个比较成熟的 web framework, 你有啥建议
: 比如有如下目的
: 倾向1: 主要做 full stack, 前后一起做
: 倾向2: 主要做 RESTful API over traditional SQL database
|
d*******r
发帖数: 3299 | 44 帮别人问, 我自己做, 肯定用 Node or Python3
【在 p*****2 的大作中提到】
: 干嘛用java？
: 现在也就dw play vx吧
|
x***4
发帖数: 1815 | 45 play 和slick (scala的sql orm)改来改去。庆幸一开始做了明智的决定没采用。
【在 z*******3 的大作中提到】
:
: restful多半是http
: jaxrs，jaxws，用tomcat就可以host，然后jdbc
: 这种做法网络上各种傻瓜教程比较多
: 各种ide可以做到比较强力支援，不用async的话可以做到异常傻瓜化
: 如果用async的话，可以用undertow
: 如果是我自己做，肯定用vert.x
: 用JDBC client和web
: 语言groovy, java, js, ruby随便选一个
: 主要是vert.x的web，ide等傻瓜工具比较少
|
d*******r
发帖数: 3299 | 46 就知道你会推 vert.x
vert.x 对于老 Java 用户搞着顺手吗... 我看都是在用异步
还有, vert.x + ORM_over_SQL 这种有成熟方案吗
用 tomcat 那些, Spring还是要研究吧?
【在 z*******3 的大作中提到】
:
: restful多半是http
: jaxrs，jaxws，用tomcat就可以host，然后jdbc
: 这种做法网络上各种傻瓜教程比较多
: 各种ide可以做到比较强力支援，不用async的话可以做到异常傻瓜化
: 如果用async的话，可以用undertow
: 如果是我自己做，肯定用vert.x
: 用JDBC client和web
: 语言groovy, java, js, ruby随便选一个
: 主要是vert.x的web，ide等傻瓜工具比较少
|
z*******3
发帖数: 13709 | 47
node什么也都改来改去
倒是传统的servlet老当益壮
除了undertow以外，其他都不如serlvet
http://www.techempower.com/benchmarks/#section=data-r10&hw=ec2&
【在 x***4 的大作中提到】
: play 和slick (scala的sql orm)改来改去。庆幸一开始做了明智的决定没采用。
|
z*******3
发帖数: 13709 | 48
顺手啊，就是vert.x没有那么傻瓜罢了
用tomcat你什么都不懂，一样能写web
vert.x要求略高，对于网络协议，数据库还有多线程这些
底层一点，看你要什么了
比如orm over sql这个纯粹看hibernate的熟悉程度
你会hibernate，只要有sql你就能搞出来
这个跟web无关
【在 d*******r 的大作中提到】
: 就知道你会推 vert.x
: vert.x 对于老 Java 用户搞着顺手吗... 我看都是在用异步
: 还有, vert.x + ORM_over_SQL 这种有成熟方案吗
: 用 tomcat 那些, Spring还是要研究吧?
|
d*******r
发帖数: 3299 | 49 怎么没见你提 Spring framework 呢
用 tomcat, hibernate 那些, Spring还是要研究不?
【在 z*******3 的大作中提到】
:
: 顺手啊，就是vert.x没有那么傻瓜罢了
: 用tomcat你什么都不懂，一样能写web
: vert.x要求略高，对于网络协议，数据库还有多线程这些
: 底层一点，看你要什么了
: 比如orm over sql这个纯粹看hibernate的熟悉程度
: 你会hibernate，只要有sql你就能搞出来
: 这个跟web无关
|
z*******3
发帖数: 13709 | 50
tomcat，jaxrs可以不用spring
tomcat自己有connection pool
可以部分优化效率
spring是用来优化多线程效率的
然后orm是用来简化开发效率的
undertow是用来优化servlet效率的
这些都是optional，你什么都不用其实也无所谓
可以的，什么都不用就跟php差不多了
而且你学会用spring什么也不难
就五分钟，spring mvc麻烦点，但是我觉得也没啥难的
用ide的plugin
【在 d*******r 的大作中提到】
: 就知道你会推 vert.x
: vert.x 对于老 Java 用户搞着顺手吗... 我看都是在用异步
: 还有, vert.x + ORM_over_SQL 这种有成熟方案吗
: 用 tomcat 那些, Spring还是要研究吧?
|
|
|
z*******3
发帖数: 13709 | 51
spring本质只是一个多线程优化效率以及简化开发的一个framework
可以不用啊，vert.x当时community就在讨论要不要做ioc
其他语言开发者反对，因为其他语言做不到ioc
对于大多数写脚本的web developers来说，他们不懂这些
还不是一样survive下来，你可以不用，效率就跟php之类的差不多了
看你那个项目的大小，如果项目大到一定程度，开发人员素质要跟上
如果只是拖控件，搞点crud，那我觉得这么高级的东西不懂也无所
能把东西做出来交差是王道，tomcat一个web server可以做很多东西
包括connection pool都有
【在 d*******r 的大作中提到】
: 怎么没见你提 Spring framework 呢
: 用 tomcat, hibernate 那些, Spring还是要研究不?
|
d*******r
发帖数: 3299 | 52 那简单说的话, Spring 主要提供的什么功能
【在 z*******3 的大作中提到】
:
: spring本质只是一个多线程优化效率以及简化开发的一个framework
: 可以不用啊，vert.x当时community就在讨论要不要做ioc
: 其他语言开发者反对，因为其他语言做不到ioc
: 对于大多数写脚本的web developers来说，他们不懂这些
: 还不是一样survive下来，你可以不用，效率就跟php之类的差不多了
: 看你那个项目的大小，如果项目大到一定程度，开发人员素质要跟上
: 如果只是拖控件，搞点crud，那我觉得这么高级的东西不懂也无所
: 能把东西做出来交差是王道，tomcat一个web server可以做很多东西
: 包括connection pool都有
|
z*******3
发帖数: 13709 | 53
要有选择地使用
如果是古德霸这种老鸟，肯定上来就要求用spring这些
如果只是菜瓜，表搞那么复杂，先从crud，hello world开始
orm自己写也不难，高级一点用hibernate咯
这些东西都不是mutually exclusive的
都是optional的，可用可不用，java这点好，选择很多
【在 d*******r 的大作中提到】
: 怎么没见你提 Spring framework 呢
: 用 tomcat, hibernate 那些, Spring还是要研究不?
|
z*******3
发帖数: 13709 | 54
ioc和di
可以很容易滴decoupling
不容易造成memory leak
其次可以复用component beans
不需要大量生成beans，就可以复用或者说是共用objects
好处是多方面的，搞起来也很容易啊
就五分钟就可以搞定了，我当年就用了五分钟搞掂
一直都不理解为什么有人说spring难
【在 d*******r 的大作中提到】
: 那简单说的话, Spring 主要提供的什么功能
|
d*******r
发帖数: 3299 | 55 非常感谢!! 省了我这个 Java 菜鸟很多的研究时间
【在 z*******3 的大作中提到】
:
: ioc和di
: 可以很容易滴decoupling
: 不容易造成memory leak
: 其次可以复用component beans
: 不需要大量生成beans，就可以复用或者说是共用objects
: 好处是多方面的，搞起来也很容易啊
: 就五分钟就可以搞定了，我当年就用了五分钟搞掂
: 一直都不理解为什么有人说spring难
|
d*******r
发帖数: 3299 | 56 那其实就是想在 static typed Java 里做出有点动态的那种依赖关系和组合关系吧,
我扫了眼 Spring 教程, 就一直在 beans, beans ...
动态脚本(Python, Node, PHP, Ruby)貌似这个功能确实不是必须的
【在 z*******3 的大作中提到】
:
: ioc和di
: 可以很容易滴decoupling
: 不容易造成memory leak
: 其次可以复用component beans
: 不需要大量生成beans，就可以复用或者说是共用objects
: 好处是多方面的，搞起来也很容易啊
: 就五分钟就可以搞定了，我当年就用了五分钟搞掂
: 一直都不理解为什么有人说spring难
|
z*******3
发帖数: 13709 | 57
beans就是components
就是一个简化的npm
java最低级的单位就是bean
就是一个java文件
你想弄动态，看reflection
spring什么大量用了reflection
反射就只要知道名字就可以随便操弄beans了
【在 d*******r 的大作中提到】
: 那其实就是想在 static typed Java 里做出有点动态的那种依赖关系和组合关系吧,
: 我扫了眼 Spring 教程, 就一直在 beans, beans ...
: 动态脚本(Python, Node, PHP, Ruby)貌似这个功能确实不是必须的
|
d*******r
发帖数: 3299 | 58 我看 beans 是自带 serialize 的一种 class 吧
http://stackoverflow.com/questions/3295496/what-is-a-javabean-e
npm 你指 node npm?
再问个傻问题, beans 的标准是啥时候定下来的
【在 z*******3 的大作中提到】
:
: beans就是components
: 就是一个简化的npm
: java最低级的单位就是bean
: 就是一个java文件
: 你想弄动态，看reflection
: spring什么大量用了reflection
: 反射就只要知道名字就可以随便操弄beans了
|
z*******3
发帖数: 13709 | 59
spring的大多数策略应该是所有多线程都需要的吧？
其他语言尤其是脚本，做不到di和ioc很重要一点是当插入的时候
需要有一个宿主，which绝大多数时候是对象
@Inject
MyObject myObject
你得先得到这个myObject才能调用方法
其他脚本经常会搞1st class citizen func
这个没有宿主啊，所以就不存在有inject的问题
你要用func，反正作用域是global的，直接用就是了
就类似static method，但是jvm的static区内存应该尽量省着用
一下子把所有func全部塞入这块中去，好像也不是非常合理
尤其是很多不用的funcs，spring就帮你搞这块的东东了
用的时候，spring会init这个func所属的beans，然后存起来
不用的时候释放，等等，这块属于spring framework高级技能了
有兴趣可以展开，这就是轮子怎么造的问题了
ejb提供了更多的选择，比如ejb di就提供了类似spring的功能
等等
【在 d*******r 的大作中提到】
: 那其实就是想在 static typed Java 里做出有点动态的那种依赖关系和组合关系吧,
: 我扫了眼 Spring 教程, 就一直在 beans, beans ...
: 动态脚本(Python, Node, PHP, Ruby)貌似这个功能确实不是必须的
|
z*******3
发帖数: 13709 | 60
beans没有标准，所有的java文件都是beans
只不过换个名字而已，所以spring说pojo
plain ordinary java object
意思就是你不需要遵循标准，没有标准，没有接口没有抽象类需要你去impl
随便拿一个java文件，这就是bean
spring通过xml和annotation来管理这些bean
所以你原来java怎么写，以后还怎么写，只需要在xml和annotation上告诉spring就好了
所以spring是一种非侵入式的框架，不像ejb早期，需要你impl接口或者抽象类
这个侵入就比较强
serialisable是一个interface，marker interface啊
如果你不垮虚拟机调用的话，你不需要impl这个
如果你垮虚拟机调用bean的话，才需要额外把这个接口写上去
做个标注，这样虚拟机就知道你需要序列化这个bean
【在 d*******r 的大作中提到】
: 我看 beans 是自带 serialize 的一种 class 吧
: http://stackoverflow.com/questions/3295496/what-is-a-javabean-e
: npm 你指 node npm?
: 再问个傻问题, beans 的标准是啥时候定下来的
|
|
|
d*******r
发帖数: 3299 | 61 像 Node.js 这种动态的语言, 把一个 Object (JSON) 里的 field 换成啥,
都是随便换, 随便插的, 当然错误校验也差一些.
【在 z*******3 的大作中提到】
:
: beans没有标准，所有的java文件都是beans
: 只不过换个名字而已，所以spring说pojo
: plain ordinary java object
: 意思就是你不需要遵循标准，没有标准，没有接口没有抽象类需要你去impl
: 随便拿一个java文件，这就是bean
: spring通过xml和annotation来管理这些bean
: 所以你原来java怎么写，以后还怎么写，只需要在xml和annotation上告诉spring就好了
: 所以spring是一种非侵入式的框架，不像ejb早期，需要你impl接口或者抽象类
: 这个侵入就比较强
|
z*******3
发帖数: 13709 | 62
对啊，java你用反射就随便插随便改，就容易错
强校验的话，就全部转换成object，这个校验就强
用jackson可以实现自由转换json和object,map,list这些
【在 d*******r 的大作中提到】
: 像 Node.js 这种动态的语言, 把一个 Object (JSON) 里的 field 换成啥,
: 都是随便换, 随便插的, 当然错误校验也差一些.
|
z*******3
发帖数: 13709 | 63
不过你可能需要把func和entity分离
spring主要节省的是funcs所属的objects
entity那种需要考虑多个threads之间的争抢
这个最好的方式就是每一个thread自己去用自己的entity
想起韩复渠的笑话，这么多人抢一个球，太不像话
我做主，打开仓库，你们每个人玩一个球
这个球就是entity，只要做到隔离，每个人有自己的球
基本上scale out都不难做，但是互相之间要抢球
那就麻烦了，做游戏就特别容易抢球
【在 d*******r 的大作中提到】
: 像 Node.js 这种动态的语言, 把一个 Object (JSON) 里的 field 换成啥,
: 都是随便换, 随便插的, 当然错误校验也差一些.
|
d*******r
发帖数: 3299 | 64 "spring通过xml和annotation来管理这些bean"
有意思, 那 Spring annotation 相当于自己搞了一套 class/object/whatever 的数据
结构抽象了. 那简单说, 它跟一般 class 定义比,主要多了那些重要功能
好了
【在 z*******3 的大作中提到】
:
: 不过你可能需要把func和entity分离
: spring主要节省的是funcs所属的objects
: entity那种需要考虑多个threads之间的争抢
: 这个最好的方式就是每一个thread自己去用自己的entity
: 想起韩复渠的笑话，这么多人抢一个球，太不像话
: 我做主，打开仓库，你们每个人玩一个球
: 这个球就是entity，只要做到隔离，每个人有自己的球
: 基本上scale out都不难做，但是互相之间要抢球
: 那就麻烦了，做游戏就特别容易抢球
|
z*******3
发帖数: 13709 | 65
可以这么说，毕竟是framework，还是有东西要你遵守的
不过这个部分跟你语言的部分分离
不侵入你语言的实现，这样你就可以复用很多代码了
因为同样的java代码，你放在哪里，都不需要修改
你的spring跟我的spring用的java文件是一样的
这样你至少在测试的时候就很方便，没有context要折腾
这个方法过了那就是过了，不存在说有context的问题
spring的xml很傻瓜
就是beans.xml
那个xml文件里面就这些东西，你看一下就懂了
spring是一个组件的pool
tomcat是一个thread的pool
这个thread主要用来管理网络上发送过来的req
然后tomcat会从thread pool里面抓出一个thread去处理这个req
然后你写的主要是组件，不管是servlet，还是spring这些
你写的都是component，不涉及thread这些，就放到server里面去被调用
对吧？传统的做法，都是servlet like的方式
就是你在servlet里面实现逻辑，如果你在servlet里面要用其他文件里面的方法
就需要去先实例化其他文件（就是bean）里面的class，然后调用方法
这就很麻烦，因为你的servlet跟其他class文件捆绑在一起了
耦合就强了嘛，尤其是当其他的class文件改动了之后
会影响到你这个servlet，整个需要重新编译
那spring做到的就是，你不需要去直接调用其他bean
什么时候inject进来，spring负责，你只需要assume这个对象存在就可以了
spring会负责剩下的，所以这个时候你只需要有一个interface
然后调用interface的方法便可，那如果将来，interface的implement class改变了
你这个servlet就不需要重新编译了，就灵活很多
就可以做到decoupling，beans的书写和servlet的书写分离
你写你的，你编译你的，我写我的，我编译我的，就不会凑到一块去，互相干扰
这么说太抽象，我们举个例子
比如Bean的interface是GoodBug，实现类是GoodBugImplementation
没有spring的时候，servlet是
GoodBug goodbug = new GoodBugImplementation;
代码中
goodbug.func(...);
...
如果将来GoodBugImplementation改变了，你这个servlet也得跟着重新编译才能通过
而用了spring之后
@Inject
GoodBug goodbug;
代码中
goodbug.func(...);
...
或者在xml里面增加
//大概是这个意思，具体语法到时候自己查，好久没用xml了，可能有些语法有错
这时候servlet中就不存在有GoodBugImplementation类了
将来GoodBugImplementation如果改变了，你这部分代码不需要重新编译
【在 d*******r 的大作中提到】
: "spring通过xml和annotation来管理这些bean"
: 有意思, 那 Spring annotation 相当于自己搞了一套 class/object/whatever 的数据
: 结构抽象了. 那简单说, 它跟一般 class 定义比,主要多了那些重要功能
:
: 好了
|
z*******3
发帖数: 13709 | 66 这种不加任何限制的java文件就是pojo
而大多数framework, server都会添加某些限制
比如ejb,早期就需要impl很多接口，还不只一个，四五个
vert.x目前做到的也需要你impl AbstractVerticle这个抽象类
servlet也需要impl一个抽象类
否则beans就不是verticle，不是servlet
但是spring只需要在xml中标记一下，就可以了
这样你源代码基本上不动
测试时候就很方便，没有context，你不需要去设置什么东西就可以开始测试了
测试ejb烦死，需要app server，测试servlet也需要有tomcat之类的
test case通过之后，你就可以直接放入spring中去
改一下配置xml文件就好了，就不需要重新编译 |
d*******r
发帖数: 3299 | 67 大体上懂了, 你这些回帖省了我 N 多研究时间, 太感谢了!!
【在 z*******3 的大作中提到】
: 这种不加任何限制的java文件就是pojo
: 而大多数framework, server都会添加某些限制
: 比如ejb,早期就需要impl很多接口，还不只一个，四五个
: vert.x目前做到的也需要你impl AbstractVerticle这个抽象类
: servlet也需要impl一个抽象类
: 否则beans就不是verticle，不是servlet
: 但是spring只需要在xml中标记一下，就可以了
: 这样你源代码基本上不动
: 测试时候就很方便，没有context，你不需要去设置什么东西就可以开始测试了
: 测试ejb烦死，需要app server，测试servlet也需要有tomcat之类的
|
z*******3
发帖数: 13709 | 68 组件pool最大的好处就在于复用这部分代码
spring通过给不同thread提供可以被分享的func来减少内存的使用
这部分说起来挺麻烦，跟fp的immutable有点类似
简单说就是spring也主张要无副作用的func
不要在func外寄存状态，只有ejb和vert.x可以在func外寄存状态
vert.x也只有worker和普通的verticle可以寄存
新增加的multiple thread shared verticle就跟spring很像了
都不允许寄存状态，如果不寄存状态的话，每个func所属的object
只需要实例化一次就可以了，ejb就会实例化一堆，然后pool起来
spring对于一般的bean只实例化一个，并不断复用这一个
spring也提供那种可以寄存状态的，需要设置bean为prototype
这样每次调用都会重新生成一个object，只是不推荐你这么搞 |
d*******r
发帖数: 3299 | 69 老赵你应该搞个 Java tech blog, 把很多东西梳理下,
放上去, 造福我们这些 Java 菜鸟 :D
Spring -> Vert.x 串起来讲, 东西还是不少的.
记得二爷搞过一个算法blog, 好像他那会儿在刷题
这个有点像 Actor 了?
【在 z*******3 的大作中提到】
: 组件pool最大的好处就在于复用这部分代码
: spring通过给不同thread提供可以被分享的func来减少内存的使用
: 这部分说起来挺麻烦，跟fp的immutable有点类似
: 简单说就是spring也主张要无副作用的func
: 不要在func外寄存状态，只有ejb和vert.x可以在func外寄存状态
: vert.x也只有worker和普通的verticle可以寄存
: 新增加的multiple thread shared verticle就跟spring很像了
: 都不允许寄存状态，如果不寄存状态的话，每个func所属的object
: 只需要实例化一次就可以了，ejb就会实例化一堆，然后pool起来
: spring对于一般的bean只实例化一个，并不断复用这一个
|
z*******3
发帖数: 13709 | 70
就是actor，vert.x里面的verticle就是actor
所以vert.x到处抄，抄完了node抄akka，抄完了akka抄spring
我就喜欢这种会抄的家伙
【在 d*******r 的大作中提到】
: 老赵你应该搞个 Java tech blog, 把很多东西梳理下,
: 放上去, 造福我们这些 Java 菜鸟 :D
: Spring -> Vert.x 串起来讲, 东西还是不少的.
: 记得二爷搞过一个算法blog, 好像他那会儿在刷题
:
: 这个有点像 Actor 了?
|
|
|
d*******r
发帖数: 3299 | 71 http://www.quora.com/Is-developing-in-Groovy-Grails-faster-than
"Keep in mind Grails under the hood is SPRING and HIBERNATE."
整半天, Grails 是在 Spring 上载套一层, 然后来模仿 Rails 这种东西的呀.
感觉好难受, 巨多层的抽象... -_- |
g*****g
发帖数: 34805 | 72 Grail就是spring mvc + hibernate用Groovy写。spring mvc没有什么问题，纯粹是用
java verbose而已。ROR比Spring MVC晚。web前端JVM可以做，但是前景不如NodeJs。
【在 d*******r 的大作中提到】
: http://www.quora.com/Is-developing-in-Groovy-Grails-faster-than
: "Keep in mind Grails under the hood is SPRING and HIBERNATE."
: 整半天, Grails 是在 Spring 上载套一层, 然后来模仿 Rails 这种东西的呀.
: 感觉好难受, 巨多层的抽象... -_-
|
d*******r
发帖数: 3299 | 73 多谢指点, 看来我还是让那帮人用 Node 算了, JVM 应该用在所谓 "大后端"
大牛能说说对 vert.x 3 的看法么, 还是得 "让子弹飞一会儿"
vert.x 能完成的工作, 主要竞争对手是哪些技术?
【在 g*****g 的大作中提到】
: Grail就是spring mvc + hibernate用Groovy写。spring mvc没有什么问题，纯粹是用
: java verbose而已。ROR比Spring MVC晚。web前端JVM可以做，但是前景不如NodeJs。
|
g*****g
发帖数: 34805 | 74 我不懂vert.x，也没法发表看法。
【在 d*******r 的大作中提到】
: 多谢指点, 看来我还是让那帮人用 Node 算了, JVM 应该用在所谓 "大后端"
: 大牛能说说对 vert.x 3 的看法么, 还是得 "让子弹飞一会儿"
: vert.x 能完成的工作, 主要竞争对手是哪些技术?
|
z*******3
发帖数: 13709 | 75 vert.x什么都能做
node单线程非常蛋疼，性能并不理想
而且将来streaming弄上去的话，我不认为单线程会有什么前途
因为streaming天生就是blocking的东东，你一定会需要多线程
而一旦涉及worker，node就不是那么好用
如果那帮人已经提出要弄jvm的话，多半是他们自己的考虑
就像你之前说的，主要做http web service，这个就不是web
多半不只需要倒腾html那些东东，等到时候绕了一大圈，最后发现
你还是不得不倒腾jvm的话，那就很不划算了
node有自己的engine，jvm是另外一个平台
要同时维持两套班底，就显得很亏
vert.x的主要竞争对手就是所有的东西
包括node, akka, ejb这些，其实都被某些媒体拿来对比过
就spring的di目前没怎么说，因为暂时先不做di，这个在community讨论过
主要是其他语言的开发者反对，因为无法实现，只有java的用户要求比较强烈
因为spring是de facto企业王者，所以建议多抄袭spring
最后tim说，暂时先不搞
但是你自己对spring熟悉的话，把spring结合到vert.x中去也不是那么困难的事
这个纯粹看开发者素质，vert.x没有那么傻瓜，虽然也不难
要驾驭自如的话，需要对一些概念比较熟悉，也有好处
这一套弄下来，很多概念设计理念就了然于心，不会有用其他框架那种瞎子摸象的感觉
真要出什么问题的话，一般都能搞定，因为都你自己做的
vert.x还有一个好处就是你接触到的技术，都是最新的
包括rxjava, docker, nosql这些，那批人都会教你怎么搞，有很详细的文档
不像某些公司的东西，基本上都在忽悠你，typesafe的很多东西都有这种感觉
看了一圈，你未必懂他在说什么，到处都是概念，你想问问题？给钱
vert.x所有文档我看过去都毫不费力，很容易的事情，无非就那点东西
很少跟你扯蛋概念，什么异步之类的都会详细解释一遍，不懂还可以问
最后要用vert.x 3的话，记得用rxjava，把vert.x rx那一部分认真学习一下
否则各种callback很容易造出金字塔来
【在 d*******r 的大作中提到】
: 多谢指点, 看来我还是让那帮人用 Node 算了, JVM 应该用在所谓 "大后端"
: 大牛能说说对 vert.x 3 的看法么, 还是得 "让子弹飞一会儿"
: vert.x 能完成的工作, 主要竞争对手是哪些技术?
|
z*******3
发帖数: 13709 | 76
ror在设计上有它的好处
groovy并不负责搞spring和hibernate的那些东西
这些framework和语言各有各的用处
并不是mutually exclusive
spring主要负责di和ioc，hibernate负责orm
groovy则主要是负责简化逻辑代码
你用groovy写各种crud很快
vert.x里面所有例子，groovy的代码是最简短的
超过其他所有脚本语言，比js还有ruby都简短
这个你如果用vert.x的话，可以直接对比，一下就看出来了
而简化代码跟di还有orm并不冲突啊
所谓grails就把这些东西汇总起来的这么一个框架
实际上所有的web server都是好几个东西的汇总
比如html template，比如session management，比如web listener etc.
讲一个东西容易一堆东西一起上，乱七八糟
比如struts以前就用了那个啥freemarker
搞vert.x就把这些都分开，你自己搭配，任何一个组件出了问题
你就去看这部分是咋回事，而不是瞎子摸象
啊，好大一个概念，你都不懂里面到底咋回事
虽然最后你还是得挨个对付这些东西，但是到底是怎么回事，经过你自己搭建起来之后
你自己应该很清楚是怎么回事，实在不懂，看源代码，就在你手上，你自己或者是同事
写的
【在 d*******r 的大作中提到】
: http://www.quora.com/Is-developing-in-Groovy-Grails-faster-than
: "Keep in mind Grails under the hood is SPRING and HIBERNATE."
: 整半天, Grails 是在 Spring 上载套一层, 然后来模仿 Rails 这种东西的呀.
: 感觉好难受, 巨多层的抽象... -_-
|
z*******3
发帖数: 13709 | 77 vert.x主要开发人员都在欧洲
感觉在欧洲应用得很广泛啊
苏格兰皇家银行，还有一些用了vert.x的软件，被汉莎等公司所使用 |
l**********n
发帖数: 8443 | 78 感觉java8还可以，你说呢？scala没戏。
【在 z*******3 的大作中提到】
: vert.x主要开发人员都在欧洲
: 感觉在欧洲应用得很广泛啊
: 苏格兰皇家银行，还有一些用了vert.x的软件，被汉莎等公司所使用
|
d*******r
发帖数: 3299 | 79 不过感觉用 [email protected]
/* */, 还不如直接用 [email protected]
/* */ 了
一直没太懂 rxjava 主要是干嘛的, 为啥要跟 vert.x 结合着用
【在 z*******3 的大作中提到】
: vert.x主要开发人员都在欧洲
: 感觉在欧洲应用得很广泛啊
: 苏格兰皇家银行，还有一些用了vert.x的软件，被汉莎等公司所使用
|
z*******3
发帖数: 13709 | 80 简单， 写起来快，是真的java script
尤其是如果你对class MyClass{
public static void main(String[] args){}
}
这些感到厌烦的话
rxjava就是fp那些东西啊，map，filter，flatmap etc.
用来排除金字塔很管用啊
每次返回一个observable，然后subscribe你的callback method就好了
subscribe完之后继续返回observable，如此循环，就不用金字塔了
这些在同步中很容易写，在fp和异步中就变得麻烦起来
但是最终可以写成
a.map()
.flatmap()
.filter()
...这种方式
比之前的
a.map(...,flatmap(...,filter()))
这种美观多了
如果不是fp的话，这里还需要嵌套一层object做匿名类，烦死
而且这个做下去就是streaming，一旦streaming开始推广
以后这种搞法会越来越多
/* */, 还不如直接用 [email protected]
/* */ 了
【在 d*******r 的大作中提到】
: 不过感觉用 [email protected]
: /* */, 还不如直接用 [email protected]
: /* */ 了
: 一直没太懂 rxjava 主要是干嘛的, 为啥要跟 vert.x 结合着用
|
|
|
z*******3
发帖数: 13709 | 81
java8用了->而不是=>
groovy也用->
scala用=>
不管怎样，groovy是clojure，scala这几个中最容易最快上手的
clojure比较麻烦，scala也比较麻烦
fp那一套需要对spring比较熟悉才行
spring可以理解成fp初级吧，对于func的side effect要求跟fp很像
当然没有immutable这种东东
【在 l**********n 的大作中提到】
: 感觉java8还可以，你说呢？scala没戏。
|
d*******r
发帖数: 3299 | 82 那感觉 rxjava 也不是必须的, 可能对 fp 粉很重要
【在 z*******3 的大作中提到】
: 简单， 写起来快，是真的java script
: 尤其是如果你对class MyClass{
: public static void main(String[] args){}
: }
: 这些感到厌烦的话
: rxjava就是fp那些东西啊，map，filter，flatmap etc.
: 用来排除金字塔很管用啊
: 每次返回一个observable，然后subscribe你的callback method就好了
: subscribe完之后继续返回observable，如此循环，就不用金字塔了
: 这些在同步中很容易写，在fp和异步中就变得麻烦起来
|
l**********n
发帖数: 8443 | 83 请问java有哪些异步框架？
【在 d*******r 的大作中提到】
: 那感觉 rxjava 也不是必须的, 可能对 fp 粉很重要
|
l**********n
发帖数: 8443 | 84 java有哪些websocket库？
【在 d*******r 的大作中提到】
: 那感觉 rxjava 也不是必须的, 可能对 fp 粉很重要
|
d*******r
发帖数: 3299 | 85 vert.x
【在 l**********n 的大作中提到】
: 请问java有哪些异步框架？
|
p*****2
发帖数: 21240 | 86 akka
vertx
【在 l**********n 的大作中提到】
: 请问java有哪些异步框架？
|
l**********n
发帖数: 8443 | 87 选哪个？
【在 p*****2 的大作中提到】
: akka
: vertx
|
p*****2
发帖数: 21240 | 88
选node或者go吧。
【在 l**********n 的大作中提到】
: 选哪个？
|
z*******3
发帖数: 13709 | 89
well，得承认vert.x可以当ejb用
如果你直接写worker verticle去监听port的话
但是如果你用了async的话，rx最好用上去
要不然各种callback会很快把金字塔造起来
就显得很恶心了
【在 d*******r 的大作中提到】
: 那感觉 rxjava 也不是必须的, 可能对 fp 粉很重要
|
z*******3
发帖数: 13709 | 90
vert.x天然就支持websocket
http,tcp,udp这些常见的网络协议vert.x都支持
还有jca, jms这些
自己翻翻manual吧，到处都是
http://vertx.io/docs/vertx-core/groovy/
WebSockets are a web technology that allows a full duplex socket-like
connection between HTTP servers and HTTP clients (typically browsers).
vert.x的api对新生事物的兼容性做得很好
各种features都围绕着新生的工具展开
下一步重点是streaming api
【在 l**********n 的大作中提到】
: java有哪些websocket库？
|
|
|
l**********n
发帖数: 8443 | 91 这个很有用，当然akka也行，可我觉得一般人觉得akka太难
【在 z*******3 的大作中提到】
:
: vert.x天然就支持websocket
: http,tcp,udp这些常见的网络协议vert.x都支持
: 还有jca, jms这些
: 自己翻翻manual吧，到处都是
: http://vertx.io/docs/vertx-core/groovy/
: WebSockets are a web technology that allows a full duplex socket-like
: connection between HTTP servers and HTTP clients (typically browsers).
: vert.x的api对新生事物的兼容性做得很好
: 各种features都围绕着新生的工具展开
|
z*******3
发帖数: 13709 | 92
其实不难，typesafe那帮人故意弄复杂了
估计好骗钱吧，it很多东西都故意弄得很复杂，便于收取咨询费
akka的基本单位跟vert.x一样
vert.x官方文档里面也说了，就是actor model
但是akka的是树状结构，一个接一个，就像tree node一样
vert.x是bus结构，所有的communication通过event bus完成
就更简单一点，然后各种接口什么也都比较完整
你可以随心所欲自由搭配和组合，这种非侵入式的设计比较讨喜
【在 l**********n 的大作中提到】
: 这个很有用，当然akka也行，可我觉得一般人觉得akka太难
|
p*****2
发帖数: 21240 | 93 vertx比akka简单 但是还是比node go麻烦
【在 l**********n 的大作中提到】
: 这个很有用，当然akka也行，可我觉得一般人觉得akka太难
|
z****e
发帖数: 54598 | 94 go不简单，各种轮子不全，而且明显太底层了
node简单有代价，明显过于倾向web了
而且benchmark这两个都很不行
：vertx比akka简单 但是还是比node go麻烦
： |
