摘要: Groovy 是一種利用其他語言（如 Ruby、Jython 和 Smalltalk）中的特性的動態語言。Groovy 在 Java VM 上運行，并使任何現有的 Java 對象（以及所有 API）可用于 Groovy。Groovy 當前遵循 JSR-241 中的標準；您可以在 Groovy 網站及其項目主管 (Guillaume Laforge) 的網志中了解有關該語言的詳細信息。
Grails 之于 Groovy 相當于 Ruby on Rails 之于 Ruby。（該名稱最初為“Groovy On Rails”，現在已改為“Grails”以避免混淆/競爭。）與 Ruby on Rails 一樣，Grails 用于創建 CRUD（創建、讀取、更新、刪除）Web 應用程序。您可以在 Grails 網站及其項目主管 (Graeme Rocher) 的網志中了解有關 Grail 的詳細信息。
閱讀全文
摘要: Groovy 的 Eclipse 插件能夠編輯，編譯以及運行 groovy 腳本和類
閱讀全文
摘要: 經典大片，國人驕傲，不容錯過！
閱讀全文
摘要: 今天我無意間看到了一個Grails與RoR(Ruby on Rails)的性能比較，覺得有必要與各位還不了解Grails的朋友分享一下，以消除對Grails的神秘感甚至誤解：
閱讀全文
摘要: Groovy: The Sleeping Giant
閱讀全文
摘要: Groovy輕松入門系列教程之Grails實戰基礎篇，高效開發不是夢！
閱讀全文
摘要:
閱讀全文
摘要: 多次轉載，鏈接與題目均已丟失，無法注明，向原作者致歉！
聞者傷心，見者流淚～
閱讀全文
摘要: Groovy輕松入門系列教程之搭建Groovy開發環境
閱讀全文
摘要: 將Spring2.0.2升級至2.0.3須謹慎！
閱讀全文
摘要: 2007年Groovy好事連連，不容錯過！
閱讀全文
摘要: 通過比較Groovy與Java的不同點和相同點，快速掌握Groovy :-)
閱讀全文
摘要: 讓我們來回顧一下主流語言的發展歷程：機器語言(由01組成) -> 匯編語言 -> ... -> C語言 -> C++ -> Java -> ?
不知道大家有沒有發現在語言發展過程中，存在這么一個規律：
閱讀全文
摘要: Groovy高效編程之統計單詞頻率，展現Groovy的魅力 :-)
閱讀全文
摘要: 想必關注Java的朋友不會沒有聽說過Groovy吧？的確，由于Groovy的語法與Java極其相近，所以對于我們這群Java狂熱分子特別友好。Groovy對于有Java基礎的朋友來說，幾乎可以說是唾手可得！
閱讀全文
Ruby的語法可以借鑒，但其本身的實現就免了
說Ruby是一種沒有光明前途的語言的原因：
Ruby的Thread是偽線程,不管代碼中寫了多少個Thread.new,Ruby都只啟動了一個線程去運行這些Thread的代碼。
這樣做的確使得Ruby的Thread很容易控制，程序也不容易產生類似死鎖這類嚴重的線程問題。但是效率始終無法提高，因為在ruby進程中，實際上只有一個真實的線程在運行，同樣的代碼在那么多核或者多cpu的電腦上運行效率和單核cpu的電腦上的效率并不會相差多少。
你目前在工作站上用的CPU時鐘速度是多少？10GHz么？ 2001年8月Intel芯片就達到2GHz，按照2003年前的CPU發展趨勢推算，到2005年初，我們就能擁有第一塊10GHz的Pentium芯片。但實際上沒辦到。而且情況好像越來越糟——我們根本就不知道到底在什么時候這樣的芯片可以出現。
那么放低期望，4GHz又如何呢？目前我們已到3.4GHz——那么4GHz已經不遠了吧？唉，好像4GHz也遙不可及。可能你知道，Intel首先于2004年中將4GHz芯片的發布時間推遲到2005年，而到了2004年秋季，則徹底取消了4GHz計劃[譯注11]。在本文寫作的同時，Intel宣布計劃到2005年早期，實現到3.73GHz（即圖中的右上最高處）的微量提升。所以，至少就目前來說，時鐘速度的競賽實際上結束了，Intel和其他大多數處理器廠商將把旺盛的精力投入到多核等方向去。
也許，我們某天在主流PC里能裝上4GHz的CPU，但2005年別想。Intel實驗室里的確已經有運行在更高速度的芯片——不過代價是驚人的，比如龐大數量的冷卻裝置。你想不久在你的辦公室里就有這樣的冷卻設備，坐飛機的時候，就把它們放在你膝蓋上？別做夢了！
如果應用程序想充分利用CPU吞吐增加量，那它們就必然日益需要并發，這種形勢逐漸明朗，并將在接下來的數年里深入發展。Intel已經揚言未來他們會推出集成100顆內核的芯片，那么單線程應用最多就只能利用這種芯片1/100的潛在生產力。“哦，性能沒那么重要吧，計算機總是跑得越來越快”的論調已經變得天真而可疑，甚至在未來不久將完全錯誤。
總結一下我的觀點：
CPU性能提升途徑主要是靠實現多核，靠提高主頻是沒有多大希望了，而單線程僅僅能利用單核資源，嚴重浪費了多核CPU提供的性能，不幸的是，Ruby的線程是偽線程，即始終僅有一個線程在執行，隨著軟件的日益龐大，Ruby將不得不求助于CPU主頻的提升，但像前面所說的那樣，4G都是一個遙不可及的目標，別提10G甚至更高了。我堅信，RoR終有一天不堪重負，被Java擊潰！?
摘要: 迅雷一道算法題的解答 :-)
閱讀全文
???????
每個問題有很多種解法，但其中存在一種最優的算法，據我觀察和思考，‘懶人’是寫不出那種最優算法的，為什么呢？因為最優算法有一個很明顯的特點就是算法本身集結了人類的聰明才智，讓我來用一個實例來證明這個觀點：問題：
請計算當參數為 n(n很大) 時, 1-2+3-4+5-6+7+......+n 的值
‘懶人’解法：
public class Lazy {
? public static void main(String[] args) {
??? int n = 10000;
??? int result = 0;
??? for (int i = 0, flag = 1; i < n; i++) {
????? result += flag * (i + 1);
????? flag =?-flag;
??? }
??? System.out.println(result);
? }
}
‘勤人’解法：
public class Diligent {
? public static void main(String[] args) {
??? int n = 10000;
??? int result = 0;
??? if (0 == n % 2) {
????? result = -n / 2;
??? } else {
????? result = -n / 2 + n;?
//由于-n / 2會舍棄小數部分，所以無需寫成-(n - 1) / 2
??? }
??? System.out.println(result);
? }
}
人類的智慧為計算機擔負了不少的計算量，“懶人”算法的時間復雜度為O(n)，而“勤人”算法的時間復雜度僅為O(1)，這題的最優算法出世了！
忠告各位喜愛編程的朋友，在解決問題之前，請可憐可憐您使用的那臺精疲力盡的計算機吧，花些時間思考一下，您付出的一分一秒都會有回報的 :-)
摘要: 如果您對選擇Ruby還是Python猶豫不決的話，這篇文章很適合您 :-)
如果想找一種能與Java真正無縫結合的動態語言，我吐血推薦Groovy ( http://groovy.codehaus.org )，JVM上的JCP官方標準語言。
閱讀全文
摘要: 小弟關注Groovy已有數月(您可以到Groovy官方網站 http://groovy.codehaus.org 下載)，發現其極具魅力，故在我參加的學校'創新試驗項目'中，就用它來實現最簡易的ORM，做的非常簡單，主要原因是沒有時間，因為小弟學業繁重，所以抽出一個下午的時間來實現一個簡易版的ORM，數據庫用的是MySQL。現在簡單說明一下所示代碼，將User類的一個實例通過save方法保存到數據庫中，然后再根據給定條件通過findBy方法從數據庫中取出實例，最后刪除一個特定實例。由于深知通過XML文件進行配置的痛苦，所以在設計時沒有用到任何XML文件。此程序讓程序員只需關注自己要處理的對象，而不用關心數據庫方面的東西，簡化開發過程。最后我想說明的是，由于時間問題，所以編碼方面只注重算法的體現，沒有考慮其他方面。下面給出的代碼僅供演示及參考(源碼已經上傳，點擊下載)：
閱讀全文