Currently there's quite a debate raging over the relative merits of Groovy and JRuby as scripting languages running on the Java virtual machine. Curious minds want to know - which of these languages will win this upcoming language war? People want to know which language to pick for a project, or which language to commit to learn.
Perhaps the first thing to point out is that it's perhaps rather unfair to see this as a race between these particular two horses. Scripting has been available on the JVM for a long time. Jython, a Java implementation of Python, has been around for several years. There's plenty of other, more obscure languages, which I daren't mention for fear of offending all the ones I miss out.
JRuby has got a lot of attention due to the attention of the Ruby language generally - attention particularly ignited by the interest around Rails. We've seen a sharp spike of interest around Ruby and Rails work at ThoughtWorks, and JRuby adds an extra dimension since it allows people to deploy Rails applications using their existing Java infrastructure.
Groovy gets its attention because it, more than any other language, is designed to work seamlessly with the JVM, and got a lot of attention from an early JSR.
Personally I'd dropped Groovy from my radar a couple of years ago when its development seemed to bog down. With its 1.0 release and further interesting positive vibes from some of my colleagues I've started to pay attention again.
Lets begin by talking about similarities. Both JRuby and Groovy (and indeed Jython) are modern OO scripting languages. They combine the well-chosen terseness of scripting languages with good solid structures for building larger programs. As such they are suitable both for classical scripting and for writing larger programs. Both are comfortable with dynamic type checking, although Groovy does offer some static facilities too. Both support Closures which are an important feature for the greater expressiveness that people want from this kind of language.
The biggest difference between them is their broader platform philosophy. Groovy is designed to be a scripting language for Java. As much as possible its syntax tries to match the equivalent in Java. (Including such ugly things as the default fall-through in switch statements.) It also works with Java's class library directly, although it dynamically adds many methods to Java's classes, vital in order to make use of things like closures.
JRuby, however, is a Java implementation of the Ruby platform. Ruby can run directly on mainstream operating systems with a C runtime, and is starting to run on .NET's CLR. When you program in JRuby you primarily use Ruby's libraries which are implemented in Java, and may also use Java's libraries at your discretion. If you stick to Ruby's libraries, or at least wrap any foreign elements, you can run Ruby programs on the C, Java, or (in time) .NET runtimes. So you can use JRuby to both run Ruby programs on the JVM and as a language for scripting the JVM.
One of the big differences between JRuby and Jython is around the libraries. One of the tricky aspects of porting this kind of scripting language to the JVM is that these languages are usually closely intertwined with libraries implemented in C. Porting these libraries to Java involves rewriting the libraries in Java. Jython didn't do much of this, as a result many Python apps can't run in Jython. However the JRuby implementers decided from early on that their goal was to run Rails apps, as a result many libraries including all the Ruby standard libraries needed to be ported.
The fact that JRuby is a Ruby platform on the JVM means that in JRuby you have two kinds of objects - JRuby objects and Java objects. Although there are ways for the two to talk to each other and to convert there is a difference. There are times when you need to know whether you're dealing with a Java string or a JRuby string. With Groovy you don't have that boundary, there are just Java objects.
It's too early, or rather too difficult, to say if one language will win out. Both are pretty young, only just finding their feet on the JVM. On a more personal level, your choice has a lot to do with what you expect to do with it. If you are only interested in running on the JVM, then Groovy could well be the easier choice. You are working directly with Java's library and object model, and the syntax requires less getting used to. A strong reason to prefer Ruby is the fact that it lives in multiple implementations. Ruby is a tool you can use in a lot of other places. As a long time Rubyist, there's not much incentive for me personally to get heavily into Groovy, even though I actually like the language a lot from what I've seen of it.
Rails is an important factor. The Java world is hardly lacking in web frameworks, but Rails is widely liked by those who've used it. I've not got many reports yet about Grails (the Groovy knock-off) so can't give a firm opinion on that. But I can imagine that the ability to deploy web apps with Rails could be a major factor in making JRuby popular. Something else to look at is the growth of RSpec as a new spin on testing environments.
With any platform it's as important to consider the people involved in the community as much as any technical factors. Good people can overcome technical weaknesses quickly and a vibrant community is a potent source for big innovations. RubyPeople have formed a particularly strong community, which has already spawned things like Rails, Rake, and Rspec.
Will either matter to Java? After all Jython's been around for a long time without making a huge impact on the JVM. Tool support is frankly pathetic for any of these languages when you compare it to what you have for Java at the moment.
I think we're actually at an inflection point with Java. Until recently the Java cry was One VM and OneLanguage. (As opposed to the CLR which was one VM and many languages, providing they're C# or VB.) This seems to be changing as people realize the limitations of Java and begin to seek out different capabilities. It's likely the future will see multiple languages closely integrated within the JVM.
There are plenty of people who dislike the hype around Rails and Ruby. But even if you dislike Ruby, the hype has led to a resurgence of interest in new languages. I doubt if the interest in Groovy would be anywhere near as great as it is if it wasn't for this hype, nor would Jython be awaking from its slumbers. The ruby/rails hype has also generated interest in other exotic JVM languages. The really nice thing here is that the JRuby people have been encouraging their dynamic rivals - recognizing that the point here is to encourage multi-lingual inter-operability and innovation.
1:設置環境變量CATALINA_HOME＝E:"tomcat5.5
2：設置CLASS_PATH 為CLASS_PATH＝.;C:"java"jdk1.5.0_06"lib"dt.jar;C:"java"jdk1.5.0_06"lib"tools.jar;%CATALINA_HOME%"bin"bootstrap.jar
3：設置PATH中為C:"java"jdk1.5.0_06"bin;E:"tomcat5.5"bin;
4：添加服務命令：service.bat install Tomcat5
運行完命令后就可以在服務中看到 Apache Tomcat5 然后可以自行改為手動或自動啟動。
注：如果使用tomcat5.exe安裝名字為'Tomcat5'的服務可以運行以下命令：
tomcat5 //IS//Tomcat5 --DisplayName="Apache Tomcat 5"
--Install="C:"Program Files"Tomcat"bin"tomcat5.exe" --Jvm=auto
--StartMode=jvm --StopMode=jvm
--StartClass=org.apache.catalina.startup.Bootstrap --StartParams=start
--StopClass=org.apache.catalina.startup.Bootstrap --StopParams=stop
5：移除服務命令：tomcat5 //DS//Tomcat5
http://blog.digitalascent.com/2007/11/gwt-rpc-with-spring-2x_12.html
http://gwt-widget.sourceforge.net/?q=node/39
先記下來，有空好好研究研究
找工作是一個體力腦力都需要很大挑戰的事情，需要提前做好充分的準備。從整體來講最終的結果是靠長年的積累來取得好的結果，但是隨機性處處存在，實力不是決定因素。因此，做好充分的準備是有必要的：
1、要好好準備你的簡歷，中英文都需要，而且越能體現你的特長越好，把你的優勢寫在最前。簡歷意味著你是否能進筆試，沒有這個啥都沒有
2、在中國，找工作筆試很重要，聽說在發達國家，找工作都是靠面試，而在中國，在這樣一個龐大的人群中，筆試卻成為最重要的一個環節。除非你的Java或者C#強到足以說，我能靠這些找到一份理想的工作不成問題的情況。否則，你還是需要準備C、C++，而且越是偏題，越是怪題，越要仔細留意。例如c中的sizeof()函數，是我見過筆試最多出現的，但是你在工作中會用到多少呢？所以說中國的應試教育甚至影響到了找工作，不過人還是要先適應環境才能改變環境的。推薦一本書《程序員面試寶典》這本書的確很有用，如果你不想好好再學C或者C++（和我一樣，狂汗）的話，這本書足夠你應付一些疑難雜癥了了。還要準備算法，例如一些樹和圖的算法，是最經常考的
3、平時要敢于說話，要敢于表達自己。找工作一定不要害羞。怕什么？你自己如果真有實力，那展現出來就好啦，沒什么比一個好的單位找到一個好的人才更令他們開心的了，既然是這樣，你還怕什么啊？當然，你要是沒實力，那就另當別論了，萬一裝腔作勢被拆穿，結果很可怕。所以簡歷中，絕對不要寫自己不熟悉的東西。在找工作前，要找一些能代表你技術實力的項目，最好提前做ppt，多試著演講幾次。還有我在找工作的時候遇到過有人讓我當場演示寫程序，尤其是有些公司會邀請你去參與他們的項目中去，那么，你如果會用快捷鍵，那是一件能加很多分的技能
4、實習能加很多分。實習的人，找實習單位的工作非常的容易，或許是人情分吧，不過這也沒辦法。我為了導師的項目，放棄了實習機會，的確很可惜，但是也沒什么好后悔的，做人么，坦坦蕩蕩一些
5、不要怕被好的公司拒掉，你要堅信一點，你很優秀，拒掉是他們的損失。而且，相信自己，是金子總會發光，關鍵是你自己不能放棄自己，那樣什么都沒有。既然你喜歡這一行，你喜歡創造的感覺，那么就快樂的工作下去吧
6、別心急，鍋底有肉，總有很好的工作留在最后面，據說11、12月份有很多工作單位錄人不夠會很著急，那么你就很容易找到工作啦，所以，別急么
7、第一份工作并沒有你想象中的那么重要，關鍵是要在工作中積累自己，這才是最重要的，只要你不停的提高自己的實力，你想錢會少么？所以，別那么在意得失，要做一個聰明的糊涂蛋
好啦，今天就寫到這吧，我現在也能想到這么多啦，加油吧
JDK 1.1.4
Sparkler
寶石
1997-09-12
JDK 1.1.5
Pumpkin
南瓜
1997-12-13
JDK 1.1.6
Abigail
阿比蓋爾--女子名
1998-04-24
JDK 1.1.7
Brutus
布魯圖--古羅馬政治家和將軍
1998-09-28
JDK 1.1.8
Chelsea
切爾西--城市名
1999-04-08
J2SE 1.2
Playground
運動場
1998-12-04
J2SE 1.2.1
none
無
1999-03-30
J2SE 1.2.2
Cricket
蟋蟀
1999-07-08
J2SE 1.3
Kestrel
美洲紅隼
2000-05-08
J2SE 1.3.1
Ladybird
瓢蟲
2001-05-17
J2SE 1.4.0
Merlin
灰背隼
2002-02-13
J2SE 1.4.1
grasshopper
蚱蜢
2002-09-16
J2SE 1.4.2
Mantis
螳螂
2003-06-26
J2SE 5.0 (1.5.0)
Tiger
老虎
2004-10
J2SE 6.0 (Beta)
Mustang
野馬
2006-04
百度的面試是這樣的
一面的時候考察技術細節和IT知識。從深度和廣度上同時考察一個應聘者的能力。同時問一些技術問題，考察應聘者解決技術問題的能力
二面的時候主要考察的項目經驗、團隊協作、IT知識方面的一些能力。一般不會涉及到具體問題的細節。同時還考察的應聘者未來的學習計劃等等。有點綜合實力考察的味道了。
三面一般很短，考察一些解決問題的能力和一些項目經驗（在我的印象中，人家不都說三面涉及到具體實質問題了么，比如說薪資啥的，咋還問我這些呢）。
個人感覺面試的時候不要慌張，把最真實的你展現給對方，如果有的問題真的沒有考慮到，那么就說你現在想不出來。如果你真的做過很多項目，再加上平時又很注重了解最新的IT知識，那么一般他們的問題都不會難倒你。
個人有一點想法，就是有些人幾年如一日的努力，找工作的時候就會很輕松。有些人只有在找工作的時候壓力才會很大。這些其實大家都明白，但是做到就很難。
帖一個好的找工作帖子
http://club.it.sohu.com/itmain.php?b=zz0049&c=69&a=51434
前天參加了校內百度招聘的筆試，應聘的職位是Web開發工程師
今天很多同學都收到了面試的通知，我沒收到，看來很有可能是被鄙視了，總結下經驗吧
1、看來當前Web 開發工程師大都注重考察Ajax的知識，尤其是有關XMLHttpRequest和瀏覽器相關這一塊，所以要是下一次應聘這個職位，我可是要好好準備一下的，還有有關JavaScript的一些內容，這些東西都在考察的范圍之內。
2、估計這次的失敗和我潦草的字體和卷面有關，看來以后不能把卷子當草稿紙用了，哈哈
3、要準備些有關正則表達式的知識
4、最好在筆試的時候帶自己的一份簡歷去，這樣很直接，而且考慮很周到
第一次沒經驗，是該好好總結下，就這樣吧，希望明天會更好
今天使用到Spring 驗證的模塊（Validator），稍微研究了一下，覺得不僅僅是書上講的那么簡單，在此總結下
介紹下Spring Validator 接口必須實現的方法
1、public boolean support(Class clazz);這個方法是要驗證提交表單時對應的那個緩存數據的類（通常由Hibernate生成），這通常由代碼編寫者設定，一般不會有錯
2、public void validate(Object target, Errors errors);注意，這里返回的反而不是boolean，這是因為Spring 在處理無法提交的表單使用的機制是例外機制，他會送出一個Errors，包裝了對應的信息。通常使用的方法是由類ValidationUtils 提供的，該類提供了驗證的幾個方法，并包裝了錯誤。這里包裝后的錯誤會出現在Controller 中的BindException
中，可以用getMessage() 方法來得到信息，不過這個信息很原始，可以利用適當的字符串處理機制處理一下。
其實這里有一個更好的方法，就是混合使用<spring:bind>標簽，這個標簽可以把對應提交的form 對象和表單中相關名稱的字段綁定，而且可以通過它的子屬性打印出錯誤信息例如你可以嵌入<c:out value="status.errorMessage" />這樣就會把該字段驗證時失敗的信息顯示出來，非常容易和好用，建議大家可以使用
當Validator 接口實現完畢后，要在配置servlet 的xml 文件中將對應的Controller 的validator 屬性設置為你的Validator 接口實現類，這樣，系統就會自動對你需要驗證的模塊進行驗證了。
如果你還想錦上添花的話，不但可以使用Spring MVC 的驗證機制，還可以用JavaScript 寫一段富客戶端的驗證機制
嗯，差不多了，就總結到此吧
一、快速的學習能力：短期內閱讀先進的技術書籍、文檔并能應用之
二、熟練運用工具、整合工具、利用工具改變現有工作，提高效率的能力
三、掌握信息獲取的方便途徑和方法：例如google、RSS、Blog等方式，可以讓你最快捷的解決問題
四、高效、具有創新力的團隊凝聚力，強的協作能力和管理能力
五、對于技術，尤其是新技術和其蘊含價值的敏感性
六、獨立思考、創新的能力
個人認為要完全滿足上述六條，不是一個很容易的過程，大致我的成長經歷告訴我應該分為如下三個階段
a、第一、二條是一個高級程序員應該具備的素質，絕大多數的人，現在都處以這個階段，甚至還沒有達到
b、第三、四條是一個優秀項目經理應該具備的條件，具有了一些管理的能力，并能及時跟進和解決問題
c、第五、六條是大師級別的能力了，對于技術的應用能發掘價值，能創造新的技術。這才是幾萬人中只能出現一個這樣的人才。
看來我的路還遠，嘻嘻，繼續努力吧
Spring Web MVC是Spring框架自帶的一個Web框架，它很好的結合了Spring本身的IoC和AOP的功能。是利用Spring開發Web系統的不二選擇。
最初使用這種框架，我設計系統時對數據庫的操作顯得有些拙劣，對應一個數據庫表的操作，我往往用多個Controller對應多個Service的模式，使其松耦合。但這樣層次不清晰，可復用模塊變差。導致系統很龐大，重復部分多，而且難于管理。
經過思考，結合重構的思想。我想到一個解決方案，這個解決方案是面向接口的，可以很方便的解決上述問題?；舅枷胧菍獢祿熘忻總€表，對其封裝成一個
Service，而這個Service實現了一些通用的接口方法，對應模塊的多個Controller都可以調用這個Service接口中的方法。這就把
Controller和Service從原來的緊耦合變成了松耦合的模式，增加了可復用性。