CowNew開源團隊

爪哇國家里福洲有個農民湯木，聽說聯邦政府在東南部的佛落里洲建設特別區，需要大批勞力。吃不上飯的湯先生就打算去那里混飯吃了。
到了佛落里洲之后，才知道這里竟然在洲政府序列里有個綁架局。綁架局是干什么的呢？
首先，向湯木一類的來自外洲的人收取費用，頒發《免綁架證》，費用高昂，有效期一年。但是，有了《免綁架證》后，還不能免于被綁架，還必須在敲詐局辦理《免綁架證承認證》、在勒索局辦理《免綁架證生效證》及在無事生非局辦理《免綁架證防偽卡》，簡稱“三證一卡”，此外，女性還必須在性別歧視局辦理《女性免綁架證附加證》等許多證件，并且保證說，有了這么多證后，在大街上就不會被政府綁架，還威脅到，沒有這么多證的話，或者雖然有卻沒有帶的話，以“無證卡人”的理由予以綁架勒贖。而且，去贖人的人如果沒有這么多證，也可能被綁架。至于是否有聯邦政府頒發的《公民資格證》倒不重要。
湯木嚇壞了，為了在這里混下去，賣血辦了這么多證，并且隨身帶在身上，以為就不會被綁架了。
可是湯木想錯了。
這一天，湯木走在大街上，不幸遇到了查《免綁架證》的人員。前面已經有許多人因為沒有《免綁架證》或者沒有《免綁架證承認證》、《免綁架證生效證》及《免綁架證防偽卡》和《女性免綁架證附加證》等被綁架了！湯木正想著，我的證件齊了，不會被綁架了，所以沒有害怕，依然向前走。
戴著綠色帽子的綁架官粗魯地問湯木：“北佬，有《免綁架證》嗎？”
湯木不敢跟他計較禮貌，趕緊說：“我有。”
綁架官繼續問：“三證一卡呢？”“都有。”
“拿出來看看。”
湯木趕快拿出來了。
想不到綁架官拿過去看也不看，撕成碎片一扔。然后揚長而去。
這時另一個綁架官問湯木：“你有《免綁架證》嗎？”
湯木說：“被他撕了。”
“不要狡辯！來人，這個北佬沒有《免綁架證》，馬上綁了！”
湯木渾身是嘴也說不清了。到了天邊，也可以說那天湯木根本沒有帶《免綁架證》，所以，綁架湯木是完全正確的。

   今天我通過為JVM增加“-Dorg.apache.tapestry.disable-caching=true -Dorg.apache.tapestry.enable-reset-service=true”啟動參數的方式啟用了tapestry的非緩存模式以提高開發時的效率，但是在運行的時候發現以前正常工作的頁面出現了錯誤，跟蹤調試以后發現所有的頁面成員變量都為null了。經過分析才發現自己以前對tapestry的一個超大誤解，也避免了程序投入使用以后造成更大的問題。
因為有一些屬性是只有運行期意義的，對用戶沒有意義，所以我的程序中原有的java的set/get方法沒有與頁面中的組件綁定，因為我誤認為tapestry會替我在請求之間保存這些變量值，我也曾為此懷疑tapestry是否會因此而造成內存占用過大的問題。
   tapestry的頁面java文件默認是會被緩存的，當這個頁面對象服務完一個請求以后會被放回池中供下一個請求使用。由于一開始的開發的時候我沒有啟動非緩存模式，這樣當我再次對頁面進行操作而造成頁面刷新后，tapestry把上次為我服務的頁面對象又拿給我了，這樣在我看來那些頁面中的變量好像是被保存了一樣。當我打開非緩存模式以后，每次請求完成后，tapestry都會把變量值清空，這樣就會造成上面的問題了，這樣也就暴露問題了。
   因此在使用tapestry的時候一定要將需要在頁面之間保存的變量放到session中或者保存在頁面的hidden字段中，否則很容易出現bug。為了提早發現bug，建議在detach方法中將所有的變量賦值為null。

   在開發程序的時候熱加載是非常有幫助的，這能大大簡化我們開發調試的速度。在使用tapestry開發的時候，只要是啟動了調試模式，那么代碼的熱替換是自動被JVM支持的，也就是只要我們的tapestry運行在調試模式下，就可以實現java代碼的即時修改即時生效。但是tapestry的頁面文件（.page和.html模板）默認是無法實現熱加載的，每次修改頁面都必須重啟服務器，大大降低了開發速度。其實解決這個問題只要增加虛擬機參數就可以了，只要在虛擬機參數（注意不是應用參數）中加入：-Dorg.apache.tapestry.enable-reset-service=true -Dorg.apache.tapestry.disable-caching=true即可。這樣每次修改的時候tapestry就不會去緩存中取了，其中org.apache.tapestry.enable-reset-service的意思是：If not specified as "true", then the reset service will be non-functional. The reset service is used to force the running Tapestry application to discard all cached data (including templates, specifications, pooled objects and more). This must be explicitly enabled, and should only be used in development (in production, it is too easily exploited as a denial of service attack).

