今天偶然在TheServerSide.com上发现一篇挺有意思的文章，大意是讲在软件开发项目中类似日构建这样的工作为什么重要，通过它我们要达到的目的是什么。虽然文章的背景是讲一个叫做BuildMonkey的东东，但是很大的篇幅实在是我们日常很容易忽略的问题。如果你在公司做项目经理或者负责配置管理，建议你看一看这篇文章，说不定会有启发。
原文见：
http://www.theserverside.com/articles/article.tss?l=BuildManagement
posted @ 2005-03-30 15:16 大胃 阅读(18) | 评论 (0) | 编辑 收藏
今天在ADTmag.com上看到一篇文章，大意是说Eclipse虽然给IDE市场带来了非常大的冲击，但它并非是商用IDE的杀手。正如我上一篇随笔《Eclipse创世纪》引用Eclipse CON 2005上Lee Nackman所说，Eclipse的出现是为了提供一套被广泛认可和接受的实现了基本功能的平台，然后在这个基础上大家来开发真正满足市场具体需求的产品，同Visual Studio等竞争，而不是在底端为了一些开发人员普遍需要而大同小异的功能点各做各的一套，重复建设。这样传统的IDE提供商可以试着换一个角度看Eclipse：我们可以在一个相对成熟的基准平台上开发更高附加值的东西。文中还提到一些公司如Borland是怎样应对Eclipse的存在。
原文见：
http://www.adtmag.com/article.asp?id=10789
posted @ 2005-03-30 13:56 大胃 阅读(19) | 评论 (0) | 编辑 收藏
posted @ 2005-03-27 12:20 大胃 阅读(17) | 评论 (0) | 编辑 收藏
| What is your preferred Java IDE? | |
| Eclipse | 53.3% |
| emacs | 2.1% |
| IDEA | 19.8% |
| Java Studio | 0.8% |
| JBuilder | 6.6% |
| JDeveloper | 3.3% |
| Netbeans | 2.5% |
| vim | 3.3% |
| WSAD | 7.4% |
| other | 0.8% |
| Vote count: | 242 |
posted @ 2005-03-26 19:39 大胃 阅读(78) | 评论 (0) | 编辑 收藏
仅仅是为了好玩，我们来看一个Eclipse的C#插件，该插件由一家法国公司Improve Technologies开发和维护，目前支持Eclipse 3.0和.NET Framework 1.1。
首先，我们需要在本机安装.NET Framework SDK和Eclipse。
接下来我们通过Eclipse和一个update site来下载和安装该插件：在Eclipse的工作台选择Help -> Software Updates -> Find and Install...，选择Search for new features to install，选下一步，点New Remote Site...，输入一个名称和如下的URL：
http://www.improve-technologies.com/alpha/updates/site.xml
点完成，这时Eclipse就会开始载入上述XML文档并查找相关信息。需要注意的是这个site.xml实际上同时包含了Improve Technologies的其他插件，我们并不需要。在接下来的Search Results页面，我们只用勾选C Sharp的条目即可。选好以后点Finish，这个时候Eclipse就会开始安装这个插件，完成后会提示是否重启Eclipse，选是。
重启Eclipse之后，我们作最后的一些配置。打开Window -> Preferences，我们可以看到新增的C# Preferences，在这里可以指定C#编译器类型和位置，如：C:/WINDOWS/Microsoft.NET/Framework/v1.1.4322/csc.exe
大功告成，我们来试验一把。
新建一个空白项目，在项目中选New -> Other，或者用快捷键Ctrl + N，选择C#目录的C# File创建一个新的C#文件，输入一些测试代码，选保存，这时默认会自动编译该文件，我们可以在下方的%cSharpConsoleView中看到编译器的信息，如果一切顺利，在我们的Project目录下面就会多出来一个exe文件，双击这个exe文件，我们的C#程序就可以跑起来了。补充说明：我们可以右键cs文件，选Properties（Alt + Enter）来指定输出文件类型和其他命令行参数等。
这个插件实现的功能其实相当有限，基本上只是利用现有的compiler，然后把一些操作简化了，然后有一些syntax highlight的功能，甚至也结合compiler做了一些代码级的简单错误提示。但是它不失为一个有趣的插件。
我用作测试的代码如下：
using
System;
namespace
MainNamespace
{
public class MainEntry { public static void Main() { // Add your code here Console.WriteLine("To test C# plugin in Eclipse"); for (int i = 0; i < 10; i ++ ) { Console.WriteLine(" # " + i + " # ");
} Console.ReadLine(); } }
}
Just for fun.
用这个插件来做一些简单的验证和思路整理是可以的，如果真的要选一款免费的C# IDE做开发用，我想我会考虑SharpDevelop。
posted @ 2005-03-22 22:49 大胃 阅读(66) | 评论 (0) | 编辑 收藏
目前Eclipse的最新的正式发布（release）版本是3.0.1，这个3.0的版本是在2.1的版本已经流行了很长时间以后才迟迟推出的，不论是核心功能还是界面都有了极大的更新。不过在我看来，它有一个很大的遗憾，毕竟不是SUN乐意推行的产品，在这个重大版本提升时，没有包含对J2SE 5.0的支持。不像NetBeans，仿佛确切知道J2SE 5.0具体的发布时间一样，几乎在J2SE 5.0发布的同时推出全新的4.0版，并毫不掩饰的自豪的宣称自己是首款完全支持J2SE 5.0的Java IDE。还好，Eclipse项目毕竟有多年积淀下来的支持者和开发资源，在迈向3.1的各个版本中，对J2SE 5.0的支持得以逐步完善，至今已经推出3.1M5a版，其对J2SE 5.0在各个子系统的支持也都基本到位了。
那么这个即将到来的3.1正式版本升级有些什么东西值得我们期待和关注呢？当然还是来自eclipse.org官方的文档资料最有权威，有兴趣的朋友可以直接看：
http://eclipse.org/eclipse/development/eclipse_project_plan_3_1.html
在我的blog中，我只选取其中一部分我感兴趣的为大家介绍。
首先，大家需要留意如下三个计划中的时间点：
I – 2005年4月1日 # 发布3.1 M6版
II – 2005年5月13日 # 发布3.1 M7版
III – 2005年6月下旬 # 正式发布 3.1 release版
其次，文档中还提到分别对于其三个子项目，平台、JDT和PDE都有哪些相应的改善，这些条目分为三类：[确定]要包含在3.1中的，[考虑]要包含在3.1中的，以及[不打算]包含在3.1中的，所幸的是目前还没有第三种。我们简单浏览一下JDT[确定]要包含的条目：
I – 增加对J2SE 5.0的完整而全面的支持
II – 增强的编译器检查
III – 提供增强的外部字符串编辑功能，如单独的properties文件编辑器
IV – 将一些Java编辑器的功能开放给平台级的文本编辑，如超链接式的浏览，拼写检查等
V – 增强的调试器功能，如从stack trace超链接到代码的能力
VI – 导入和导出ANT构建文件，比如从ANT脚本导入完整的项目和从项目导出完整的脚本
不知道大家对这个新版本的Eclipse持什么态度，笔者是充满期待，呵呵。
posted @ 2005-03-21 21:25 大胃 阅读(83) | 评论 (1) | 编辑 收藏
本文部分内容和灵感来自eclipse.org网站，特此声明。更多内容，请参考：
http://eclipse.org/articles/Article-SWT-Design-2/SWT-Design-2.html
由于SWT直接跟操作系统打交道，所以我们需要在处理系统的图形资源时格外小心，以免不必要的资源泄漏。所幸SWT提供了很好的资源管理机制，我们绝大多数情况下需要做的只是确保两条原则：
第一条原则 – 谁分配谁销毁
第二条原则 – 父控件销毁的同时销毁子控件
下面我们分别来看一看这两条在实际中是如何体现的。
先看第一条原则。乍一看这似乎是废话，但是在实际中往往并非那么简单。首先，构造方法不等于分配资源，实际上分配资源可以发生在一个类中的任何地方以及一个对象生命周期的任何时候，只要你的代码告诉操作系统这样做。你必须保证所有由你分配的资源当你不再使用时调用其dispose()方法；同时你也必须保证所有不是由你分配的资源不要随便调用其dispose()方法，否则很可能会影响到实际分配的那段相关代码的正常工作。好消息是，为了明确和简化这第一条原则所规定的分工，SWT在设计之初就确定下来，所有基于系统资源的SWT类都在其构造方法中完成所有所需的资源分配，在其他方法中则没有任何分配系统资源的动作，所以我们可以幸运的这样看待SWT的资源管理：如果你调用了某个SWT类的构造方法，那么就由你来调用其dispose()方法释放资源；如果你没有调用某个SWT类的构造方法，即便你使用了这个类的实例，也不应该由你来调用其dispose()方法。就是这么明确。
比方讲，你new了一个Font对象，那么当你不再需要它时，就应该调用dispose()；如果你通过某个控件的getFont()方法取得一个Font对象并使用后，你不应该去销毁它，而应该交给那个具体的控件去处理。
对于第二条原则，SWT有一个很好的机制去支持它，那就是，所有的SWT控件，具体讲，Composite类及其子类的实例，都必须有一个父控件，这个父控件的引用在子控件的构造方法中被传入。需要注意的是，所有这些控件的不带参数的构造方法都只有默认访问级别，于是我们不能在自己的SWT程序中直接调用这样的默认构造方法而只能提供一个父控件的引用，而在Widget类（Composit的父类）的带参数构造方法中，它会调用如下方法：
void
checkParent (Widget parent)
{ if (parent == null) error (SWT.ERROR_NULL_ARGUMENT); parent.checkWidget ();}
进而：
protected
void
checkWidget ()
{ Display display = this.display; if (display == null) error (SWT.ERROR_WIDGET_DISPOSED); if (display.thread != Thread.currentThread ()) error (SWT.ERROR_THREAD_INVALID_ACCESS); if ((state & DISPOSED) != 0) error (SWT.ERROR_WIDGET_DISPOSED);}
这样的检查保证了任何控件在创建时都有父控件。当我们调用某个Composite的dispose()方法时，它会调用：
void
releaseChildren ()
{ Control [] children = _getChildren (); for (int i=0; i<children.length; i++) { Control child = children [i]; if (!child.isDisposed ()) child.releaseResources (); }}
其中的_getChildren()方法通过OS对象的方法遍历控件的子控件，然后汇总到一起分别调用releaseResources()方法释放控件和句柄。
回到上次的SimplestSWT的例子：
package sean.test.swt;import org.eclipse.swt.widgets.Display;import org.eclipse.swt.widgets.Shell;
public
class
SimplestSWT
{ public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } display.dispose(); }}
这当中，Display是一个顶层的设备，它继承自Device类，而Device类实现了Drawable接口。Shell的父类是Decoration，而Decoration继承自Canvas，Canvas继承自Composite，最终这条继承链一直连到Widget类。我们在创建Shell示例的时候，需要告诉构造方法它的父控件是什么，在这里就是display。于是当我们最后调用display.dispose()时，虽然我们没有明确写shell.dispose()，我们的Shell实例也随之销毁了。
这就是SWT的资源管理机制，稍有例外的是MenuItem的setMenu()方法和Control的setMenu()方法，它们通过显式调用setMenu的方式注册自己的父控件。
posted @ 2005-03-20 17:11 大胃 阅读(100) | 评论 (0) | 编辑 收藏
本文部分内容和灵感来自eclipse.org网站，特此声明。更多内容，请参考：
http://eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html
众所周知，SWT与Swing最大的不同就是它直接使用操作系统提供的现成的本地图形接口，于是具备本地化的Look & Feel。但是它是怎么做到这一点的呢，当然是通过JNI。我们来看一个例子，假定我们使用Win32的API。
我们现在有一个文本框text，通过如下的代码，我们给它一个字符串，并让它选择/highlight从3~5（[3,5]）的字符。
text.setText(“abcdefgh”);text.setSelection(
3
,
6
);
在Windows下，这个setSelection方法是怎么实现的呢？我们可以看看源码：
public
void
setSelection (
int
start,
int
end)
{ … OS.SendMessage (handle, OS.EM_SETSEL, start, end); OS.SendMessage (handle, OS.EM_SCROLLCARET, 0, 0);}
做过Windows编程的朋友可能一下子就认出了这个SendMessage，这不就是Win32 API中用于向窗体发送消息的函数吗？呵呵，没错，我们再来看一下这个SendMessage方法的原型：
public
static
final
int
SendMessage (
int
hWnd,
int
Msg,
int
wParam,
int
lParam)
{ if (IsUnicode) return SendMessageW (hWnd, Msg, wParam, lParam); return SendMessageA (hWnd, Msg, wParam, lParam);}
public
static
final native
int
SendMessageW (
int
hWnd,
int
Msg,
int
wParam,
int
lParam);
public
static
final native
int
SendMessageA (
int
hWnd,
int
Msg,
int
wParam,
int
lParam);
我们看到了两个版本，一个版本针对Unicode，另一个版本针对ASCII，正好Win32 API也是如此，我们在这里看到的是native的方法，这意味着具体还有一组JNI的C代码来直接与操作系统的函数打交道：
#ifndef NO_SendMessageW__IIIIJNIEXPORT jint JNICALL OS_NATIVE(SendMessageW__IIII) (JNIEnv
*
env, jclass that, jint arg0, jint arg1, jint arg2, jint arg3)
{ jint rc; OS_NATIVE_ENTER(env, that, SendMessageW__IIII_FUNC); rc = (jint)SendMessageW((HWND)arg0, arg1, (WPARAM)arg2, (LPARAM)arg3); OS_NATIVE_EXIT(env, that, SendMessageW__IIII_FUNC); return rc;}
#endif
#ifndef NO_SendMessageA__IIIIJNIEXPORT jint JNICALL OS_NATIVE(SendMessageA__IIII) (JNIEnv
*
env, jclass that, jint arg0, jint arg1, jint arg2, jint arg3)
{ jint rc; OS_NATIVE_ENTER(env, that, SendMessageA__IIII_FUNC); rc = (jint)SendMessageA((HWND)arg0, arg1, (WPARAM)arg2, (LPARAM)arg3); OS_NATIVE_EXIT(env, that, SendMessageA__IIII_FUNC); return rc;}
#endif
看到这里，你也许已经恍然大悟：SWT所做的无非就是把Win32的API简单的包装了一下，我们在SWT这一层调用的方法、传递的参数被原封不动的代理到了Win32层。这就是SWT的核心思想。SWT有一个很重要的设计原则，那就是，SWT的API一对一的封装OS的API，完全忠实于操作系统的API实现的行为，如果有bug，那也是OS的bug，它不会尝试去“纠正”操作系统，因为那样会潜在的破坏本地化的一些行为。忠实于OS也使得调用者不必但心自己的SWT程序会跟OS的本地GUI有不一致的地方，如有必要直接参考MSDN即可。SWT其实就是这样一个thin wrapper，我们通过它可以方便的访问Win32的图形API，为我们的应用程序提供native的Look & Feel。
下面给出一个完整的SWT示例：
package sean.test.swt;import org.eclipse.swt.SWT;import org.eclipse.swt.layout.FillLayout;import org.eclipse.swt.widgets.Display;import org.eclipse.swt.widgets.Shell;import org.eclipse.swt.widgets.Text;
public
class
DummySWT
{ public static void main(String[] args) { final Display display = new Display(); final Shell shell = new Shell(display); shell.setLayout(new FillLayout()); final Text text = new Text(shell, SWT.SINGLE); text.setText("abcdefgh"); text.setSelection(3, 6); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } display.dispose(); }}
posted @ 2005-03-20 15:06 大胃 阅读(99) | 评论 (0) | 编辑 收藏
本文假定读者使用Windows操作系统+JDK 1.4，其他平台和JDK版本应该也是八九不离十。
为了编译和运行SWT程序，我们有两种选择：1- 使用Eclipse SDK；2- 下载单独的SWT二进制文件和源文件。
随Eclipse SDK，我们可以在它的plugins目录下找到SWT的二进制文件，通常的目录名称是：org.eclipse.swt.win32_xxxx，后缀是版本号，在这个目录下有os和ws两个子目录，内容分别是SWT的JNI库和swt.jar。
如果不是使用Eclipse来开发，或者需要SWT的源文件，那么需要下载单独的SWT二进制和源文件包，在下面的地址可以找到：
这个zip文件解包以后包含JNI库（一些DLL）和swt.jar，以及swtsrc.zip，这个swtsrc就是我们SWT的源文件了，包括C和Java的源代码。
为了运行SWT程序，我们需要首先编译我们SWT的代码，这个时候需要告诉编译器swt.jar的位置；编译成功以后，我们除了指明classpath包含swt.jar之外，需要在命令行告诉java.exe另一个参数，那就是java.library.path，看上去大概是这个样子：
java -cp %SWT_HOME%/swt.jar SimplestSWT -Djava.library.path=%SWT_HOME%
如果你使用的是Eclipse SDK 3.1M5a或者更新的版本，你可以直接右键.java文件选择Run As -> SWT Application，则不用在命令行写那么长的参数了。
比较有意思的是，我们可以在eclipse.org的SWT下载页面看到目前SWT支持的平台：
呵呵，支持的平台虽然有限，不过还是蛮多了。
posted @ 2005-03-20 01:05 大胃 阅读(79) | 评论 (0) | 编辑 收藏
2696
1269
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
