早上，習慣性的打開GoogleReader，看看世界的變化。發現Planet Eclipse上已經有參加EclipseCON2008的朋友把Eclipse4.0（簡稱e4）Demo地址以及一些截圖放到Blog上了~我們就來欣賞一下Eclipse的巨大變化吧！
呵呵，是不是很可怕，一個基于web的開發工具？我在Eclipse的Wiki上已經看到這個截圖的Demo了，但是還沒有時間試用~
此次放出的e4的demo基本上都是swt的調整，比方說可以使用swt來做flex，使用swt來做DOJO~，從這些方面就可以看到Eclipse正在向基金會想想的那樣為e4提供一個基于web應用的平臺，我想這個平臺應該就是RAP了~而且從Demo上看，e4將會大大的涉足到web應用領域中，期待他們為我們帶來再一次的驚呼！！！
http://wiki.eclipse.org/E4/Running_the_demos （e4的demo）
還有一個令人振奮的消息，不知道是好事還是壞事-----微軟已經決定進入Eclipse基金會，并打算開始資助SWT項目了。
Earlier this week, the teams and developers working on the various projects of Eclipse began an intense debate regarding the next steps in the future of Eclipse, all triggered by the announcement of the incubation project titled 'e4' on the Eclipse committer mailing-list:
The Eclipse Project PMC is announcing a new component, called E4, as part of the Eclipse Project Incubator.
Component Description:
During the Eclipse Project 3.4 release cycle, one of the important plan items was "Create the Eclipse 4.0 Plan". The intent of this work was to identify the most pressing issues that would impact the ongoing success of Eclipse, and come up with a plan to address them. The result was the design of a new platform "e4", which will be the basis for Eclipse 4.0.
The goal of the e4 component is to provide a public venue for the initial explorations that were done, leading up to the e4 design. We expect to continue to work in this area until we have reached consensus on how the full e4 effort will be structured.
The e4 moniker is a reference to Eclipse 4.0, which would be the next major release number for the classic Eclipse distribution and platform projects. The last three major Eclipse releases shared these version number relationships:
Callisto corresponded to the Eclipse platform v3.2,
Europa corresponded to the Eclipse platform v3.3, and the upcoming
Ganymede release corresponds to the Eclipse platform 3.4.
Historically it has been common practice for these plan documents to outline the thematic goals for a given release of what is commonly called the
Eclipse top-level project. Traditionally, the top-level project has encompassed the Eclipse platform, the Java development tools, the Plug-in development tools, and all other components of the commonly referred-to Eclipse 'classic' distribution (the Java and Eclipse Plug-in IDE). This plan format has been used since the 2.1 release of Eclipse, and each prior plan is available
on the Eclipse top-level project site. The e4 announcement is a somewhat different approach in that community involvement is being asked prior to the drafting of any plan.
Initially, the e4 project is little more than a community gathering point; a place to track early changes and ideas in code. The goal of opening this project now has been described by many of those involved as an effort to get community input and ideas at
EclipseCon 2008, and to then begin drafting a plan based on the community input after that point. Kevin McGuire, an Eclipse committer who primarily works on the Platform UI team, described e4 in this way:
We on the platform team care passionately about Eclipse. We know you do too. We want to see it live a long, healthy life. We want it to serve its community as best it can. When we can’t achieve that it makes us sad. It’s clear to us that for Eclipse as a platform to remain long lived, vibrant, and relevant, it must be able to change. But the weight of a zillion plug-ins, projects, and API means the path of least resistance is stagnation, and the effort to effect change given the current constraint system is becoming monumental.
Therefore, two things must happen:
- A new space must be carved out in which experimentation can happen, leading to change.
- New people must get involved, bringing with them their energy, ideas, requirements, knowledge, passion.
These two are intrinsically tied.
That is e4.
While there was some heated discussion over the format and approach of the initial project announcement, the e4 project is likely to become a central test-bed for the various transformations that Eclipse will go through to reach its next major milestone. In the past, major version number increments for Eclipse have represented significant changes for the Eclipse project. The transition to Eclipse 3.0 encompassed the move of Eclipse to the OSGi platform, the announcement and creation of Eclipse rich-client platform, and both a look-and-feel and performance overhaul. The expectation is that Eclipse 4.0 will also represent such a major shift.
InfoQ will continue to cover future Eclipse planning decisions as they become available.
EclipseCON2008 only 1 week left!
又一次開源界的盛會EclipseCON2008就要召開了~據我了解此次盛會將會吸引更多的開源廠商，領袖，開發者參與，其中就有來自微軟的Sam Ramji（微軟開源的Labs），關于OSGi的討論依然是重頭戲。
雖然Eclipse的RAP的發布也有半年多了，也在開源界引起了不小的反響，但是RAP還是沒有得到廣泛的應用，來自RAP的主力開發商Innoopract Informationssysteme GmbH的消息，此次EclipseCON2008大會也會給RAP帶來更多的利好消息，畢竟關于RAP的討論被安排在第二場，僅次于第一場OSGi的議題。
Eclipse4.0也被提上了討論日程，在介紹中提到，Eclipse3.0主要在力推RCP平臺，而Eclipse4.0將會將會帶來一個全新的用戶界面以及新的用戶體驗，將帶領Eclipse進入到WEB應用中，我想在Eclipse4.0的時候RAP應用，將變成Eclipse的主推平臺了。
還有很多關于其他項目的討論，但是我一直關注的VE的消息，好像還是不被人們注意，可見VE基本上已經死亡，而且我認為可以算是Eclipse基金會中比較失敗的一個項目了！
預祝此次大會碩果累累，祝Eclipse越走越好！
預言了兩天，終于決定在我們的RCP客戶端中增加執行JRuby的功能。說是預言其實也沒有什么好預言的，JRuby早有耳聞，Ruby也一直在學習。其實要解決的問題只有一個---解決Java實例如何給JRuby，然后有JRuby操作，其實不難，JRbuy官方的WIKI上有一個例子，但是那個例子有太多硬編碼的問題，稍稍改造，將硬編碼的內容抽取到JRuby中，就好了~
我想說的其實是在RCP中加入JRuby的作用是：
實施人員只需要寫腳本就可以隨意操作界面上的任意東西；
使產品更進一步達到零二次開發的階段；
使用JRuby來開發SWT的界面，還是有比較復雜，在熟悉SWT開發和JRuby的情況下畫一個比較復雜的界面時候就會非常復雜！這里還是建議使用類似于XSWT等XML界面描述語言，然后配合腳本完成功能。
下面給出一個可以在運行JRuby的SWTShell：
| package com.glnpu.jruby; import java.util.ArrayList;
import java.util.List; import org.eclipse.swt.SWT;
import org.eclipse.swt.events.SelectionAdapter;
import org.eclipse.swt.events.SelectionEvent;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.Text;
import org.jruby.Ruby;
import org.jruby.javasupport.JavaEmbedUtils;
import org.jruby.runtime.builtin.IRubyObject; public class RunJRUBY extends Shell { private RunJRUBY run;
private Text text;
/**
* Launch the application
* @param args
*/
public static void main(String args[]) {
try {
Display display = Display.getDefault();
RunJRUBY shell = new RunJRUBY(display, SWT.SHELL_TRIM);
shell.open();
shell.layout();
while (!shell.isDisposed()) {
if (!display.readAndDispatch())
display.sleep();
}
} catch (Exception e) {
e.printStackTrace();
}
} /**
* Create the shell
* @param display
* @param style
*/
public RunJRUBY(Display display, int style) {
super(display, style);
run = this;
createContents();
} /**
* Create contents of the window
*/
protected void createContents() {
setText("SWT Application");
setSize(500, 375); text = new Text(this, SWT.V_SCROLL | SWT.BORDER | SWT.WRAP | SWT.H_SCROLL);
text.setBounds(0, 0, 492, 312); final Button button = new Button(this, SWT.NONE);
button.addSelectionListener(new SelectionAdapter() {
public void widgetSelected(final SelectionEvent e) {
Ruby runtime = Ruby.getDefaultInstance();
try {
//允許傳對象，作為參數給JRuby
IRubyObject rootRubyObject = JavaEmbedUtils.newRuntimeAdapter().eval( runtime, text.getText() );
JavaEmbedUtils.invokeMethod( runtime, rootRubyObject, "run", new Object[] {run}, null );
//不傳對象，直接運行JRbuy
//runtime.evalScriptlet(text.getText());
} catch (Exception e1) {
System.err.println(e1.toString());
e1.printStackTrace();
}
}
});
button.setText("button");
button.setBounds(335, 326, 48, 22);
//
} @Override
protected void checkSubclass() {
// Disable the check that prevents subclassing of SWT components
} } |
下面是可以執行的JRuby代碼：
| require 'java'
module SWTTest
include_package 'org.eclipse.swt'
include_package 'org.eclipse.swt.layout'
include_package 'org.eclipse.swt.widgets'
include_package 'org.eclipse.swt.events'
end
class TestDialog < SWTTest::Dialog
@shell
@parentShell
def initialize shell
super(shell, SWTTest::SWT::NONE)
@parentShell = shell
open
end
def open
createContents()
@shell.open();
@shell.layout();
end
def createContents
@shell = SWTTest::Shell.new(@parentShell, SWTTest::SWT::DIALOG_TRIM | SWTTest::SWT::APPLICATION_MODAL)
@shell.setSize(500, 375);
@shell.setText("SWT Dialog");
button = SWTTest::Button.new(@shell, SWTTest::SWT::PUSH)
button.setText("Test Button 1")
button.setBounds(147, 116, 48, 22);
end
end
class TestMain
def run shell
TestDialog.new shell
end
end
TestMain.new |
在JRuby代碼的最下面有一個TestMain的類，主要是用于調用的~這一點是和其他的寫法不同的！
至于它有多強大，就看大家怎么用了~而且java和JRuby是運行在同一個JVM之上的，它可以使用此JVM下的所有對象！
不要用年終考評來訂立學習目標，要利用年終考評來記錄個人的成長。
要讓每一位程序設計師都明白，寫出零錯誤程序是很不容易的，所以應該多花功夫用各種方法做最徹底的測試。
糾正程序設計師以為加除錯碼會花太多時間的觀念，應該訓練程序設計師第一個反應是考慮加上除錯碼是否有道理，第二是考慮加除錯碼是否符合項目的目標與工作的優先級。
不要讓凡事不能的態度阻礙了創新。
不要讓程序設計師以為使用者并不在乎軟件的質量。
不要給使用者次品，寧愿延期交貨，務必追求質量完美。
程序設計師必須經常以使用者的觀點來看自己寫的程序，程序設計師必須能體會使用者的感受。
在包裝盒里的每一件東西，都是產品的一部分。
將程序的可共享性當作優先考慮的目標之一，否則程序設計師將經常做重復的工作。
從您的每件工作中創造最大的資源，不管是利用現有的杠桿，或是創造新的杠桿。
如果進度發生落后，那表示有個地方出錯了。您應該找出問題，并加以解決，不要一味要求組員加班，在問題沒有解決之前，加班是沒有用的。
別誤信加班等于增加生產能力，長期的加班只會傷害生產能力，對項目沒有幫助。
周末是屬于組員私人的時間，不是公司的。公司不應該以打敗競爭對手為理由，要求員工周末加班。
強調思考的重要性，而不是長時間工作。
訓練開發小組懂得在正常工作時間內掌握好工作的效率，不要讓他們超時工作，因為超時工作只是浪費時間的假面具。
與程序設計師共同研擬出一份每日活動的時間表，把無法預期的臨時公務變成固定時間處理的事情，并且把程序開發的工作放在最優先的地位，不要讓其他次要的事情干擾到寫程序。
主管應該把自己視為團隊中的一分子，與其他人平等，而不是高高在上。
用看程序的方式找錯，是既懶惰又無效率的方法；
| 隨時睜大雪亮的眼睛，看看是不是有個懸而未決的問題，一定要有個人(或是由主管自己)來負責研究到底哪里出錯，也許這種研究既花時間又無聊，但總比災難發生之后再來花好幾個星期收拾殘局要好得多。 |
問了錯的問題，而導致錯的答案，訓練自己問出正確的問題！
| 如果您能很清楚告訴別人，您想要的究竟是什么，這樣別人才能給您真正需要的幫助，而不是做一些似是而非的虛工。 |
勉強自己接下不可能完成的任務，實在是以長痛代替短痛的做法，而且長痛的是整個團隊，該拒絕的時候絕對不能含糊；
不要為了討好別人而傷害雙方的工作進程，您永遠要根據自己的目標，做適當的決策。
必須保護項目不受外界的左右，尤其是當這種操控來自特權人物之手。
副產品對公司或產品都沒有策略上的價值，充其量只是一種消費者回饋。
不值得開發的功能就不要做。
軟件產品的開發，不能只為了有趣、挑戰性，或是夠有個性夠令人眩目。
遵循標準重于一切，特別是關于使用者界面的部分。
確定您所要求的報告真的值得屬下暫停工作，花那么多時間去寫。
請注意定期會議的價值，確定它值得每個人放下手上的工作。
召開任何會議之前，請確定本次會議的目的是什么，達成這個目的的條件是什么，然后，務必達到開會的目的。
不要利用進程表來驅使項目的進行，這對小組的士氣傷害太大了。
讓日程表維持適度的緊迫，但又是可以做到的，好讓組員振奮、不松懈，專心致力于項目的推進。
絕對不要草率定出不可能的期限，導致組員為了趕進度而損害產品的質量。
把長期的大項目，分成幾個完整而獨立的小項目，各小項目必須有一個主題。
為了保持創意的活力和團隊士氣，必須讓每一個小項目都有令人興奮的結果。
不要讓程序設計師的學習停滯不前，要讓程序設計師有機會磨練不同領域的技術，培養十八般武藝樣樣精通的組員。
訓練新進程序設計師時，先培養他對整個公司所有項目都有價值的技術，然后才培養本項目獨有的技術。
不要舍不得放您最優秀的程序設計師到別的項目去。如果他在您的項目已經沒有新的東西可學，為了公司和他個人的前途，您應該把他推薦到別的項目，讓他的成長永不間斷。
確定每位組員、每兩個月都有一項技術上進步。
一發現某處需要改進，就立即采取更正的行動。
首先還是先看一下書評。
下面是來自china-pub的書評：
| 作者詳細描述了他在美國領導項目的各種實際的策略方法，教您如何開發高質量的軟件，而且絕不延誤。本書是為每一位從事研發工作的朋友而寫，相信您在讀過本書之后，一定急于推薦給您的主管、同事和您的朋友。 |
卓越的領導者從不同的角度看世界。若是公司被大火燒得精光，他非但不為丟飯碗驚慌，反而利用火焰來燒烤一頓大餐。當每個人都搖頭離去，卓越的領導者仍有充分的信心保持樂觀，對每件事都從正面角度來思考。就因為凡事都看光明面，卓越的領導者并不把失敗當失敗，反將其當作學習克服障礙的經驗。正因如此，卓越的領導者樂意嘗試各種稀奇古怪的想法，并從中獲得重大的突破，即使不成功，他只把這次經驗當成獲得信息的方式之一。這種領導人不一定要有經驗，而是需要強烈的進取心和明確的理想，能夠將理想與他人溝通，鼓舞他人共同追尋理想的能力，再加上一點機會，這就是能將理想實現的卓越領導者。
每當有人完成了一項新的功能或特色，就發個e -mail 給大家。
例如：
| “我已完成Faxmangler 的搜尋與取代功能。Frank”
主管應該看一下結果，然后回一個：
“我檢查過F a x m a n g l e r的搜尋與取代，不太順暢，請再修改。Hubie”
或是：
“很好，繼續加油！Hubie”
想想看，如果大家經常收送這類正面的e - m a i l，一定會覺得充滿干勁，這和可恨的進度報告多么不同！程序設計師會很樂意看見這類的好消息，當自己送出完成工作的信息時，也會很有成就感；沒有人會覺得這是很討厭的報告。 |
每當進度快要落后了，就到我的辦公室私下討論原因，我們一起開動腦筋尋求解決之道。
例如：
| 當某位程序設計師覺得自己可能要落后了，我會和他談，研究將來如何避免這種事情。是我們在制定進程時疏漏了某一個重要環節嗎？或是時間表定得太樂觀了？是不是有個錯蟲( b u g )在作祟，害得程序很難寫或無法測試？不論問題是什么，我們一定想辦法解決掉，并且預防它將來再發生。 |
盡可能減少項目中小組彼此間的依賴。
目標越是明確，達成目標的過程就會越有效率。
建立最適當的程序設計優先考慮順序，并且讓所有的程序設計師確實遵守。
| 排出一個優先級表： - 體積大小(size)
- 速度(speed)
- 堅固性(robustness)
- 安全性(safety)
- 可測試性(testability)
- 容易維護(maintainability)
- 簡潔(simplicity)
- 再用性(reusability)
- 可移植性(portability)
|
一旦您掌握了這個概念，把它應用在項目上，您可以大聲說自己確實是在聰明地工作，而不是辛苦地工。
一發現Bug就立即清除掉，別拖延。
作者給出的提示：
錯蟲愈晚清除，時間花得愈多。
在開發的過程就立即除蟲，可以讓您早些學到經驗，然后就不會再犯同樣的錯誤；相反地，如果到了項目后期才發現，您可能已經犯過多次同樣的錯誤而不自知。 發現錯蟲而立即除錯是一種緩沖器，提醒那些講求快速而不夠謹慎的程序設計師，以后多加小心。 若能保持沒有任何錯蟲，您就能比較準確估出項目的完成時間。 要求錯蟲隨時發現隨時改，等于是在開發過程中引進一個小小的質量管理機制，多方的防微杜漸，保護產品的正確性。 |
學習前人的經驗；
好方法要讓大家分享；
項目只要有偏差，就需要調整，絕對不可以放任自流！
定期暫停手邊的工作，然后往前思考，隨時做必要的修正，以避免未來的大障礙。
| 有什么事情是我今天能做，而且可以幫助項目在未來幾個月內順利進行的？ |
總結本書中的54條法則得到：
- 建議一只和諧的團隊；
- 給團隊一個明確的目標，讓大家都知道這個目標并把它印入腦海；
- 讓品保人員明白自己不僅僅是為了Bug而加入團隊的；
- 建立合適的檢查點和里程碑，并利用檢查點和里程碑檢驗團隊的健康度；
- 不要害怕延誤，要不斷的修正方法但不要過度的修正目標；
- 努力讓團隊中成員產生共鳴；
希望大家共勉！
法則二十七：
Be like the doctors 用醫生的方法
當病人已經藥石罔效時，醫生通常會對病情有所保留，避免病人太過悲觀或恐懼，并且盡量鼓勵病人保持希望，最好能讓病人有個期望完成的目標。
醫生絕對不會斬釘截鐵地斷言什么醫療行為一定會有什么樣的結果，反而是以
一種自在且充滿信心的口吻說：“試試看吧，一切都還沒有確定呢。
另外一件應該向醫生學習的事情是，即使是再小再簡單的醫療行為，都帶著幾分風險，所以醫生會說：“當然，任何情況都是有可能的，治愈率再高我都不能跟你說百分之百沒問題。
法則二十八：
Remember the triangle:features, resources, times 軟件開發金三角：特色、資源和時間
作為一位軟件開發的領導人，你得集中注意力在三件事情：資源（人和錢）、特色（產品與其品質）和時間。這三件事是軟件開發的核心，其他的都是外圍。
資源、特色和時間是三角形的三個邊，任何一邊的變化，都會影響到另外一邊或兩邊。所以如果時間落后了，去看你的三角形，看看對特色和資源的影響；當有人談到可以增加什么功能特色時，你得立刻談起時間和資源，以顯得你思慮周
詳反應敏捷。所以，管理者的第一要務是把這個三角形放在心里，隨時利用這個模式來思考問題，你會發現答案都在這個三角形內。
法則二十九：
Don't know what you don't know 不懂別裝懂
法則三十：
Don't go dark 建立適當的檢查點
法則三十一：
Beware of a guy in a room 留心沒有檢查點的組員
法則三十二：
If you build it, it will ship 軟件要經常建構，就能順利推出
法則三十三：
Get a known state and stay there 掌握實際情況
法則三十四：
Use ZD milestones 零缺點里程碑
零缺點不代表軟件中沒有錯蟲，也不表示沒有遺漏的功能，而是指團隊的成品達到了事先規劃的品質水準，也經過測試驗證，就是零缺點里程碑。
法則三十五：
Nobody reaches the ZD milestone until everybody does 所有組員一起到達零缺點里程碑
法則三十六：
Every milestone deserves a no-blame postmortem 完成每個里程碑后，心平氣和地檢討
法則三十七：
Stick to both the letter and the spirit of the milestones 把握里程碑的實質意義與精神
法則三十八：
Get a handle on "normal" 培養正常的團隊運作
法則三十九：
A handful of milestones is a handful 里程碑不宜太多，才好掌握
法則四十：
Every little milestone has a meaning (story) all its own 每一個里程碑應有專屬的宗旨
法則四十一：
Look for the natural milestones 尋找自然出現的里程碑
以下是六種自然出現的里程碑：
1. 產品設計趨于穩定。
2. 中間產品被明確定義。
3. 團隊真正了解要花多少時間和努力才能完成目標（通常這會發生很多次，而且多半是進度落后的時候）。
4. 產品設計被刪減，或是資源增加，或是進度延誤，
或是三者同時發生。
5. 開發活動停止。
6. 產品進入除錯或穩定階段。
法則四十二：
When you slip, don't fall 如果滑了一跤，別就此倒地不起
- 進度落后與道德無關，請切記！
- 不要隱瞞事實。
- 化阻力為助力，利用進度落后來激發效率。
進度落后不是問題，被進度落后嚇倒才是問題。進度落后并不代表產品的難度太高而無法開發。但是如果進度已經落后卻未被察覺，那表示組員們不思考、不觀察、不討論，此時組織可說是瀕臨瓦解了。
善用你的遲延，這是最能看出你領導能力的時候，此時也是組員最脆弱也最需要你的時候，在這個時候組員最能把你的話聽進去，此時組員的學習能力最強。如果你在辦公室內激動得大喊大叫，指天罵地，那就錯失了贏得組員的心的大好機會。你必須說：“O K，進度落后了，讓我們來看看問題出在那里？??今天下午五點在會議室，我們要檢討每一個細節，問題一定要設法解決！”當組員了解到你不是企圖卸責或算帳，而是真誠地想解決問題，就會樂意把一切開誠布公地攤開來談，大家一起研究問題，從各種角度去設法克服問題。“進度落后”反而變成大家寶貴的成長經驗。
法則四十三：
Don't trade a bad date for an equally bad date 不要因為進度落后而更改最后期限
進度落后的程度是與計劃的不確定性成正比。
法則四十四：
After a slip, hit the next milestone, no matter what延誤了這個里程碑，就一定要如期到達下一個里程碑
我們必須明白，每一次的延誤，就是你和團隊信心的一次受挫，所以，延誤這個里程碑時，最好的補救辦法就是無論如何絕不延誤下一個里程碑。團隊必須挽回對自己的信心和對理想的承諾；因此，下一個任務必須準時完成的意義更重大，團隊需要重建信心。
法則四十五：
A good slip is a net positive 把延誤當作寶貴的學習機會
法則四十六：
See the forest 見樹亦見林
如果本項目有六個模塊，各有9 0 %的部分已經完成，那么你已經完成了5 4 %。每個模塊完成了九成，聽起來是個挺不錯的成績，但不能當成整個項目完成了百分之九十，它們之間不是相加的關系。你必須“見樹亦見林”。如果任何一個模塊完成比率是零，那么整個項目的完成率也是零。
法則四十七：
The world changes, so should you 世界在變，所以你也得跟著改變
雖然你想做些改變，你未必有勇氣實行。
偉大的軟件必定只有一個中心思想，至于品質能夠實現到什么程度，依賴領導者能否帶領團隊融合無數個小而重要的改變。如果你能在混亂中辨識出對項目最有意義的改變，并且引導團隊去適應它，將它融入團隊的精神中，將來就會在產品中表現出這項改變，呈現在顧客眼前。
法則四十八：
Violate at least one sacred cow 關懷多于要求
法則四十九：
Beta is not the time to change Beta測試版不是修改功能的時候
法則五十：
The Beta is for spin development Beta測試是暖身活動
法則五十一：
Triage ruthlessly 急救術
法則五十二：
Don't shake the Jell-0 小心保持軟件的穩定
法則五十三：
Compete with the superior story 偉大的軟件應該有一個偉大的故事
法則五十四：
Create a winning image 建立贏家形象
我討論的進度條主要是JFace的進度條，RCP已經提供了完善的Job組件，為什么還要用JFace的進度條呢？原因是我要在登陸界面上做進度處理，也就是使用Eclipse3.3提供的AbstractSplashHandler特性，可以將原有的啟動畫面替換成為一個登陸界面，啟動這個登陸界面時，Eclipse的Platform此時還沒有啟動，所以不能使用RCP本身的Job組件了。
由于是一個檢測服務器是否聯通的測試，所以并不知道測試的真實時間，所以就是要使用“傻瓜進度條”了，也就是反復走的進度條陳剛的代碼如下：
| button.addSelectionListener(new SelectionAdapter() {
private boolean stopFlag;// 停止標志 private void go() {
for (int i = 0; i < 10; i++) {// 循環10次，每次間隔一秒
System.out.println("第" + (i + 1) + "個任務執行完畢");
if (stopFlag) {// 監控是否要讓停止后臺任務
System.out.println("被中斷了");
return;
}
try {
Thread.sleep(1000);
} catch (Throwable t) {}
}
stopFlag = true;// 執行完畢后把標志位設為停止，好通知給進度框
System.out.println("全部任務執行完畢");
} public void widgetSelected(SelectionEvent e) {
stopFlag = false;// 每次都設初值為false
new Thread() {// 把后臺任務放到一個新開線程里執行
public void run() {
go();
}
}.start();
showProgressDialog();// 打開一個進度框
} private void showProgressDialog() {
IRunnableWithProgress runnable = new IRunnableWithProgress() {
public void run(IProgressMonitor monitor) {
monitor.beginTask("正在執行中......", 30);
int i = 0;
while (true) {
// 監聽是否單擊了進度框的“取消”按鈕，stopFlag則是監聽后臺任務是否停止
if (monitor.isCanceled() || stopFlag) {
stopFlag = true; // 單擊了“取消”按鈕要設標志位為停止，好通知后臺任務中斷執行
break;// 中斷處理
}
// i到30后清零。并將進度條重新來過
if ((++i) == 30) {
i = 0;
monitor.beginTask("正在執行中......", 30);
}
// 進度條每前進一步體息一會，不用太長或太短，時間可任意設。
try {
Thread.sleep(99);
} catch (Throwable t) {}
monitor.worked(1);// 進度條前進一步
}
monitor.done();// 進度條前進到完成
}
};
try {
new ProgressMonitorDialog(s).run(true, true, runnable);
} catch (Exception e) {
e.printStackTrace();
}
}
}); |
主要是使用兩個線程交替使用，第一個線程處理業務，第二個線程監控第一個線程查看它是否結束，如果結束或者被點擊cancele則停止進度條的進程，如果一直沒有關閉的指令，則反復開始---累加---結束---開始---累加---結束。
我們幾乎是把陳剛的代碼原原本本的抄襲了一下，僅僅是替換了go()中的內容，但是發現一個問題
new ProgressMonitorDialog(s).run(true, true, runnable);
使用此句的話，JFace的線程永遠不會啟動；
替換為
new ProgressMonitorDialog(s).run(false, true, runnable);
使用此句的話，JFace的線程可以啟動，運行正常，但是cancele不能響應，UI界面完全卡死！
第一個參數的名字fork~乍看去，什么意思都沒有，但是看看API才發現內藏很大的玄機，如果為true則此線程為一個非UI線程，大家知道非UI線程是不會阻塞UI的；如果為false則此線程為一個UI線程，大家也知道UI線程如果使用不當很容易阻塞UI的。
關鍵的問題是我們和陳剛的代碼幾乎一摸一樣他的進度條就啟動，我的進度條就不啟動！為什么？（這點至今不明白!）
詳查API發現如果fork為false的時候還是另有洞天的：
| This implementation of IRunnableContext#run(boolean, boolean, IRunnableWithProgress) runs the given IRunnableWithProgress using the progress monitor for this progress dialog and blocks until the runnable has been run, regardless of the value of fork. The dialog is opened before the runnable is run, and closed after it completes. It is recommended that fork is set to true in most cases. If fork is set to false, the runnable will run in the UI thread and it is the runnable's responsibility to call Display.readAndDispatch() to ensure UI responsiveness. |
API中說的很明白，如果fork為false時需要在線程中調用Display.readAndDispatch()方法，以避免UI被阻塞！
大家如果在JFace的開發中如果使用了進度條，發現UI被阻塞的話，就想想我哦！！！呵呵只用在進程中調用一下Display.readAndDispatch()就解決了！