Unlike most other configuration values, this must be specified as a JVM system property.

 批量系統原有的頁面定時刷新的實現是不太合理的，以RealtimeBatchRunningOfCountwf為例：
 首先在RealtimeBatchRunningOfCountwf.page中定義了屬性refreshUrl：<property-specification name="refreshUrl" type="java.lang.String"/>，RealtimeBatchRunningOfCountwf.html中將refreshUrl插入head部分。實現的重點在RealtimeBatchRunningOfCountwf.java中，getRefreshUrl方法返回httpmeta頭，在這個頭信息中定義了刷新時間和要刷新到的頁面的url:
 public String getRefreshUrl() {
  String t_intervalTime = getIntervalTime();
  if (t_intervalTime == null) {
   t_intervalTime = getRequestCycle().getRequestContext()
   .getParameter("intervalTime");
  }
  if (t_intervalTime == null || t_intervalTime.equals("")) {
   return "";
  }
  String url = "";
  
  try{
   url = "<meta http-equiv=\"Refresh\" content=\""
    + t_intervalTime
    + "; URL="
    + getRequestCycle().getRequestContext().getAbsoluteURL(
    "batch-server/app?service=page/RealtimeBatchCountwf")
    + "&gappid=" + getGappid() + "&gfuncid=" + getGfuncid() + "&intervalTime=" + t_intervalTime
    + "&agentzoneno=" + getAgentzoneno()
    + "\"/>";
  } catch(Exception e){
   setMessage(e.getMessage());
   return "";
  }
  return url;
 }
 可以看到getRefreshUrl的實現是非常復雜的，由于TapeStry的頁面模型是比較復雜的，其中的變量都是通過頁面模型來儲存的，如果只是簡單的刷新頁面，會造成這些頁面變量錯誤，因此在getRefreshUrl方法中將所有的變量拼接到url中，這樣在頁面的getGappid、getAgentzoneno等方法中首先判斷頁面請求（getRequestContext）中是否有此頁面變量，如果有則取頁面請求中的，否則再去取本對象中的變量值。這樣看起來getGappid、getAgentzoneno、getRefreshUrl等方法都非常復雜，一旦頁面中增加新的屬性就需要去修改getRefreshUrl方法，而且這樣造成視圖（View）的邏輯混雜到了模型（Model）中，違反了MVC的隔離原則，最重要的是這樣做違背了Tapestry頁面模型設計的原意。因此我做了一個新的實現方法，可以參考BatchTaskContrlwf:
 首先仍然是在BatchTaskContrlwf.java中定義getIntervalTime方法：
 public String getIntervalTime()
 {
  if (intervalTime == null)
  {
   intervalTime = "60";
  }
  setMessage("數據每 " + intervalTime + " 秒更新一次,更新的速度可以在左上角更改");
  return intervalTime;
 }
 getIntervalTime比以前的實現簡單了。BatchTaskContrlwf.java中也沒有了getRefreshUrl方法，這樣保持了視圖與模型的獨立性。
 在BatchTaskContrlwf.html中body的開頭增加如下的javascript：
<script>
 //intervalTime表示秒，但是在setTimeout中的單位是毫秒，所以在后邊加三個零
 window.setTimeout("RefreshPage()",<span jwcid="@InsertText" value="ognl:intervalTime"></span>000);
 function RefreshPage()
 {  
  document.getElementById("imgRefresh").click();
 }
</script>
 這里調用定時器實現每隔intervalTime秒就調用一次RefreshPage方法，在RefreshPage方法中則去模擬點擊imgRefresh控件，這樣就可以達到刷新頁面的目的了。imgRefresh是為“刷新”這個圖形按鈕增加的id屬性，因為圖形按鈕默認是只有name屬性的，而且name屬性生成的也是隨機的，所以為“刷新”按鈕增加id屬性：
