J2SE,J2ME,J2EE 的2 指Java1.2以后的版本,因为这个版本有个质的飞越,其中包括双亲委派模型

se

me

GUI

AWT

最大公约数的办法,只提供所有os都有的控件

Swing

后来SUN改变做法,Swing 里除了JFrame,JWinodows,JDialog 调用本地os控件,其它JPanel,JButton之类都是绘出来的

一切都自己搞定没有依赖,所以离“一处编写,到处运行”也更近了一步

保持外观一致性,但牺牲了性能

Swing的look and feel 可以改变风格

Swing就像Java决定不通过os来实现原生的IO,而是通过磁头马达API自己来读磁盘的扇区

喜爱Swing的人总会说“一旦你花上几年时间去掌握它,你就能正确地使用它”,这基本上是他们在试图证明和维护他们辛苦得来的用途有限的专门技术

SWT

IBM更喜欢AWT的实现机制,做出了SWT

最小公倍数的做法

大部分用本地os控件,没有的才自己绘制

类似 jvm ,不同平台有不同的开发包(so,dll)

不同平台下会有不同差别,“一处编写,到处调试”。。。

外观不一样,但性能提升很高

JFace

SWT的延伸拓展,更高级更强大,例如一些对话框JFace提供了原型,而用SWT的话就得先画shell再往里面放控件自己动手画

比如要显示一个对话框,就要自己去画【确定】、【取消】按钮,要弹出消息对话框就要自己去写数行代码

为简化SWT开发,JFace就是调用SWT实现了更多实际应用开发中要用到的公共类

SWT和JFace的关系就像Windows开发中Windows SDK和MFC的关系一样

比如实际开发时可尽量去使用JFace的东西,只有当JFace的东西不满足要求的时候才去直接求助SWT

RCP

可定制出基于 Eclipse的的产品,比如 rational ROSE

传言

SUN 习惯于公开把他们的bug归咎为操作系统的差异,好让批评的火力从SUN太早释出代码这个问题的真相上移开

原生和仿造两派的死战,两家公司在一整年里除了吵架什么都没做

IBM 原来搞Smalltalk的那一批人,对管理层要求用Swing构建WebSphere Studio非常不情愿,与Microsoft Visual Studio作对比演示的时候,所有的客户都讨厌它,就因为它的外观

读事件队列的时候用了一种可能留下内存漏洞的方式,得用自己的查询Windows事件队列的循环,SUN的Amy导致一直不修复这个错误,导致SWT和AWT/Swing不能共存

甚至在SWT中定义了自己的Point和Rectangle类——整个工具包对AWT或Swing都没有任何依赖。这个工具包放到了Eclipse中

Smalltalk

70年代初Xerox 开发

历史公认第二个面向对象语言,和第一个真正的集成开发环境(IDE),它不仅仅是一门语言

对众多语言的产生起到了极大的推动作用,:C++,C#,Objective-C,Actor,Java,Ruby等

90年代的许多软件开发思想得利于Smalltalk,如设计模式、敏捷编程和代码重构等

感受下和 java 的区别

消息传递

Smalltalk使用消息传递,而不是方法调用

区别是微妙的,但是非常强大

foo bar:baz

当线的执行时,foo发送消息#:bar:带有参数baz

Java中,像foo.bar(baz)

Java运行时找出foo的实际类型,找到最合适的方法,并运行它

Smalltalk向对象发送消息时,它在方法字典中搜索名称与消息选择器名称匹配的方法。找不到,继续搜索超类的方法字典,再找不到,发送自己的#doesNotUnderstand 消息,原始消息作为参数 (是的,消息发送是一个对象)

但#doesNotUnderstand:也只是一个方法。可以覆盖它

几个不同的角度解释Smalltalk

编译器通常产生在虚拟机上运行的二进制代码

和许多语言不同(包括C++),Smalltalk附带有一个巨大的标准类库

其它语言(如C和Pasca)中通常作为语言的一部分的功能(例如条件判断,循环等),在Smalltalk由特定的类提供

高度集成的IDE,有浏览器、监视器以及调试器

取消原始(primitive)方法直接访问内存的能力

引入元类概念

引入MVC系统以方便交互式应用软件的开发

数学计算

(15 * 19) + (37 squared)

向15发送消息,参数为19

向37发送消息squared

最后向15*19的结果发送消息’+‘,参数为37 squared的结果