Software Cinema

James Gosling 在 Java One 2008 的一個 Q&A Session 內容現在可以利用 MP3 下載聽了. 不過我覺得大多問題其實沒有很深入地回答, 本來看到網頁上寫到 java.net 的未來還蠻有興趣的, 以為會跟 SOA 有很強的關聯, 不過就我聽到的內容, 似乎也是輕輕帶過而已.

大概有以下重點 ( 邊聽邊隨便打打, 內容文法可能...ㄜ, 語句應該也不是很連貫, 重點節錄, 跟 Java 關係不大的議題我就自動跳過了 ) :

• 有人問道 : If you develop Java all over again, what will be done differently. 於是 Gosling 就說啦, Properly wont develop AWT (觀眾笑), and left over calender class ( 這點不是很確定, 因為 calender 不是被大修過, 為什麼是 left over ? ), won't done closure at the first time.

• 有人關心 Balance between continuous adapting, evolving, changing of Java and the the mature of Java, 可能是想問究竟 Java 算不算成熟, 持續的有改變是否是好事之類的. Gosling 回答道, Java 5 is really a change ( 事實上直到 Java 5 才真正做了比較大的改變 ) . There are still many Java 7 proposals on debate. The way people use it is changing. Java works out better then expected. Many proposals, such as bound property proposal, are more complicated than just writing the code. Must consider some issues, such as explosion and chaos of APIs. ( 我覺得這跟一般的 Software 增加新的 Features 是差不多的 )

• Something about Generic, seems similar with last question.

• Favorite IT/IS topics of James Gosling. Depend on who he talks. ( No very related with Java. )
  

• Future of "small Java" ( Nothing new actually )
  

• Favorite Language despite Java ? James Gosling : It's an easy quesiton, Scala. ( 一點都不熟阿 = = 要檢討 )
  

• 有人問道 Java is similar to an OS ( 指在很多表現上很像一個 OS ), platform, not simply a Programming Language environment. James Gosling 順著接手說, bycode is general for many languages. 雖然 JVM 將可以支援很多不同的語言 ( More and more services can built upon JVM in next 10 years. ), 但是某些語言是難以被完整支援的, 特別是跟 pointer 有關的語言. 即便如此, Give up C/C++, that was no-brainer. 中間還有說道 James Gosling 其實很 appreciate Microsoft 對於 C/C++ 的付出貢獻 ( 我應該沒聽錯 XD )
  

• 有人問道 Java 7 的時間表. Time frame for Java 7 or new features, or progress. James Gosling 說 It not technical question, but policy, JCP, something related ( 就是說沒辦法單單從 Technology 角度給答案啦, James Gosling 目前是 Sun 的 Client Software Group CTO ). There is no schedule, hope yesterday :p

• 給大家的話. Last word for developers : Drink more Beer ^^ (這應該是給 Java One 參加者的話) , Make sure you working on projects for fun.
  

整個錄音中其實我最有興趣的是 James Gosling 反覆提到的那個 Slide Program, 但是只有發音 ( 類似 Hextor 的發音 ) 不知道怎樣查, 嘗試幾個都找不到 @@