<img jwcid="@ImageSubmit" id="imgRefresh" hspace="20" align="middle" image="ognl:assets.refreshImage" listener="ognl:listeners.refreshAction"/>
 這樣就可以在RefreshPage方法中輕松的取得此控件了。
 在RefreshPage方法中也使用getElementById這個技巧，因為Tapestry生成的html中的表單的名稱也是不可測的，目前的名稱是“$Form0”，但是這個名稱是不保障的，如果我們在RefreshPage方法中使用document.$Form0.$ImageSubmit.click()方式刷新頁面的話，很有可能在Tapestr實現機制改變或者在頁面中加入了新的表單元素后造成代碼錯誤。而getElementById則可以直接根據控件id來定位控件，大大提高了代碼的靈活性。
注：上邊的文章是我對公司原有產品進行重構的時候發的一篇文章，涉及到了公司的一些私有概念，非公司的人可能讀部分章節起來有點費勁，請諒解。如果以后有時間我會整理成通用的文檔的。

1、開發工作進行到比較后期時，會進入一個“視覺凍結”階段，也就是界面固定不動，這樣做的目的是讓使用手冊等文件能夠定稿。
2、電子郵件讓我們工作時不被電話打擾，開發人員彼此之間的討論主要通過電子郵件，只有必要時才開會。
3、領導者的任務是努力消除程序員工作上的一切障礙，讓程序員能全力專注于產品開發，而非寫報告、開會。
4、如果你要準備向上級報告項目概況，非得要所有的程序員停下手邊的工作，為每個程序寫一份摘要嗎？這是leader的工作。有太多的Leader

在不該授權的時候授權，讓組員為了與產品無關的事情疲于奔命，導致進度停滯不前。
5、我寫文章的時候，從不使用電腦，而是使用紙筆來寫作，然后再錄入計算機。因為使用計算機的時候，每寫完一句就忍不住要編輯以前寫稿

的東西，這樣造成進度過慢，太分心于修改上，忘記了寫作內容才是本旨。
6、微軟曾經有幾位主管，每次遇到項目進度不順利，就把組員叫出來罵。這種責罵只會激起組員心中的憤怒。
7、用看程序的方式找錯，是無效率的方法，用debugger來找bug才是最快最方便的，觀察各變量在程序執行過程中的變化，是非常有效的方法

，絕對不要用猜或者用看的辦法來找錯。
8、這樣做對產品有沒有幫助？對于目標的完成有沒有策略上的價值？這樣做是否會使我忽略了更重要的事情？
9、不要把會議時間定在上午10點或者下午3點，這樣會把上午或者下午的時間切割的太零碎，最好排在一清早或者快下班之前。
10、不要讓程序員的學習停滯不前，要讓他們有機會磨練不同領域的技術，培養復合型人才。
11、不要舍不得放您最優秀的程序員到別的項目去。如果他在您的項目中已經沒有新的東西科學，為了公司和他個人的前途，您應該把他推薦

到別的項目，讓他的成長永不間斷。
12、加班本身就是一個危險的訊號，明確告訴你一定有什么地方出現了問題。

此版本更新了在Eclipse3.1下無法使用的問題，目前已經能夠在Eclipse3.2、Eclipse3.1下運行。
下載地址：http://www.cownew.com/download/

from http://blogs.huihoo.com
1. 確保固定的發布周期，短一些。最好每月一個 milestone版，半年一個final版。人手不夠？步子可以邁小一點；變化？把部分feature推遲到下一版……無論如何，版本發布的頻率節奏一定要穩定，周期要短。這是很多成功的開源項目的經驗，也是Agile最重要的原則之一。
2. 建立一個子項目，專門用于集成實用的示范應用，演示JFox推薦的體系結構、設計模式用法。這些示范應用必須是實際的完整的解決方案，而不是Hello World式的Demo。用戶可以在此基礎上修改擴充，形成自己的系統。Pragmatic的開發框架對推廣很重要。

