java的gui(一)
注：该文章只是一个尝试。
一直在想办法以一种良好的方式省时省事地记录自己的思维，系统地管理学到的知识，试过不少方法，都不凑效
本文将试着从开始着手看一个问题开始，每一步都跟踪自己的思维，记录相关的资料的出处
因为工作中会经常用到java的gui，一直在找一个契机，去学习一下java的gui相关知识。
在看到《java concurrency in practice》的第九章第一节：Why are GUIs Single-threaded？时，这个等待了许久的契机终于出现了。
这里先简介一下该章第一节的内容（根据自己的理解，着重点可能与该章节不相同）：
1.单线程的gui框架并不是唯一的，除了java，像Qt, NextStep, MacOS Cocoa, X Windows都是用单线程的
2.不缺乏对多线程gui框架的尝试，但基本都以失败告终了，为什么不能够用多线程？
原因有两个：
a.两类不同形式的运行动作，让多线程的gui天生就趋向于死锁：一类是自上向下的，如改变字体颜色，这个命令会从应用层一直往下走，一直到操作系统，然后执行渲染工作，一类是自下向上的，如鼠标的点击，从用户点击，到操作系统封装的事件，一直往上走，直到应用程序，根据死锁产生的原因之一：两种相反方向的加锁（可参考《java concurrency in practice》第十章），这两种gui所不可能避免的动作必然会导致死锁
b.mvc模式，我们知道，c可以改变m，然后反应到v上去，c也可以调用v的接口，让v去对m进行查询，这其实也是反向加锁的两种动作
3.简述了EDT的一些缺点（长任务）和限制（更新gui的操作应该都由EDT来执行）
其中，为什么不能够用多线程的两个原因中第一个原因，文章提供了一篇拓展阅读，但文中的地址有点问题，正确的地址应该是：Multithreaded toolkits: A failed dream?
懒得看英文的朋友可以下载附件（虽然翻译水平差了点，但应该意思是到位了）
文章其实也没说太多内容，主要还是针对于上述原因1做一些详细的论述，但也根据该文章了解到了这样一些内容
a.awt初衷是设计多线程的，但最后发现无法兑现承诺，之后做的swing是单线程的。
b.不能用多线程的根源性问题在于上述原因1，即使这些工具包的开发者很聪明，很仔细，也是无法避免的
c."failed dreams"的含义:一个梦想，虽然事实上是无法达到的（人们其实不会都这样认为），但是不断地有人，很多的人去为这个梦想去付出努力，让这样一个梦想无限地趋向于实现（当时查了之后有点热血沸腾的感觉）
d.多线程的gui不一定是不可实现的，但他需要开发者足够地有天份，了解工具包的细节，了解每一个并发的过程，但作为一个用于商业的组件，显然是不现实的。
看完了文章，也基本得出了接下来的学习的一个方向：深入awt和swing工具包（因为根据上述文章的描述，awt起初是设计为多线程的，同时至今它也是线程安全的，而swing是参考了awt的设计做的，用的是标准的单线程的事件队列）
于是，基于了解java gui框架的目的，在网上经过简单搜索后发现这么两篇文章：
java 2用户界面
SWT、Swing 或 AWT：哪个更适合您？
又学到了这样一些内容
1.awt提供的组件是各类操作系统的一个交集
2.swing提供的组件是各类操作系统是一个并集
swing和awt都可以实现平台的无关性（也就是java的本质），而swt据说可以，但实际上没做得swing跟awt好
由于目标是了解awt和swing的整体的结构，所以对一些细节问题没太留意，因此在这两篇文章中学到的也十分地有限
由于找不到太有用的资料，只能从java api的包的树结构开始去学习，发现swing中比较重要而基础的JComponent是继承自awt的Component的，所以决定从awt包看起
于是找了比较简单的类开始入手——Label
1.该类的确应该是设计为线程安全的，里面大部分方法都做了锁的相关操作
2.该类很简单
3.发现一个叫“peer”的概念（对等体）
于是大概翻了下Component的源码，发现处处有peer的痕迹，于是很自然地了解到搞懂peer的概念可能是读懂awt的关键
于是很幸运地找到了这篇文章
细说Java GUI：AWT，SWT，Swing
英文原文
里面有用的内容非常多，在这里稍微整理一下作为以后回忆的笔记：
1.原生组件和模拟组件
原生组件：也就是调用本地方法，使用操作系统提供的api，awt就是典型的代表
模拟组件：swing的做法，自己模拟画图
2.历史：java的swing是由IBM以前的对头公司的开发团队来开发的，swt是由ibm开发的
3.java本质：write once, run anywhere
swt在平台兼容性方面是比不上awt和swing的
“尽管Steve Northover，SWT之父，辩称SWT是平台无关的，你可以很容易地发现许多Windows API的痕迹。”
4.awt用的是原生组件，它支持的组件是java所有操作系统的交集，而swing跟swt是并集，具体实现上swing大部分（除了顶层容器）都用模拟组件（纯java实现），而swt是只有平台不支持的才用模拟
5.对等体（peer）：awt中主要使用的是对等体实现平台无关性，它的主要行为也是由对等体来调用jni来实现的（主要的行为都发生在这里），这也解释了为什么源码中只有极少的代码
6.swt也使用了对等体，但实现方式跟awt有所不同，区别在于一个是纯jni实现，一个在jni的基础上封装了一层，以达到多个操作黏合在一起形成一个更有意义的操作
7.swing没有使用jni，“Swing将组件自己的数据结构存储在JVM的空间中。它完全由自己管理画图处理，事件分发和组件布局。”它的底层是java 2D的api[/b]
8.swt需要显性地释放资源，awt由系统管理
9."Swing组件在操作系统中没有相应的对等体。它只是一块顶层容器中的逻辑区域，实际上它从顶层容器的对等体中借用资源。"
"Swing组件与顶层AWT容器共享一个对等体。"
"当操作系统开始更新UI的时候，顶层容器和Swing组件总是先于AWT组件绘制。当它们完成绘制，AWT组件会覆盖Swing可能绘制过的地方。因此不提倡Swing和AWT组件的混用。"
10.look and feel观感（不太了解具体含义，是否是指类似renderer，editor这样的？）：原生组件无法完成的东西，因为它依赖于操作系统的实现，但模拟组件却是可以模拟任何不存在的组件。
"Java 2D在Java中是强大的类库，它为高级图像处理，颜色管理，图形绘制和填充，坐标系变换和字体生成提供丰富的特性"
11.又谈到了多线程与单线程模型
12.谈到了想要仔细了解的一个重点：事件分发线程
"AWT读取操作系统中的基本事件并在java代码中处理它们。AWT事件分发线程被命名为?AWT-{OS}-Thread。这个线程由AWT系统隐式启动。当AWT应用程序启动时，这个线程在背后启动，在操作系统上抽取和移除事件。当诸如按钮动作这样的逻辑事件被触发时，它传递给注册在按钮上的操作监听器。开发者也能为AWT组件编写鼠标，键盘和绘制事件的事件监听器。这通常通过扩展AWT Canvas组件来完成。这一组件支持了所有已提供的事件，而且你可以通过重写事件处理方法，实现一个自定义的组件。"
"然而，在Swing中，这是一个不同的线程。Swing把AWT事件作为自身事件系统的一个输入。它获取AWT事件并做一些初始化处理，产生一个对应的Swing事件并把它放到自己的事件队列上。Swing也有自己的事件分发线程，通常命名为EventQueue-0。这个线程从事件队列中抽取Swing事件，就如同AWT从操作系统中抽取那样。然后它把事件分发给目标组件。通常事件首先被分发给组件的顶层容器，然后由顶层容器的dispatch方法处理，它可能被再分发或重定向到一个Swing组件，在那里继续由自己的监听器进行处理。"
"SWT更类似于AWT。唯一的区别是它要求开发者显式地书写事件循环代码。然而底层的实现细节是不同于AWT的。看看SWT的读取和分发事件代码，它会让你想起MFC的代码风格。"
"AWT，SWT和Swing都有相似的事件监听器模型。它们都使用观察者模式，组件和监听器的连接方式是把监听器添加到组件上,这组成了一个对象网络的模型。当事件被触发并分发给组件，组件调用它的监听器以处理事件。一个监听器也可以继续分发事件给后续的处理，或产生一个新的事件并把它广播到网络中的其他节点上。基本上有两种不同的广播事件方式。一种是同步调用监听器。另一种是异步地将事件发送回队列，它将在新一轮的事件分发中被分发出去。
除了直接发送给队列的方式，Swing还有一些其他的分发异步事件的方法。其中之一是调用SwingUtilities 或EventQueue 的invokeLater，这一方法包装一个Runnable对象到事件中并把它发送给事件队列。这确保了Runnable的run方法能在事件分发线程上执行，保证了线程安全。实际上，Swing的Timer好SwingWorker基于这一机制实现。SWT也有相应的发送异步事件的方式。它的invokeLater的对应方法是display.asyncExec，它以一个Runnable对象作为参数。"
最后两段的内容其实《concurrency in practice》也提到了，而且讲得还详细些。
13.系统地描述了awt，swt，swing各自的优劣[/b]
基本也就是原生组件跟模拟组件各自的优劣
14.swing扩展组件的方法：
A.继承已有组件；
B.靠复合组件的方式扩展。
C.从零开始使用JComponent编写自定义组件；
D.使用渲染器和编辑器机制扩展复制的Swing组件，如JList，JComboBox，JTable，JTree等；
E.基于已有Look And Feel 或从零开始创建新的Look And Feel；
F.使用LayeredPane，GlassPane或拖放机制开发高级的组件，例如浮动的固定组件，自定义弹出窗口，自定义菜单等。
15.数据输送时间：数据输送时间是指用于将应用程序数据传递给UI组件所需要的时间。例如，一个学生管理系统要求从数据库中装载学生信息并在一个表格中显示出来。花费在从内存到表格组件的数据传递时间被称为数据输送时间.
在数据传送时间上，swing更有优势，
a.swing有许多设计良好的组件模型（model）
b.swing相比awt和swt少了一个从jvm到操作系统的数据转换过程（awt/swt需要从操作系统到jvm，然后再从jvm到操作系统，swing是直接画出来）
看完该文章后，再次定位到三个学习目标
1.事件分发线程和它的观察者模式是了解awt的关键（其他的就是原生组件引用peer的事了），同时swing也需要了解这一点，swing相当于是在awt的事件线程上做的第二次的分发
2.java 2D的实现：也就是渲染的过程（这一点需要权衡一下，如果需要占用太多时间，可只是基本了解或者放弃，个人认为与操作系统关联性会很高，而且以后用到的机会少）
3.据文章描述，swing的api是设计得非常良好的api，参考它的可扩展性设计可能会对以后的工作有很大的帮助
接着，自然是先找到这个事件线程了，然后看它事件是怎么收的，然后又怎么进行分发的，然后是每个组件收到事件后怎么做，或者说怎么进行二次分发？
怎么找事件线程？用了个很简单的办法，写了点测试代码，然后debug，直接就得到了调用栈，然后找到了这个事件调度线程：EventDispatchThread
再往深点看一下，因为关联了jdk的源码，直接断了个断点在EventDispatchThread的构造函数中，然后又得到了EventDispatchThread的创建的调用栈
从最底部的main看起，发现了一件有点意思的事情（Component中的）
show方法是被废弃掉的，但推荐使用的setVisible居然调用的是show()~，那废弃干嘛呢？
