Jython和JRuby,以及Groovy:Java平臺的統一認識模型
當前,對于Python、Ruby 和Groovy的討論以及學習正如火如荼。很多愛好者出于各種目的都在積極地開發這3種語言的潛力。Python和Ruby也分別有Java的版本:Jython和JRuby,再加上Groovy,把一些軟件初學者,特別是初初弄軟件架構的人員搞得在他們這幾種語言中無從著手進行選擇,本文從面向方面程序設計、分析的角度,幫助初學者對目前很熱的這3種語言進行分類,以期這部分讀者能順利地解決對這3種語言的認識問題,同時也解決一些長期以來糾纏不清的理論問題。為了達到這個目的,我們從以下4個方面來進行敘述:
◆Python、Ruby和Groovy都是動態語言
◆元邏輯編程和面向方面的編程
◆Jython、JRuby和Groovy的語言層次分析
◆如何比較經濟地使用Python、Ruby和Groovy語言
一、Python、Ruby和Groovy都是動態語言
【動態語言】是指用該語言編寫的程序在運行時可以動態地改變程序定義的語言要素的層次結構或內部結構。比如,你可以在運行時用Ruby的反射機制或Groovy的元對象協議(MOP)完成下列編程:
例1:下面是一個Ruby腳本
- #Ruby 程序
- #alias_method:用來記錄被覆蓋的方法
- #define_method:重新定義一個方法,一般會調用alias_method保存的方法
- #class_eval: 根據傳入字符串的值,給類增加一個方法。
- def run_before(m)
- alias_method "__before__#{m}", m
- define_method(m) {|*arg| yield(*arg); send("__before__#{m}", *arg);}
- end
- class Test
- def run
- puts "hello, my run"
- end
- def self.log
- puts "before run"
- end
- end
- class Test
- run_before("run") {log}
- end
- test = Test.new
- test.run
例2:下面是一段Groovy腳本
- //Groovy程序
- package com.groovy;
- class MOPHandler {
- static void main(args) {
- def hndler = new MOPHandler()
- hndler.helloWorld()
- hndler.createUser("Joe", 18, new Date())
- hndler.name
- hndler.metaClass.toString()
- }
- def invokeMethod(String method, Object params) {
- println "MOPHandler was asked to invoke ${method}"
- if(params != null) {
- params.each{ println "\twith parameter ${it}" }
- }
- }
- def getProperty(String property) {
- if (property.equals("name")) {
- print "你用過 name 屬性\n"
- }
- println "MOPHandler was asked for property ${property}"
- }
- }
到這里我們必須提出一個比較嚴肅的問題:像上面我們看到的兩個程序一樣,這種反射式的編程和時下流行的“面向方面”的程序設計到底式什么樣的一個關系呢?
二、元邏輯編程和面向方面的編程
【元邏輯編程】通常是指利用語言本身的各種固有機制,特別是一些語言本身的背景機制進行編程的邏輯機制。比如,反射,又如作用于Java字節碼的一些開源工程項目(像ASM)等等。當你對Jython、JRuby 和 Groovy 的jar包進行分析后,你會發現下面的一張表格:
語言對比條目 |
Jython |
JRuby |
Groovy |
語言***版本 |
|
|
|
基本jar包 |
jython.jar 共計:1177KB |
asm- asm-commons- backport-util-concurrent.jar bsf.jar jline-0.9.91.jar jruby.jar 共計:2932030字節 |
groovy-all- 共計:2718KB |
字節碼處理 |
無 |
有 |
有 |
與Java的兼容性 |
稍低 |
中等 |
極高 |
元邏輯編程機制 |
有 |
有 |
有 |
開發者支持程度 |
人數少 |
人數中等 |
人數呈上升趨勢 |
掌握難度 |
及其容易 |
不易掌握 |
要懂Java |
Web開發框架慣例 |
無 |
Rails |
Grails |
可編譯特性(Java) |
可以 |
可以 |
可以 |
原生AOP支持 |
不支持 |
偏向于不支持 |
支持 |
這份簡單的表格為我們提供了很多有用的信息,在這里我們主要關注——這3種語言的“元邏輯編程”和“面向方面編程(AOP)”兩項內容。
首先我們要清楚元邏輯編程并不是AOP,當前很多的開發者將元邏輯編程和AOP混淆了起來,比如,上面例子1中有些開發者就將它認為是AOP的例子,這里我們來澄清一下相關認識:
1、AOP本身強調的是:連接點、切點、通知以及方面,并且AOP很在乎由這些AOP編程機制帶來的類層次結構的改變。這一點對于無論你用的是靜態織機還是動態織機都一樣。
2、我們不能把類似Java的動態代理機制就認為是AOP的本真編程,比如,例子2中這個Groovy的程序由一個子句: new MOPHandler() 就沒有被元對象協議捕捉。
因此,我們說:雖然面向方面的分析與設計是帶來軟件革命的一項已經不算新的技術了,但請不要把稍微動態化一點的程序都冠以AOP的標簽,這有助于我們把握技術的前沿方向。所以,在這里由必要向開發界提出元程序邏輯和【AOP本真編程】的概念。我們把應用了【連接點】、【切點】、【通知】以及【方面】的程序設計叫做AOP本真編程或【原生AOP編程】,而以此同元邏輯編程相區別,把AOP本真編程以下的動態化編程稱為元邏輯編程。
三、Python、Ruby和Groovy的語言層次分析
對它們三者的語言層次分析有助于我們把握他們的某些實質。很多開發者都有一個共同認識就是:很難在這三者中做出選擇主要用何種語言進行24小時的開發。這里我們試圖幫助你做出選擇。
其實只要我們以面向方面的程序設計作為未來發展方向的話,一切問題就可以迎刃而解。我們在上的表格中看到,Jython沒有原生的AOP支持,JRuby傾向于不支持原生AOP編程,Groovy的元對象協議就是AOP的制作。說JRuby傾向于不支持AOP是由于在制作JRuby的過程中,ASM的字節碼修改主要是為了Ruby的語法,而不是向Groovy一樣使語言本身具有AOP的功能。于是我們可以用下列圖示表示Jython和JRuby以及Groovy的層次關系:
從圖中我們可以看到,在Java平臺之上,Jython和JRuby作為不具備原生AOP功能基本處于同一層次,而Groovy從原生AOP功能上說比Jython和JRuby都強。
四、如何比較經濟地使用Python、Ruby和Groovy語言
沒有任何一種語言可以徹底地取代另外一種或是所有的語言。因此無論Jython、JRuby和Groovy在AOP的未來功能上如何發展,你都必須對他們進行學習。但是,什么時候該用什么語言進行開發呢?我們來試著總結性回答這個問題。
1、從軟件工程的角度上講,Jython是最節省成本的選擇,JRuby次之,而Groovy雖然也很簡單但深入一點的開發其實還是較為困難的;
2、從個人學習的角度上講,可能有很多人處于Rails的原因會偏愛JRuby,也有一些開發者由于Groovy和Java的無縫集成而使用Groovy,然而大家需要知道的是,在這3種語言中其實個人可能會覺得JRuby非常不容易掌握;
3、從團隊學習和應用的角度講,Jython和Groovy是簡單的,而JRuby是較為困難的;
4、這3種語言都可以進一步結合Java的字節碼處理技術,進一步完成AOP的功能,在這個時候,Jython將碰到的技術問題最多,JRuby次之,而Groovy將碰到的技術問題可能沒有。
在Jython、JRuby和Groovy的應用開發上,但愿本文起到拋磚引玉的作用。
【編輯推薦】