首先自我介紹：我是鄭重，南京人，Java程序員，現在巴黎一個小IT公司任職，做J2EE編程，主要做servlet/JSP，CMS和portal。應龍輝之邀加入huihoo社區。
言歸正傳。我算是關注huihoo的一員。所謂關注，首先要知道的一個問題就是，huihoo是什么。網站上說huihoo是Open Enterprise Foundation，它自己也有一些項目，比如JFox，這樣看來，huihoo很象一個類似Apache或者Codehaus的一個組織。 Huihoo還擁有一個技術論壇，這樣又有點象The Server Side。龍輝還有建立自己的forge的打算，如果forge真的建立起來了，huihoo又有了點sourceforge或者objectweb的模樣。但其實，Apache，The Server Side和sourceforge是完全不同的三個東東，那么huihoo到底是什么？
我個人傾向于把huihoo看成是一個Open Source Foundation。原因如下：
先說技術論壇。我覺得國內沒有必要再存在一個Java技術論壇。最權威的Java技術論壇，堪稱Sun的Java Forum，The Server Side和Java World。國內也有一些有知名度的論壇，比如CSDN，比如China Java World，比如java-cn，所以我覺得技術論壇已經夠多了。而且技術論壇的靈魂是人氣，不是技術本身。國內那些論壇，統統好像菜場，到處充斥著關于 CLASSPATH如何設置之類的問題，這些問題雖然低級，但卻正是一個技術論壇所需要的：不停的有人問問題，有人回答問題，論壇的人氣就起來了，至于問題本身是什么，卻不那么重要。你要去國內那些論壇問castor怎么用，問xmlbeans怎么用，肯定問津者鮮。我想，一個這樣的技術論壇，應該不是 huihoo所需要的。Huihoo不是一個Java初學者俱樂部。
然后說forge。一個forge，本質上是一個服務提供者，所以最重要的是提供的服務是否可靠，是否穩定。Huihoo不是財大氣粗的地主，弄個服務器來為別人提供CVS和問題跟蹤系統，這樣的負荷huihoo肯定受不了。而且，即使能弄來一個這樣的服務器，為什么別人不選擇sourceforge而選擇huihoo？再而且，我覺得項目不貴多而貴精。我三天一個想法，如果用huihoo做forge，一個月我就能注冊10個項目，可這10個項目，我能堅持到底的能有一個就不錯了。成千上萬個半途而廢的項目也比不上一個好項目。爛尾的項目太多，反而壞了名聲。
最后是開放原代碼基金會。做好一個基金會，關鍵是有一個或者n個有技術有激情并能堅持不懈的團隊，和一個或者n個優秀的項目，這也很象目前huihoo的發展模式。如果huihoo意在成為一個這樣的組織，那么我覺得forum也好，forge也好，都好比闌尾，有了是個累贅，遲早要卸載掉，所以干脆不用。看看apache和codehaus，都沒有自己的forum和forge。為什么沒有？因為沒有必要。
在上面所說的基礎上，再談談huihoo的項目。我看了看huihoo網站上列出的一些項目，一個普遍的問題是，似乎堅持下去的不多。很多的項目，最后更新時間都是去年，而今年都快結束了。Java技術日新月異，如果一個Java項目停滯一年沒有進展，基本就可以進回收站了。所以，我覺得huihoo應該把它的成員組織好，把它的項目精簡一下，然后好好進行開發。
開始一個項目，首先要問的一個問題是，為什么需要做這樣的項目。Unix下的 bash，全稱是but another shell。為什么大家不用原來的shell，卻要用這個bash，but這個單詞，很有講究。因為bash提供了shell所不具有的新特性，所以需要這樣的but another。做任何一個項目，都一樣。
不客套了，直接拿JFox開刀。J2EE服務器，市場上已經有很多了，比如 JBoss，比如JONAS，比如Apache的Geronimo。為什么還需要JFox？這個問題，我沒有和列位JFox團隊的成員探討過，JFox的主頁上也沒有找到，所以并不清楚。Apache的Geronimo，開始的時間不久，但主頁上明確說明了為什么在大家有JBoss和JONAS可以選擇的時候啟動Geronimo：因為license的問題，Apache希望創建一個在Apache License 2.0之下的開源J2EE服務器。那么，JFox的理由是什么？
做開放源代碼的項目，關鍵是有人愿意使用。開放源代碼，讓程序員不能從中獲得物質上的所得，那么開發的動力來自哪里？我個人認為，一部分來自于理想，一部分來自于別人的認可，兩者缺一不可。一個沒有人使用的項目，就得不到別人的認可，就難以為繼，即使各位是多么的理想主義。而且，優秀的項目，不是閉門造車的成果，而是無數次的反饋和回應反饋的迭代。沒有人使用，就沒有反饋，就創造不出優秀的項目，這恐怕也是對理想的一個打擊。
我看到JoyAOP，看到Willow，都有同樣的疑問：我為什么要選擇huihoo 的項目，而不是Spring AOP或者aspectJ，不是ObjectWeb的Enhydra？Huihoo需要有自己的項目，每個項目都應該有自己存在的理由。沒有存在理由的項目，為什么要存在？
先說這么多。我想，每一個關注huihoo的人，或多或少都會有類似我的想法。要把huihoo建設好，需要直面這些問題。雖然我心存疑問，但我對huihoo是有希望的，因為huihoo有靈魂，那就是它的成員。措辭直接，不夠委婉，還望見諒。
from http://blogs.huihoo.com