在 The Computer Language Benchmarks Game ( http://shootout.alioth.debian.org/ ) 網站上提供了由大約 18 個 benchmarks, 由對於大約 34 種 programming languages 的 implementation 作 benchmarking 的結果. 並提供方便的統計或比較觀點查看結果. 他們的計畫網頁可以在 Alioth GForge 找到 : Shootout@Alioth-GForge

例如 Java 6 -server 對 Python 的比較結果 : ( 這兩者在 CPU Time 跟 Memory Usage 上的差異還真是明顯 )

或是可以對於不同的 benchmarks 給予不同的 weights, 進而調整 benchmarking 的結果.


不過當然, 這些 benchmarking 只能反應這些 programming languages 之間比較的小部份面向而已, 就軟體工程的角度而言, 選擇 programming languages 時要考慮的 factors 比這裡所能呈現的多太多了.

但是從這點出發, 是否未來有一天, 我們也可以靠著在這樣的網頁上, 選取跟目前進行中的 project 相關的 benchmarks, 以及要衡量的 factors, 就決定要利用哪種 programming language 進行開發呢 ? 例如上面的 benchmark 中, 包含了許多基本的 data structure 以及 algorithms 作為 benchmarks, 如果這些 benchmarks 可以組合起來, 提供更為 high-level 的 evaluation benchmark, 同時加上不同的 programming languages 在 architectural components 上得 benchmarks, 那麼我們可能就可以找到更多在軟體工程中可以被利用的 benchmarks, 進而更容易決定 programming languages 的選擇.

雖然我是個平常用不到 bytecode inspection tool 的人, 不過今天因緣際會看到 reJ 這個 tool, 起了一點想法.

我們對於什麼東西都可以用 5W1H, who, when, why, what, where, how 來嘗試弄清該東西的本質, 而我就想問了, what kind of bytecode inspection tool do you actually need ? 以及 who else also need this tool ?

reJ 這樣說了,

There are various robust libraries/APIs available for bytecode manipulation, such as:

• BCEL - http://jakarta.apache.org/bcel/
• ASM - http://asm.objectweb.org/
• Serp - http://serp.sourceforge.net/
  

Each library has a slightly different focus. reJ uses it's own API which is focused to serve the needs of the user interface. The user interface with syntax coloring, search, compare and editing capabilities is something that is less readily available elsewhere.

關鍵句子出現了, "serve the needs of the user interface".

現在已經有很多強大的 bytecode manipulation library 出現, 尤其是 BCEL 跟 ASM, 基本上最近幾年在比較好的 software engineering conference / journal 上看到關於需要處理 bytecode 的 paper 都脫不了使用這兩個 tools. 在品質上顯然是受到信賴的.

然而 bytecode manipulation 終究只是技術的問題. 怎樣從 bytecode data 中挖出 information 並不該是身為 programmer 的我們需要花費最多關注的問題, 畢竟這是個一定可以被解決的問題. 我們更應該關注的是怎樣更有效率地挖出有意義的 information, 或者換句話說, bytecode inspection tool 要該要呈現什麼樣的 user interface 給 programmer, 才能夠讓 bytecode inspection 的動作有意義且有效率. 我相信 reJ 的那段話就是在嘗試說明此點.

User interface 在這裡並不單純指 software GUI 而已, 而是包含了 programmer 跟 bytecode inspection tool 之間的各種 operating languages. 透過 user interface 的設計, bytecode inspection tool 可以知道 programmer 真正想要的 information, 並且將之呈現給 programmer.

從 reJ 的 screeshots 可以看到這種努力, 雖然目前支援的 views 還很少, 但是這是以 service 的觀點來製作 bytecode inspection tool, 嘗試把 programmer 真正想要用的 views 帶進 software. (這不就是 service-oriented computing ?) 底下 screeshots 取自 reJ @ SourceForge.net.


也有其他的 tool 有類似的想法, 例如 jclasslib, 可以看到的 information 更多, 但是過多的 information 卻沒有整理成適當的 views, 一樣對於 programmer 來說是種困擾. 底下是 jclasslib 的一張 screeshot, 其他的 screeshots 可以在他的網站找到.

jlayout 是一個可以把 GUI configuration 與 Java code 分開處理的 tool. 遵從 jlayout 的 annotation 以及 configuration 語法, 可以把原先 Java code 中一大串的 GUI code 部分以少量的 annotation 取代掉, 而在 configuration file 上是以對每個 object 獨立作 configuration 的方式, 指定 object 的 state, 以及 objects 之間的 association. 整體概念可以簡單用下圖說明.


概念上跟 CSS 之類的有點相似, 但是 jlayout 沒有辦法支援長相一樣的 GUI objects 使用同樣的 configuration, 當然就更別說 styles 之間的 inheritance 關係.

從 configuration file 的長相可以看到其實 jlayout 在 code 跟 configuration file 之間還是有蠻強的 coupling. 需要依靠 object name 作為 configuration deployment 的依據, 也幾乎每一個 GUI object 都需要一個獨立的 configuration section.


換句話說, jlayout 提供的好處其實只有可以縮短原先 Java code 內的繁雜長串 GUI 部分, 以及可以透過 text-based configuration 調整 GUI object 的 state, 以及 GUI objects 之間的 associations. 進行調整時, 因為許多 method call 的 code 被省略了, 因此可以用更簡潔一點的方式作調整.

我對於 Jini 的 capabilities 以及 architecture 之認識主要依靠閱讀 Jini Architecture Specification [1] 以及Jim Waldo (Sun 資深工程師, Jini 的主要發明者之一) 在 1999 年發表於 Communications of the ACM 上的一篇文章 [2].

The Goal of Jini

引用 Jim Waldo 在 [2] 文章一開始的一段話 :

The Jini™ architecture exemplifies a new approach to computing systems—making the network the central connecting tissue. By replacing the notion of peripherals and applications with that of network-available services and clients that use those services, the Jini system breaks down the conventional view of what a computer is, while including new classes of devices in a unified architecture.

可以看出Jini 的理想是跳脫目前的電腦架構, 而在目前的基礎之上, 建構一個以 Service 為單位, 基於 Network, 只存在 Services 與 Clients (Users) 的世界.

The Reality of Jini

然而 Jini 以開放的 Specification 來看並未真正完全具備實現理想世界的完整能力. Jini 的主要能力仍是以 Service Lookup 為主, 也提供 Service Registration 以及 Leasing 的特性. 其中 Leasing 機制可以視為一種極為簡單的 Service Negotiation. 另外一個令 Jini 與目前既有的 Service Middleware 極為不同的特點是, Jini 有 Mobile Code (Code Mobility) 的概念. 此概念為跳脫傳統在 Service 與 Client 是只有單純的 Data 傳送的方式, 而把 Code 也視為 Data 進行傳送. 這樣一來 Services 之間的 coupling 將更低, 同時更能更應付一個快速變化的網路環境 (Changing Network). 此特殊的能力事實上是建構在 Java 本身統一利用 JVM 執行程式, 以及 Java 的 Security 特性上. Jini 的真正意函在於 Jini Specification, 而利用 Java 作為實現只是一種選擇, 然而其他語言是否能夠實現 Jini Specification 就不一定了.

在所查到的相關資料中, 大多將 Jini 的 limitations 歸因於下列幾點

1. Network-Centric [3]
1. need a central server [3][5]
2. TCP/IP based [5]
2. Architecture Base
1. based on conventional distributed system [3]
3. Java-based [4]
1. JVM limitation [3][5]
2. Java RMI limitation [3][5]
   

如果單以 Jini architecture specification 的角度來討論, 唯一可能留下的應該只有 need a central server 以及 based on conventional distributed system 兩點. 其中需要 central server 此點會使得 Jini 在某些環境下比較難以實現, 例如 pure Ad Hoc 環境, 或是缺乏 central server 的 P2P 環境. 而 based on conventional distributed system 這點在 [3] 中則是認為會導致 Jini 需要 statically configured infrastructure 來完成 service discovery, 這跟 need a central server 是一樣的意思, 另外就是 Jini 將會需要一個足夠穩定的網路環境 (well-behaved computing environment) 以便進行 RMI 的運作, 滿足 transparency 以及 synchronization 的需求.

而餘下的 limitations 我認為其實跟 implementation 的選擇相關比較大. 比如說 TCP/IP 的依賴性問題, 在 Jini 原先的 implementation 中僅支援 TCP/IP, 但是根據 specification 可以進行適當的擴充, 以支援其他不同的 protocols, 在 [5] 有參與討論者說明自身的相關計畫經驗. 同樣的, 與 Java 相關的 limitations 可以藉由選擇不同的語言實現 Jini architecture specification 解決.

再者, 如果回到 Jini 原先的理想下, 那麼其實 Jini 還有著更多的 limitation, 包含在目前 service oriented 環境中要求的各種 service management 能力, 諸如 service broking, service negotiation, service mediation, service billing, service composition, service security... [6] 等等, Jini 都有許多尚未能滿足的部分.

The Rise and Fall of Jini

下圖說明了我認為 Jini 的 rise and fall. 但因為其中的許多部份沒有查到確切的年份資料, 因此我僅是簡單地照我的猜測及推想擺放相關方塊的位置.


首先是 Jini 的開始開發以及第一個版本的 release. 根據相關的文章可以看出 Jini 在當時引發的熱潮. 而這時有個意外的插曲, Sun 的 marketing 把 Jini 說小了, 沒有完整地呈現出 Jini 的理想, 或許這是為了單純的 marketing 考量, 此點在後來採訪 Jim Waldo 的文章中也有提及[7]. 我認為這點在某個程度上使得 Service-Oriented Computing 沒有更早獲得重視與劇烈發展.

而在 Jini 於市場上取得短暫的成功後, 怎樣維持接續的發展以及強化 Jini 的能力是最重要的事, 單純只有 service lookup 顯然是不夠的. 在這裡我想同時受到幾項因素影響 Jini 的發展. 首先是同一時間 Java 本身也在 J2SE 以及 J2EE 領域取得巨大的成功, 相關的應用及計畫大幅展開, 此段時間內想必 Sun 本身也是忙的不可開交. 對照同時間的 J2ME 發展, 幾乎呈現停擺狀態. 另外如上述說的 Service-Oriented Computing 的想法還不成熟, 許多 Jini 可以沿深加強的方向都還沒有較為成功的研究成果出現. 另外有一個我認為很重要的因素, 在於 Sun 在 Jini 最初 release 不久後開始緊縮 license, 以 Sun Community Source License (SCSL) 授權, 直到 2005 年才開始分別釋放部分程式碼改為 Open Technology License 以及 Apache License [9]. 我認為這無形中對於 Jini 在 Open Source Community 以及 Commercial Company 的發展進行了侷限, 許多基於 Jini 的可能性無從發展 [8], 進而影響後續對於 Jini 是否能夠制定一個 standard 以及 Jini 應用的 promotion.

而對於 Sun 以及Jini 來說, 最大的玩笑或許是 Web Services 的崛起. Web Services 使用 XML-based Remote Procedure Call (XML-based RPC), 相對於 Jini 的理想來說其實有點開倒車.然而在之後的兩年之間, Web Services 的熱潮完全掩蓋了 Jini 的光芒. [10] 的作者認為原因可能是 Web Service 相對的 simplicity. 我覺得應該反過來說, 是 Jini 還沒有達到應該有的 simplicity.

縱使如此, 不管怎麼說, Web Service 的熱潮也逐漸退了, 取而代之 Service-Oriented Computing以及 Middleware-based Software Engineering 看起來正要開始快速發展, 因此我想我同意 Jim Waldo 說的, 許多真正有用而強大的概念是需要時間成熟及驗證 [7], 過早斷定 Jini 已經不行了是不必要的, Jini 仍有大好的機會捲土重來.

References
[1] Jini Architecture Specification, URL : http://www.jini.org/wiki/Jini_Architecture_Specification
[2] Jim Waldo, “The Jini Architecture for Network-Centric Computing,” Communications of the ACM, vol.42, no.7, pp.76-82, July 1999
[3] Robert Grimm, Janet Davis, Eric Lemar, Adam Macbeth, Steven Swanson, Thomas,erson, Brian Bershad, Gaetano Borriello, Steven Gribble, and David Wetherall, "System Support for Pervasive Applications," ACM Transactions on Computer Systems, vol.22, no.4, pp.421-486, November 2004
[4] J. Allard, V. Chinta, S. Gundala, and G. G. Richard III, "Jini Meets UPnP: An Architecture for Jini/UPnP Interoperability," Proceedings of Symposium on Applications and the Internet, pp.268–275, 2003
[5] Limitations of Jini Technology, discussion thread at Jini mailing list, URL : http://osdir.com/ml/java.sun.jini/2004-10/msg00199.html
[6] Dan Jong Kim, Manish Agrawal, Bharat Jayaraman, and H. Raghav Rao, "A Comparison of B2B E-Service Solutions," Communications of the ACM, vol.46, no.12, pp.317-324, December 2003
[7] Janice J. Heiss, "Jini Network Technology Fulfilling its Promise: A Conversation with Jim Waldo," March 2004, URL : http://java.sun.com/developer/technicalArticles/Interviews/waldo_qa.html
[8] Eric S. Raymond, "Open letter to Sun: Let Java Go," 2004, URL : http://www.catb.org/~esr/writings/let-java-go.html
[9] Licensing of Sun's Jini Technology, at Sun official website, URL : http://www.sun.com/software/jini/licensing/
[10] Berco Beute, "Universal Plug 'n Play: Jini's ex-rival back from the dead?" 2004, URL : http://www.artima.com/weblogs/viewpost.jsp?thread=48801

當初看上 Jupe 是因為他的 reverse engineering 支援, 看起來似乎頗有希望. 在 forward engineering 部分的 UML tools 已經夠多了, 而且甚至有點雜. 除了對於 XMI 支援以及呈現的問題, 不同的操作 style 也造成這些 forward engineering tools 合用互補的不易. 然而在 reverse engineering 的部分, 則是連這樣的缺點都還沒辦法有 ^^b , 因為好用的 reverse engineering tools 實在太少了, 有些可能要在 commercial 才看的到.

Jupe 相依於 Eclipse GEF, Eclipse UML2 frameworks, 同時嘗試支援 forward and reverse engineering. 在今年 (2007) 三月左右停止繼續維護與開發, 原因不明.

在使用上, Jupe perspective 右手邊是 forward engineering 用的 UML 元件選單, 這跟大多數的 tools 一樣, 就沒什麼好說的. 而在 reverse engineering 部分則是可以從 package 或是 class 直接增加到 class diagram 內, 操作上是還算直覺.


但是在呈現上的結果到是有很大的問題. 僅以加入一個 class 來說, 圖上會連同外面的 package 一起出現, 但是圖形卻不會自動調整大小, 整個就擠在一起.


需要手動分開才能看一點.




而且對於 graph boundary 沒有作 checking, 所以可以隨便移動, 離開原本的 package 也是可以.


綜合以上總總, 實在不能算是派的上用場的 tool, 而只是 yet another failed Eclipse plug-in. 有空真該來統計一下 fail / success 的 Eclipse plug-ins 比例. Eclipse platform 身為一個響譽軟體開發社群的 IDE, 是否對於如此多的 fail plug-ins 也負有一些責任呢 ?

Jdec 就如其名是一個 Java Decompiler, 目前主要支援的 features 包含 :

1. Decompiling a Java class
2. Decompiling a jar file : 我喜歡直接支援 jar file 的 decompiler, 而不是需要使用者自己利用各種技巧來作到
   
3. Selective Decompilation of a class file : 這個功能是不錯, 但是需要知道該 class 的 specific name, 如果可以作到將 jar file 當作 code repository, 而可以利用 keyword 去作 mapping 就更好了. 而且 Jdec 也不能自動將相關的 classes 都作 decompiling. 事實上我們作 decompiling 就是想看 code, 因此如果能自動找出直接相關 (high-coupling) 的, 形成一個 concern, 或許會更為有用.
   
4. Decompiling 2 Versions : 感覺不太有用, 只是方便想比較的人, 但是我直接利用 decompiling a Java class 找出兩個版本, 再用其他更 powerful 的 tool 去比較版本不是更好 ?
   
5. Disassembling a Java class : 這個能力不錯, 雖然我用不太到. 其他的 Java decompilers好像也沒有看過這能力. 但是這功能跟 decompiler 關係有很大嗎 :p
   
6. Local variable information : 只對原本的 developer 較有用而已, 或是想認真 trace code 的人
   
7. Exception Table Information : 這個對於 code tracing 也很有用, 或是 component reuse 時, 可以用這功能加以擴充, 作 contract checking. 不過他還作的不夠好就是了. 既然又作這個, 其實可以在 Decompiling a jar file 功能上搭配這個, 幫忙分析 code 中的 exception handling coverage 情形, 可以用樹狀圖之類的表示. 不過這同樣超越一般 code decompiler 的能力了.
   
8. Constant Pool Details : 一樣, 對於作底層的人, 或是 performance 比較可能比較有用, 一般人大概沒什麼用
   
9. Skeleton Display of Class File : 實用的功能
   

不過我覺得他的操作流程設計不是很好, 新建 decompiling project 時的選擇方式非常 engineer-thinking, 這樣限制使用者的 view 會讓人感覺很不舒服. 同時 configuration 必需所有的欄位都填完才能 decompile 一個 .jar file, 還我一開始試了好幾次, 難道不能有預設值嗎 ?

他的 UI 設計應該是是有受到 Eclipse 使用 JFace 的影響, 不過還差遠了 XD

整體來說是作為一個一般 Jave decompiler 該有的功能都有了, 但是這個時代這樣已經不夠了, 或許 decompiler 所定義的能力範圍就是那樣, 但是我們總是希望更好, 總是希望一個 tool 不只是完成整個 scenario 內的一個 role, 而是能幫我演出整個 scenario, 或是只少把他跟其他 role 的關係交代清楚, 而不是我要自己去指導它們怎麼演戲, 不是嗎 ?