早上，习惯性的打开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()就解决了！