朋友銀狐999寫得一篇blog，他說出了 Huihoo 目前的一些現狀，貼出來與大家分享，希望對大家能有所啟發。
Allen，huihoo的創始人之一，這幾年一直用自己的熱情和努力，來支撐著huihoo的發展。
huihoo，國內著名的開源社團，創造了諸如JFox Server,JFoxAOP,JFoxSOAF,JFoxMX,JFoxMQ等不錯的一些開源組件。
這幾天Allen來到了北京，趁著今天周六，晚上大家聚了聚：Allen（龍輝），Peter（程勇），Orbat（楊永），梁震宇，以及我（胡長城，銀狐999）。
Allen依然對開源充滿信心，也依然在為創造一個開源神話而努力：他希望基于開源為大家提供產品和服務，利用服務來創造盈利。—— Allen很執著，也堅定著這個方向。
我們很理解Allen的夢想，但是也不得不承認現實就是現實。
huihoo是國內最值得推崇的開源團體，也創造了諸如JFox Server,JFoxAOP,JFoxSOAF,JFoxMX,JFoxMQ等不錯的一些開源組件。然而，曾經的熱血小伙子們，如今正在為“房子”，為 “自主創業”等等事情所困擾，JFox的研發越來越緩慢了。
huihoo的網站上，google的廣告越來越多了，沒有辦法，Allen只能依靠這有限的廣告收入來維護huihoo網站的運營，甚至這兩年多來，Allen利用提供咨詢和培訓的收入來維持huihoo的網站。
在Allen眼中，國內開源的市場，應該能夠托起huihoo這艘大船。然而這艘船越來越沉，船上的水手也越來越疲憊。這艘大船航行在一望無際的海洋 上，充滿熱情和激情的Allen，面對著一張可能有寶藏的圖紙，卻苦于沒有一個指南針：風帆依然在揚起，帆布卻逐漸在被撕碎······
我們很佩服Allen的執著，但是我們也實在不忍心說一些打擊Allen的話，但是我們心里都明白，Allen這個夢想，也許真的僅僅只是一個夢。這個 夢還要沉睡多久，我們誰也說不清，但是我們都希望，某一天，這個夢醒來，一切晴空萬里，面對著遠方，我們這些水手，可以高喊：瞧，就在那里。
謝謝 銀狐999 對 Huihoo 和我的鼓勵與支持，我們會堅定不移地繼續走下去。
from http://blogs.huihoo.com

