b*t
2 楼
24G的headpins, 22G的earwire, 8mm珊瑚珠。那个28G的细线,我做了挡珠。
w*o
3 楼
【 以下文字转载自 LoveNLust 讨论区 】
发信人: aihaha (爱哈哈), 信区: LoveNLust
标 题: sigh, 我怎么老有发包子的冲动呢?
发信站: BBS 未名空间站 (Sat Nov 21 20:31:47 2009, 美东)
好在一天只能发10个,不然版面的包子我一天就发光了。。。
我竟然是个败家类型的?
发信人: aihaha (爱哈哈), 信区: LoveNLust
标 题: sigh, 我怎么老有发包子的冲动呢?
发信站: BBS 未名空间站 (Sat Nov 21 20:31:47 2009, 美东)
好在一天只能发10个,不然版面的包子我一天就发光了。。。
我竟然是个败家类型的?
s*s
4 楼
这俩有什么区别? 是不是只学一个就够了.
Y*t
5 楼
很奇怪庄下家没有用黑K拿牌权后打片子,难道这时候就谋划最后双扣底牌?
真这样的话,那太牛了
真这样的话,那太牛了
j*y
6 楼
好Q啊
e*t
7 楼
servlet is the underlying technology and you'd better get a grasp of it. But
you rarely need to write your own servlet.
JSF is something built on top of servlet, which is more important than servl
et itself. If you want to work with a JavaEE webapplication. You probably wa
nt to pay more attention to JSF.
【在 s****s 的大作中提到】
: 这俩有什么区别? 是不是只学一个就够了.
you rarely need to write your own servlet.
JSF is something built on top of servlet, which is more important than servl
et itself. If you want to work with a JavaEE webapplication. You probably wa
nt to pay more attention to JSF.
【在 s****s 的大作中提到】
: 这俩有什么区别? 是不是只学一个就够了.
j*y
9 楼
好Q啊
s*s
10 楼
谢谢.
But
servl
wa
【在 e*****t 的大作中提到】
: servlet is the underlying technology and you'd better get a grasp of it. But
: you rarely need to write your own servlet.
: JSF is something built on top of servlet, which is more important than servl
: et itself. If you want to work with a JavaEE webapplication. You probably wa
: nt to pay more attention to JSF.
But
servl
wa
【在 e*****t 的大作中提到】
: servlet is the underlying technology and you'd better get a grasp of it. But
: you rarely need to write your own servlet.
: JSF is something built on top of servlet, which is more important than servl
: et itself. If you want to work with a JavaEE webapplication. You probably wa
: nt to pay more attention to JSF.
a*e
12 楼
简易,美观
h*h
15 楼
cute
x*8
18 楼
学习了!赞!
g*g
19 楼
jsf is going nowhere.
r*q
21 楼
赞!
y*i
24 楼
喜欢珊瑚
b*y
25 楼
同意。当年我加入公司的时候,前lead developer用IBM的JSF开发了个内部的产品管理
系统。结果,总是30分钟不到就内存溢出了。这个也许是IBM的JSF实现的不好,也许是
他编程的时候用的node太多了?Anyway.
我的感觉,JSF是肉包铁,Java servlet是铁包肉。是不是有点形象的比喻? 呵呵
如果我没记错的话,JSF在内存里生成了对应的html page的tree structure,所以,占
内存大。而且,designer很难插手做前台?
jsp还好。不过,我们都用的是Velocity template engine. 简单,速度快。我也自己
编写过一个类似的java template engine, 感觉这东西比jsp更加MVC.
【在 g*****g 的大作中提到】
: jsf is going nowhere.
c*n
27 楼
zan ~~~
z*s
28 楼
有种说法是理解了servlet才真正理解什么是j2ee??
k*n
30 楼
cute
s*0
32 楼
怎么没人讨论庄错在哪里?
m*V
33 楼
典雅!
o*1
36 楼
jsf 还在坚持,也改变了很多,但是还是用的人不多。
jsp就是所有 container都支持,不用什么额外的 jar.
最好的 template engine 是 thymeleaf, 几乎能想到的方便的地方它都有。
也非常适合美工和程序员合作。
【在 b******y 的大作中提到】
:
: 同意。当年我加入公司的时候,前lead developer用IBM的JSF开发了个内部的产品管理
: 系统。结果,总是30分钟不到就内存溢出了。这个也许是IBM的JSF实现的不好,也许是
: 他编程的时候用的node太多了?Anyway.
: 我的感觉,JSF是肉包铁,Java servlet是铁包肉。是不是有点形象的比喻? 呵呵
: 如果我没记错的话,JSF在内存里生成了对应的html page的tree structure,所以,占
: 内存大。而且,designer很难插手做前台?
: jsp还好。不过,我们都用的是Velocity template engine. 简单,速度快。我也自己
: 编写过一个类似的java template engine, 感觉这东西比jsp更加MVC.
jsp就是所有 container都支持,不用什么额外的 jar.
最好的 template engine 是 thymeleaf, 几乎能想到的方便的地方它都有。
也非常适合美工和程序员合作。
【在 b******y 的大作中提到】
:
: 同意。当年我加入公司的时候,前lead developer用IBM的JSF开发了个内部的产品管理
: 系统。结果,总是30分钟不到就内存溢出了。这个也许是IBM的JSF实现的不好,也许是
: 他编程的时候用的node太多了?Anyway.
: 我的感觉,JSF是肉包铁,Java servlet是铁包肉。是不是有点形象的比喻? 呵呵
: 如果我没记错的话,JSF在内存里生成了对应的html page的tree structure,所以,占
: 内存大。而且,designer很难插手做前台?
: jsp还好。不过,我们都用的是Velocity template engine. 简单,速度快。我也自己
: 编写过一个类似的java template engine, 感觉这东西比jsp更加MVC.
t*e
38 楼
现在没人用plain JSF,都有用RIA libs, 像primefaces之类,有javascript
abstraction,开发效率非常高。没有component model+js abstraction,让你几个月
时间开发上百页的RIA app,无法想象。healthcare为例,会有很长的workflow,复杂
的forms。
nodejs适合有js背景的人用,局限也不少。
关于web framework的争论一直都在,很多年前关于wicket就在本版讨论的很火爆。不
知道现在wicket还安好。孰优孰劣本无定论。都是根据具体要求和developers的背景决
定使用的技术。
abstraction,开发效率非常高。没有component model+js abstraction,让你几个月
时间开发上百页的RIA app,无法想象。healthcare为例,会有很长的workflow,复杂
的forms。
nodejs适合有js背景的人用,局限也不少。
关于web framework的争论一直都在,很多年前关于wicket就在本版讨论的很火爆。不
知道现在wicket还安好。孰优孰劣本无定论。都是根据具体要求和developers的背景决
定使用的技术。
o*1
40 楼
wicket估计没什么戏。
这种把应该前台做的工作拿到后台去做的web framework都是把简单问题复杂化。
GWT 也是这个样子,现在已经下坡路的厉害。
【在 t*******e 的大作中提到】
: 现在没人用plain JSF,都有用RIA libs, 像primefaces之类,有javascript
: abstraction,开发效率非常高。没有component model+js abstraction,让你几个月
: 时间开发上百页的RIA app,无法想象。healthcare为例,会有很长的workflow,复杂
: 的forms。
: nodejs适合有js背景的人用,局限也不少。
: 关于web framework的争论一直都在,很多年前关于wicket就在本版讨论的很火爆。不
: 知道现在wicket还安好。孰优孰劣本无定论。都是根据具体要求和developers的背景决
: 定使用的技术。
这种把应该前台做的工作拿到后台去做的web framework都是把简单问题复杂化。
GWT 也是这个样子,现在已经下坡路的厉害。
【在 t*******e 的大作中提到】
: 现在没人用plain JSF,都有用RIA libs, 像primefaces之类,有javascript
: abstraction,开发效率非常高。没有component model+js abstraction,让你几个月
: 时间开发上百页的RIA app,无法想象。healthcare为例,会有很长的workflow,复杂
: 的forms。
: nodejs适合有js背景的人用,局限也不少。
: 关于web framework的争论一直都在,很多年前关于wicket就在本版讨论的很火爆。不
: 知道现在wicket还安好。孰优孰劣本无定论。都是根据具体要求和developers的背景决
: 定使用的技术。
s*0
43 楼
怎么没人理我?nnd
谁第一个答对了给2个包子,我就不信没人讨论。
谁第一个答对了给2个包子,我就不信没人讨论。
g*g
44 楼
server side component based is not going anywhere. For two major issues.
1. Poor separation of backend and frontend personnel. web pages tend to be
more flashy than traditional desktop UI. While components are handy, it's
painful to customize CSS, and creating new components is difficult too.
2. Performance, this takes lots of memory and it's not suitable for websites
that can serve 10s of millions of users. It's probably an OK choice for
internal websites.
With html5/JS components getting stronger everyday, the writing is on the
wall.
1. Poor separation of backend and frontend personnel. web pages tend to be
more flashy than traditional desktop UI. While components are handy, it's
painful to customize CSS, and creating new components is difficult too.
2. Performance, this takes lots of memory and it's not suitable for websites
that can serve 10s of millions of users. It's probably an OK choice for
internal websites.
With html5/JS components getting stronger everyday, the writing is on the
wall.
e*t
46 楼
I agree with this.
By using js component based frameworks, front end UI developers can easily p
rototype UI desgins without much backend interaction.
Our UI developers do their prototyping or some bug fixing on some kind of mo
ck server (tomcat based). They hate to bring up the full application (jboss)
, which may take up to 15 mins to start, not to mention the data setup.
On the other hand, JSP/JSFs are used to server the http requests. They serve
r the pages, and it works well for big page level components. But I suppose
that's not the original purpose of JSF.
websites
【在 g*****g 的大作中提到】
: server side component based is not going anywhere. For two major issues.
: 1. Poor separation of backend and frontend personnel. web pages tend to be
: more flashy than traditional desktop UI. While components are handy, it's
: painful to customize CSS, and creating new components is difficult too.
: 2. Performance, this takes lots of memory and it's not suitable for websites
: that can serve 10s of millions of users. It's probably an OK choice for
: internal websites.
: With html5/JS components getting stronger everyday, the writing is on the
: wall.
By using js component based frameworks, front end UI developers can easily p
rototype UI desgins without much backend interaction.
Our UI developers do their prototyping or some bug fixing on some kind of mo
ck server (tomcat based). They hate to bring up the full application (jboss)
, which may take up to 15 mins to start, not to mention the data setup.
On the other hand, JSP/JSFs are used to server the http requests. They serve
r the pages, and it works well for big page level components. But I suppose
that's not the original purpose of JSF.
websites
【在 g*****g 的大作中提到】
: server side component based is not going anywhere. For two major issues.
: 1. Poor separation of backend and frontend personnel. web pages tend to be
: more flashy than traditional desktop UI. While components are handy, it's
: painful to customize CSS, and creating new components is difficult too.
: 2. Performance, this takes lots of memory and it's not suitable for websites
: that can serve 10s of millions of users. It's probably an OK choice for
: internal websites.
: With html5/JS components getting stronger everyday, the writing is on the
: wall.
t*e
48 楼
Not the first time you made such a statement. The truth is, component model
is an abstraction layer hiding programming complexity in HTML/JS. Given that
UI components are managed and enriched constantly by software vendors, the
same set of components rendering HTML today can generate HTML5 tomorrow. A
component-based website can be upgraded to HTML5 with new features almost
effortlessly.
is an abstraction layer hiding programming complexity in HTML/JS. Given that
UI components are managed and enriched constantly by software vendors, the
same set of components rendering HTML today can generate HTML5 tomorrow. A
component-based website can be upgraded to HTML5 with new features almost
effortlessly.
t*e
50 楼
It is a separation of concerns. Rather having the UI developers to reinvent
the wheel, component vendors package their products which are ready to be
used off-the-shelf by application developers.
p
mo
jboss)
serve
suppose
【在 e*****t 的大作中提到】
: I agree with this.
: By using js component based frameworks, front end UI developers can easily p
: rototype UI desgins without much backend interaction.
: Our UI developers do their prototyping or some bug fixing on some kind of mo
: ck server (tomcat based). They hate to bring up the full application (jboss)
: , which may take up to 15 mins to start, not to mention the data setup.
: On the other hand, JSP/JSFs are used to server the http requests. They serve
: r the pages, and it works well for big page level components. But I suppose
: that's not the original purpose of JSF.
:
the wheel, component vendors package their products which are ready to be
used off-the-shelf by application developers.
p
mo
jboss)
serve
suppose
【在 e*****t 的大作中提到】
: I agree with this.
: By using js component based frameworks, front end UI developers can easily p
: rototype UI desgins without much backend interaction.
: Our UI developers do their prototyping or some bug fixing on some kind of mo
: ck server (tomcat based). They hate to bring up the full application (jboss)
: , which may take up to 15 mins to start, not to mention the data setup.
: On the other hand, JSP/JSFs are used to server the http requests. They serve
: r the pages, and it works well for big page level components. But I suppose
: that's not the original purpose of JSF.
:
g*g
52 楼
It's not re-inventing the wheels, the components can be in pure html/js.
And they are not tied to particular server technology or language. I would
argue that the library is richer and better that way.
reinvent
【在 t*******e 的大作中提到】
: It is a separation of concerns. Rather having the UI developers to reinvent
: the wheel, component vendors package their products which are ready to be
: used off-the-shelf by application developers.
:
: p
: mo
: jboss)
: serve
: suppose
And they are not tied to particular server technology or language. I would
argue that the library is richer and better that way.
reinvent
【在 t*******e 的大作中提到】
: It is a separation of concerns. Rather having the UI developers to reinvent
: the wheel, component vendors package their products which are ready to be
: used off-the-shelf by application developers.
:
: p
: mo
: jboss)
: serve
: suppose
s*0
53 楼
重赏之下都没勇夫出来?
t*e
54 楼
Put it this way, for most companies out there, component approach is more
cost-effective. Big players need to invent brand new widgets and eliminate
ties to any particular software vendor, html/js is the way to go.
【在 g*****g 的大作中提到】
: It's not re-inventing the wheels, the components can be in pure html/js.
: And they are not tied to particular server technology or language. I would
: argue that the library is richer and better that way.
:
: reinvent
cost-effective. Big players need to invent brand new widgets and eliminate
ties to any particular software vendor, html/js is the way to go.
【在 g*****g 的大作中提到】
: It's not re-inventing the wheels, the components can be in pure html/js.
: And they are not tied to particular server technology or language. I would
: argue that the library is richer and better that way.
:
: reinvent
e*t
56 楼
I think everyone is on the same page.
For us, we need to build our own js component libraries on top of 3rd party
js frameworks (namely jquery and etc).
3rd party js component only deal with very low level components, and we need
bigger more integrated components. They typically have the data exchange in
terfaces well defined. Advantages are:
1. Consistent look and feel across different modules
2. easier css customization
3. underlying techonology agnostic, it can be java, ruby, even php.
【在 g*****g 的大作中提到】
: It's not re-inventing the wheels, the components can be in pure html/js.
: And they are not tied to particular server technology or language. I would
: argue that the library is richer and better that way.
:
: reinvent
For us, we need to build our own js component libraries on top of 3rd party
js frameworks (namely jquery and etc).
3rd party js component only deal with very low level components, and we need
bigger more integrated components. They typically have the data exchange in
terfaces well defined. Advantages are:
1. Consistent look and feel across different modules
2. easier css customization
3. underlying techonology agnostic, it can be java, ruby, even php.
【在 g*****g 的大作中提到】
: It's not re-inventing the wheels, the components can be in pure html/js.
: And they are not tied to particular server technology or language. I would
: argue that the library is richer and better that way.
:
: reinvent
t*e
58 楼
真不容易。
【在 e*****t 的大作中提到】
: I think everyone is on the same page.
: For us, we need to build our own js component libraries on top of 3rd party
: js frameworks (namely jquery and etc).
: 3rd party js component only deal with very low level components, and we need
: bigger more integrated components. They typically have the data exchange in
: terfaces well defined. Advantages are:
: 1. Consistent look and feel across different modules
: 2. easier css customization
: 3. underlying techonology agnostic, it can be java, ruby, even php.
z*e
62 楼
我这边的一个法国军工巨头在用jsf
我看页面后缀是.jsf
【在 t*******e 的大作中提到】
: 现在没人用plain JSF,都有用RIA libs, 像primefaces之类,有javascript
: abstraction,开发效率非常高。没有component model+js abstraction,让你几个月
: 时间开发上百页的RIA app,无法想象。healthcare为例,会有很长的workflow,复杂
: 的forms。
: nodejs适合有js背景的人用,局限也不少。
: 关于web framework的争论一直都在,很多年前关于wicket就在本版讨论的很火爆。不
: 知道现在wicket还安好。孰优孰劣本无定论。都是根据具体要求和developers的背景决
: 定使用的技术。
我看页面后缀是.jsf
【在 t*******e 的大作中提到】
: 现在没人用plain JSF,都有用RIA libs, 像primefaces之类,有javascript
: abstraction,开发效率非常高。没有component model+js abstraction,让你几个月
: 时间开发上百页的RIA app,无法想象。healthcare为例,会有很长的workflow,复杂
: 的forms。
: nodejs适合有js背景的人用,局限也不少。
: 关于web framework的争论一直都在,很多年前关于wicket就在本版讨论的很火爆。不
: 知道现在wicket还安好。孰优孰劣本无定论。都是根据具体要求和developers的背景决
: 定使用的技术。
z*f
65 楼
肯定是昆仑BSO的
其实回头看看,估计once太兴奋了,毕竟1010小王小王干掉大王对的机会不多。打得过
程中几个比较明显的失误
1.没留保护张,花打得太快
2.红的问题解决的太晚
3.庄下没红,给了黑K,只能是片上手了,全盘始终都没上过手,怎么都不能放
我要是红8换成片9更好点,不过对家黑K扔了,也没啥大区别。
其实回头看看,估计once太兴奋了,毕竟1010小王小王干掉大王对的机会不多。打得过
程中几个比较明显的失误
1.没留保护张,花打得太快
2.红的问题解决的太晚
3.庄下没红,给了黑K,只能是片上手了,全盘始终都没上过手,怎么都不能放
我要是红8换成片9更好点,不过对家黑K扔了,也没啥大区别。
z*e
66 楼
这里有个对比
貌似thymeleaf评价颇高啊
全部yes的只有两个,另外一个不开源
剩下的就只有thymeleaf了
http://en.wikipedia.org/wiki/Template_engine_(web)
貌似thymeleaf评价颇高啊
全部yes的只有两个,另外一个不开源
剩下的就只有thymeleaf了
http://en.wikipedia.org/wiki/Template_engine_(web)
s*0
69 楼
庄的致命错误在于花A之后接着出了5张花!你们要知道打NT这5张花意味着什么?意味着
5个主!必须留着最后出!你先打,就像先打自己手里的长套一样的错误,给敌人整理
自己牌的机会!!如果广大牌友对一开始打长套的弊端还没理解透彻,希望通过这个典型
牌例能够彻底弄明白了。
如果没有这个致命伤,哪里会发生后面的事情?其它的错误就不会存在了,根本就不可
能会被双扣了!
【在 z***f 的大作中提到】
: 肯定是昆仑BSO的
: 其实回头看看,估计once太兴奋了,毕竟1010小王小王干掉大王对的机会不多。打得过
: 程中几个比较明显的失误
: 1.没留保护张,花打得太快
: 2.红的问题解决的太晚
: 3.庄下没红,给了黑K,只能是片上手了,全盘始终都没上过手,怎么都不能放
: 我要是红8换成片9更好点,不过对家黑K扔了,也没啥大区别。
5个主!必须留着最后出!你先打,就像先打自己手里的长套一样的错误,给敌人整理
自己牌的机会!!如果广大牌友对一开始打长套的弊端还没理解透彻,希望通过这个典型
牌例能够彻底弄明白了。
如果没有这个致命伤,哪里会发生后面的事情?其它的错误就不会存在了,根本就不可
能会被双扣了!
【在 z***f 的大作中提到】
: 肯定是昆仑BSO的
: 其实回头看看,估计once太兴奋了,毕竟1010小王小王干掉大王对的机会不多。打得过
: 程中几个比较明显的失误
: 1.没留保护张,花打得太快
: 2.红的问题解决的太晚
: 3.庄下没红,给了黑K,只能是片上手了,全盘始终都没上过手,怎么都不能放
: 我要是红8换成片9更好点,不过对家黑K扔了,也没啥大区别。
r*s
70 楼
If you are building your own js components,
you should use ExtJs.
It's already componentized at js layer.
JQuery is for small projects.
party
need
in
【在 e*****t 的大作中提到】
: I think everyone is on the same page.
: For us, we need to build our own js component libraries on top of 3rd party
: js frameworks (namely jquery and etc).
: 3rd party js component only deal with very low level components, and we need
: bigger more integrated components. They typically have the data exchange in
: terfaces well defined. Advantages are:
: 1. Consistent look and feel across different modules
: 2. easier css customization
: 3. underlying techonology agnostic, it can be java, ruby, even php.
you should use ExtJs.
It's already componentized at js layer.
JQuery is for small projects.
party
need
in
【在 e*****t 的大作中提到】
: I think everyone is on the same page.
: For us, we need to build our own js component libraries on top of 3rd party
: js frameworks (namely jquery and etc).
: 3rd party js component only deal with very low level components, and we need
: bigger more integrated components. They typically have the data exchange in
: terfaces well defined. Advantages are:
: 1. Consistent look and feel across different modules
: 2. easier css customization
: 3. underlying techonology agnostic, it can be java, ruby, even php.
s*0
71 楼
snowman10,您好:
您转给 zdzbf,现金(伪币):20,收取手续费:0.2
同时附加了如下留言给 zdzbf.
答对了!
站务
您转给 zdzbf,现金(伪币):20,收取手续费:0.2
同时附加了如下留言给 zdzbf.
答对了!
站务
s*0
73 楼
其实对庄上家和庄下家垫牌出牌的次序和思路来说,都存在错误和紊乱!比如最致命的
庄上家的一个错误就是最后该打方块9,这样对家就知道他的方块88都是大的了。可以
方块5张一起甩!如果庄还有一对主10,那么刚好杀了方块88,哪里来的胜利可言?
所以,垫牌时,必须垫没用的那门大的牌,或者从来还没出现过的比较大的牌,这样就
能给对家一些有用的信息,他就能知道他的对子或者这门能不能一起甩出去了。其实,
任何一次牌局,只要你能好好思考总结,都能得到相似的结论!所以打牌贵在思考!!
!
庄上家的一个错误就是最后该打方块9,这样对家就知道他的方块88都是大的了。可以
方块5张一起甩!如果庄还有一对主10,那么刚好杀了方块88,哪里来的胜利可言?
所以,垫牌时,必须垫没用的那门大的牌,或者从来还没出现过的比较大的牌,这样就
能给对家一些有用的信息,他就能知道他的对子或者这门能不能一起甩出去了。其实,
任何一次牌局,只要你能好好思考总结,都能得到相似的结论!所以打牌贵在思考!!
!
s*e
76 楼
I do not think that you can compare JSF to servlet. JSF was introduced by
sun trying to compete with other application tier technologies such as
struts, spring mvc... Like all those web frameworks, jsf is based on Servlet
. Actually without jsp/servlet spec, none of those java based web frameworks
will ever work at all. JSF, not like other web frameworks, is designed
using page controller pattern, which is subtly different from front
controller patterns used by most other popular web frameworks.
For the future of servlet and servlet based frameworks, I do not think it
will die soon considering huge investments and open source efforts put in
the area. Actually till today, I do not see any new technology will be able
to replace servlet soon. web/restful services were long said to be the best
candidate to retire servlet, but it fall short of the task. Now server side
js is viewed to be the next one...
sun trying to compete with other application tier technologies such as
struts, spring mvc... Like all those web frameworks, jsf is based on Servlet
. Actually without jsp/servlet spec, none of those java based web frameworks
will ever work at all. JSF, not like other web frameworks, is designed
using page controller pattern, which is subtly different from front
controller patterns used by most other popular web frameworks.
For the future of servlet and servlet based frameworks, I do not think it
will die soon considering huge investments and open source efforts put in
the area. Actually till today, I do not see any new technology will be able
to replace servlet soon. web/restful services were long said to be the best
candidate to retire servlet, but it fall short of the task. Now server side
js is viewed to be the next one...
相关阅读
apache commons是啥东西呀?你们一般把transaction放在哪一层?在google play发布安卓app,license以及copyright相关问题,望大侠指点!遇到Swing的一个问题请问Freemarker和EJB3有必要学吗?一个建网站的思路问题: 文件版本Why Java did not include Tree or Graph into its Collecionts Framwork?Java里面的SWT或者Swing为啥还有书在介绍呢现在的客户,同时要3个产品:website application,iphone app,android app有谁在做drupal programming吗? (转载)是不是spring mvc用的很少Free Coursera course: Algorithms, Part I startedSSH lib for Java请问Hadoop要怎么学?aspx网页现在到底流行不?MSDN有啥值得下载的吗?programming那帮人好好玩啊如何让一个package使用另一个package的sourceWhy inner classes can access only local final variables?spring到底有什么好处?