由于工作需要，今天看了看Groovy，下面是學習過程的學習筆記：
基本原則：Java完全可以調用Groovy寫好的類；Groovy完全可以調用Java寫好的類；即使不使用Groovy的特有的語法，可以使用Java中的絕大部分傳統寫法。
1 如果使用 groovy.lang.*,grooby.util.*,java.lang.*,java.util.*,java.net.*中的類的時候無需import。
2、支持assert，比如assert 1==1,assert(true)
更高級的用法：assert('text'.3<<'hello').size==4*3+5
3、groovy支持弱類型聲明def x=1
4、GroovyBean
class Book
{
   String title;//聲明的是屬性，而非字段
}
def g = new Book()
print g.title
print g.getTitle()
5 groovy中的==表示等于（equality），而非同一（identity），這與java不同。
6 def nick = 'Gina'
def book = 'Groovy'
assert '$nick is $book' = 'Gina is Groovy'
7 使用正則判斷字符串匹配：assert '12345'=~/\d+/
8 groovy中可以直接對Integer類型使用四則運算，可以對int類型調用toString方法。
9 使用list：
def r =['a','b','c']
assert r[0]='a'
assert r.size()==9
使用map:
def http=[100:"cont",200:'ok']
assert http[200]=='ok'
http[800]='what?'
使用ranges：
def x=1..10
assert x.contains(5)
10 閉包：
（1）[1,2,3].each{entry->println entry}
（2）累加計算：其中upto表示從1遍歷到10
def  counter=0
1.upto(10)
{
   number->
   counter = counter+number
}
println counter
11 動態執行：evaluate('1+2') 會打印出3
12 groovy中類型可以弱類型聲明，也可以強類型聲明，并且聲明的時候會自動進行boxing，比如def a=1是可以的，int a=1也是可以的，而且第二種用法中聲明的a是Integer類型的。
13 Groovy支持運算符重載，其實現方式和python類似，也就是類只要實現某個方法即可實現運算符重載，下面是運算符和對應方法：+ plus；- minus；* multiply；/ div;% mod;++ next;-- previous;** power;| or;& and;^ xor;~ negate;a[b] a.getAt(b);a[b] = c a.putAt(b,c);a<<b a.leftShift(b);a>>b a.rightShift(b);a>>>b a rightShiftUnsigned(b);
switch(a){case b:} b.isCase(a);a==b a.equals(b);
a<=>b a.compareTo(b);
a>b a.compareTo(b)>0;
a>=b a.compareTo(b)>=0;
a<b a.compareTo(b)<0;
a<=b a.compareTo(b)<=0;
a as type a.asType(typeClass)
14 字符串操作：
g="Hello Grooby!"
assert g[6..11] == 'Groovy'
assert g.count('0')==3
assert 'x'.padLeft(3)=='  x'
assert 'x'.padRight(3,'_')=='x__'
assert 'x'.center(3)==' x '
assert 'x'*3=='xxx'
15 字符串的LeftShift和切片的應用
g='Hello'
g<<' Groovy'
assert g instanceof java.lang.StringBuffer
g<<'!'
assert g.toString()=='Hello Groovy!'
g[1..4] = 'i'//替換ello為i，切片的典型應用
assert g.toString()=='Hi Grooby!'
list等collection類型同樣支持切片
16 數字的方法：
def s = ''
10.times{s+='x'}
10.downto(0){x+='d'}
s=''
0.step(0.5,0.1){number->
s+=number+' '
}
assert s=='0 0.1 0.2 0.3 0.4'
17 List的常見操作
assert [1,[2,3]].flattern()==[1,2,3]//扁平化
assert [1,2,3].intersect([4,3,1])==[3,1]//交集
assert [1,2,3].disjoint([4.5,6])
list = [1,2,3]
assert list.pop()==3//像使用堆棧一樣
assert [3,1,2].sort()==[1,2,3]
assert [1]==[1,1,1].unique()//去掉重復元素

def list=[1,2,3]
assert list.count(2)==1
assert list.max()==3
assert list.min()==1
def even = list.find{item->
 item%2==0
}
assert even ==2
assert list.every{item->
 item<5
}//所有的都小于5
assert list.any{item->
 item<2
}//任何一個小于5
list.reverseEach{item->
 store+=item
}//反向遍歷

assert [1,2,3].join('-')=='1-2-3'
for(i in [1,2,3])
{
   println i
}
18 文件處理：
new File('a.txt').eachLine{println it}
19 groovy中xml處理非常簡單，可以參考blogjava上的一篇名為“Groovy高效編程——生成XML文件”的文章。
20 Groovy中使用Swing構建界面：
import grooby.swing.SwingBuilder

swing = new SwingBuilder()
frame = swing.frame(titile:'Demo'){
  menuBar{
    menu('File'){
        menuItem 'New'
        menuItem 'Open'
    }
  }
  panle{
    label 'Label my'
    slider()
    comboBox(items:['1','2','3'])
  }
}
frame.pack()
frame.show()
21 groovy中簡化了jdbc訪問數據庫的方法，提供了execute、eachRow等方法，無需開發人員關心關閉連接等問題。
22 java中運行grooby腳本的方法：
GroovyShell shell = new GroovyShell()
Object result = shell.evaluate("12+23")
23 Groovy解析引擎的類為GroovyScriptEngine
def engine = new GroovyScriptEngine(".")
def value = engine.run("test/MyScript.grooby",new Binding())