关于Java GUI 和事件处理线程的问题

qusic 2010-06-23 04:29:40
下面是sun网站上JLayeredPaneDemo的代码片段
我的问题是,为什么要在事件处理线程上调用createAndShowGUI()?
为什么要在事件处理线程上初始化程序?

private static void createAndShowGUI() {
//Create and set up the window.
JFrame frame = new JFrame("LayeredPaneDemo");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

//Create and set up the content pane.
JComponent newContentPane = new LayeredPaneDemo();
newContentPane.setOpaque(true); //content panes must be opaque
frame.setContentPane(newContentPane);

//Display the window.
frame.pack();
frame.setVisible(true);
}

public static void main(String[] args) {
//Schedule a job for the event-dispatching thread:
//creating and showing this application's GUI.
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});
}

...全文
353 21 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
21 条回复
切换为时间正序
请发表友善的回复…
发表回复
zhuyouyong 2010-06-29
  • 打赏
  • 举报
回复
顶[Quote=引用 1 楼 healer_kx 的回复:]
都一样,main里面直接new也OK。
[/Quote]
xierangh 2010-06-29
  • 打赏
  • 举报
回复
我翻译的不好的地方大家多多担待。请多多指教。

Why did we implement Swing in this way?
为什么我们要这样实现Swing呢?There are several advantages in executing all of the user interface code in a single thread:
因为在一个线程里执行用户界面代码有以下优点:
* Component developers do not have to have an in-depth understanding of threads programming: Toolkits like ViewPoint and Trestle, in which all components must fully support multithreaded access, can be difficult to extend, particularly for developers who are not expert at threads programming. Many of the toolkits developed more recently, such as SubArctic and IFC, have designs similar to Swing's.
*组件开发人员不需要深入理解线程编程:像ViewPoint和Trestle这样的工具包,它们之中的所有组件必须完全支持多线程访问,所以很难运用它们来编程,特别是不精通线程编程的开发人员。许多像SubArctic和IFC这样最近开发的工具包都和Swing有相似的设计。

* Events are dispatched in a predictable order: The runnable objects enqueued by invokeLater() are dispatched from the same event queue as mouse and keyboard events, timer events, and paint requests. In toolkits where components support multithreaded access, component changes are interleaved with event processing at the whim of the thread scheduler. This makes comprehensive testing difficult or impossible.
*用一个可以预见的方式来分发事件:invokeLater()通过分发同一事件队列中的运行对象像鼠标和键盘事件、计时器事件和画图请求来进行排队。一个在支持多线程访问的工具包中的组件改变是错综复杂的因为事件是按各自线程调度(就是具有不可预见性)来进行的。这就使得全面的测试困难或者不可能实现。
* Less overhead: Toolkits that attempt to carefully lock critical sections can spend a substantial amount of time and space managing locks. Whenever the toolkit calls a method that might be implemented in client code (for example, any public or protected method in a public class), the toolkit must save its state and release all locks so that the client code can grab locks if necessary. When control returns from the method, the toolkit must regrab its locks and restore its state. All applications bear the cost of this, even though most applications do not require concurrent access to the GUI.
*减少开销:工具包要花费特别巨大的时间和空间去管理那些工具包小心翼翼给危险局域加的锁。当这个工具包调用一个客户端编写的方法时,工具包必须保存自己的状态和释放所有需要释放的锁,以便客户端获取锁。当调用客户端代码完毕时,工具包必须重新获得刚才释放的锁和加载刚才的状态。(这是非常耗时间和空间的事情,而且对于不精通线程编程的人来说是一个灾难。而且在维护的时候也是非常困难的。)这些消耗在所有应用程序中都是占非常大的,甚至使得很多应用程序不能够顺利的进行图形界面操作。

Here's a description, written by the authors of the SubArctic Java Toolkit, of the problem of supporting multithreaded access in a toolkit:
这是SubArctic JavaToolkit作者写一个支持多线程访问的工具包中问题的说明:
It is our basic belief that extreme caution is warranted when designing and building multi-threaded applications, particularly those which have a GUI component. Use of threads can be very deceptive. In many cases they appear to greatly simplify programming by allowing design in terms of simple autonomous entities focused on a single task. In fact in some cases they do simplify design and coding. However, in almost all cases they also make debugging, testing, and maintenance vastly more difficult and sometimes impossible. Neither the training, experience, or actual practices of most programmers, nor the tools we have to help us, are designed to cope with the non-determinism.
极度谨慎是我们的基本信念当设计和编写多线程应用程序时,特别是那些有图形界面组件的应用程序。线程使用具有非常的欺骗性。在很多项目它们显得非常容易编写通过允许设计简单独立的针对一个单独任务的实体对象。(就是说设计一个线程处理一个任务,这个任务中只有一个实体对象)实际上在有些项目线程让设计和编码更加简单。然而几乎所有的项目线程都使调试、测试和维护变得更加困难得多或者不可实现。大多数程序员的培训、经验或者实战练习和专门为不是决定性判断的工具都不能帮助我们(大多数程序的努力(天才除外比如像他们这些编写人员,不过对脑细胞具有非常的杀伤力)和专门的工具都不能帮助我们解决前述多线程引起的问题)。
For example, thorough testing (which is always difficult) becomes nearly impossible when bugs are timing dependent. This is particularly true in Java where one program can run on many different types of machines and OS platforms, and where each program must work under both preemptive or non-preemptive scheduling.
例如,当bugs和时间相关联时,测试几乎无法进行。这一点在Java上尤其突出因为Java做出来的程序是跨平台的,它可以在不同类型的机器和不同操作系统上运行,程序也必须在抢占式和非抢占式调用下运行。(如果bug因为时间关系才能出现,那么测试这个代码几乎是不可能的事情。这一点在Java上表现出来就特别明显。因为Java是跨平台的,所以就需要面临不用的机器和操作系统,随之而来的是不同的调度方式(抢占式和非抢占式)。所以呢,如果事件是同时被触发而且没有一个队列来保证它们的先后顺序,那么结果就可想而知了。不同操作系统的调度方式不一样造成事件处理的先后顺序不一样,那么结果也不一样。)
As a result of these inherent difficulties, we urge you to think twice about using threads in cases where they are not absolutely necessary. However, in some cases threads are necessary (or are imposed by other software packages) and so subArctic provides a thread-safe access mechanism. This section describes this mechanism and how to use it to safely manipulate the interactor tree from an independent thread.
由于这些固有的问题(实现的时候的困难),我们建议你在项目中使用多线程前多想想如果不是必须使用多线程的时候。然而,在一些项目中多线程是必须的,所以subArctic提供了以个线程安全的访问机制。这部分详细说明了这个机制和怎么去安全的使用它们。
The thread-safe mechanism they're referring to is very similar to the invokeLater() and invokeAndWait() methods provided by the SwingUtilities class.
这个线程安全机制就是被大家经常提到的SwingUtilities提供的invokeLater()和invokeAndWait()方法。
qusic 2010-06-29
  • 打赏
  • 举报
回复
我引用的那篇文章有没有人能给翻译一下啊,总是觉得那篇文章很有用的说....
xierangh 2010-06-29
  • 打赏
  • 举报
回复
是让程序更好的支持跨平台。
把初始化程序放在事件处理线程上就已经在Java虚拟机上决定了界面程序的初始化顺序。不会造成执行顺序不确定的情况。
[Quote=引用楼主 qusic 的回复:]
下面是sun网站上JLayeredPaneDemo的代码片段
我的问题是,为什么要在事件处理线程上调用createAndShowGUI()?
为什么要在事件处理线程上初始化程序?

Java code

private static void createAndShowGUI() {
//Create and set up the window.
……
[/Quote]
qusic 2010-06-24
  • 打赏
  • 举报
回复
呀?咋没人来了呀
ronniegxq 2010-06-24
  • 打赏
  • 举报
回复
不会。。。。。。。。。。
dracularking 2010-06-24
  • 打赏
  • 举报
回复
invoke系是将事件在event-dispatching thread执行,看EventQueue.class
正好学习一下

/**
* Posts a 1.1-style event to the <code>EventQueue</code>.
* If there is an existing event on the queue with the same ID
* and event source, the source <code>Component</code>'s
* <code>coalesceEvents</code> method will be called.
*
* @param theEvent an instance of <code>java.awt.AWTEvent</code>,
* or a subclass of it
*/
final void postEventPrivate(AWTEvent theEvent) {
theEvent.isPosted = true;
synchronized(this) {
if (dispatchThread == null && nextQueue == null) {
if (theEvent.getSource() == AWTAutoShutdown.getInstance()) {
return;
} else {
initDispatchThread();
}
}
if (nextQueue != null) {
// Forward event to top of EventQueue stack.
nextQueue.postEventPrivate(theEvent);
return;
}
postEvent(theEvent, getPriority(theEvent));
}
}
huntor 2010-06-24
  • 打赏
  • 举报
回复
invokeLater 和 invokeAndWait 区别大了。
invokeLater 调用后直接返回
invokeAndWait 直到run方法被调用后才返回。
scelong 2010-06-24
  • 打赏
  • 举报
回复
invokeLater()与invokeAndWait()方法在功能上市一样的。从API上是看不出:为什么要把创建界面的代码放在此处,那么可以从源码上可以跟踪可知,最终是生成一个InvocationEvent事件,并调用其dispatch()方法,并把new Runnable(){....createAndShowGUI()}这个对象传进去,因此,如此写法就是在主线程外,重新创建一个线程来运行new Runnable(){....createAndShowGUI()}。。。!就算在此线程内抛出了错误,都不会对主线程产生影响!呵呵,希望能帮到楼主!

public class Tests {
public static void main(String[] args) throws Exception{
Runnable doHelloWorld = new Runnable() {
public void run() {
System.out.println("Hello World on " + Thread.currentThread());
try {
throwException();
} catch (Exception e) {
e.printStackTrace();
}
}
};
SwingUtilities.invokeLater(doHelloWorld);
System.out.println("This might well be displayed before the other message.");
JOptionPane.showMessageDialog(null, "DFDFDF");
}

protected static void throwException() throws Exception{
throw new Exception("Hello Exception");
}
}

dracularking 2010-06-24
  • 打赏
  • 举报
回复
Swing的事件处理代码是运行在事件分发线程(event-dispatching thread)之上的
为什么要这样,因为大部分Swing对象方法是非线程安全的,如果以多线程方式去调用的话就会造成线程间的干涉与内存不一致错误

在事件分发线程中执行就像一个排队机,在上面执行的代码就像一系列排队的任务(大部分任务都是调用事件处理方法,比如ActionListener.actionPerformed,其它任务就可以通过invokeLater或invokeAndWait来安排),任务如果不很快结束的话,就会造成未处理的事件拥堵累积且用户界面也会变得没有响应(paint方法也可以算是一个事件响应方法吧!?不管是不是,事件分发线程也是负责处理GUI drawing的)
xiangchang224 2010-06-24
  • 打赏
  • 举报
回复
UI线程是不可以阻塞的
dracularking 2010-06-24
  • 打赏
  • 举报
回复
swing单线程,非线程安全,基于这些考虑
1.多线程复杂,难掌握
2.单线程的话事件可以以可预测的顺序分发
3.更少花费

//Thread-safe example
public class MyApplication {
public static void main(String[] args) {
JFrame f = new JFrame(...);
...//Add components to the frame here...
f.pack();
f.setVisible(true);
//Don't do any more GUI work here.
}

...
//All manipulation of the GUI -- setText, getText, etc. --
//is performed in event handlers such as actionPerformed().
...
}



像这种也算线程安全的,因为它没有在主线程中涉及到影响或依赖已经realized了的组件的状态的代码
这里还是有很多值得研究啊
qusic 2010-06-24
  • 打赏
  • 举报
回复
慢慢的顶,才不容易沉
MSDBCSD 2010-06-24
  • 打赏
  • 举报
回复
有没有英文好的给解释一下咯~
qusic 2010-06-24
  • 打赏
  • 举报
回复
刚才在sun的网站上看了几篇关于这方面的文章,可惜咱英文不咋的,看不太明白。
下面就是说一定要在EDT上初始化GUI,可惜没给出深层次的说明。
[Quote]

Application Launch, Initialization, and Startup

You must create and initialize your GUI on the Swing event dispatch thread (EDT). Many application developers forget this important step.
[/Quote]
下面的或许有用,但是俺看不懂000
[Quote]

There are several advantages in executing all of the user interface code in a single thread:

* Component developers do not have to have an in-depth understanding of threads programming: Toolkits like ViewPoint and Trestle, in which all components must fully support multithreaded access, can be difficult to extend, particularly for developers who are not expert at threads programming. Many of the toolkits developed more recently, such as SubArctic and IFC, have designs similar to Swing's.

* Events are dispatched in a predictable order: The runnable objects enqueued by invokeLater() are dispatched from the same event queue as mouse and keyboard events, timer events, and paint requests. In toolkits where components support multithreaded access, component changes are interleaved with event processing at the whim of the thread scheduler. This makes comprehensive testing difficult or impossible.

* Less overhead: Toolkits that attempt to carefully lock critical sections can spend a substantial amount of time and space managing locks. Whenever the toolkit calls a method that might be implemented in client code (for example, any public or protected method in a public class), the toolkit must save its state and release all locks so that the client code can grab locks if necessary. When control returns from the method, the toolkit must regrab its locks and restore its state. All applications bear the cost of this, even though most applications do not require concurrent access to the GUI.

Here's a description, written by the authors of the SubArctic Java Toolkit, of the problem of supporting multithreaded access in a toolkit:

It is our basic belief that extreme caution is warranted when designing and building multi-threaded applications, particularly those which have a GUI component. Use of threads can be very deceptive. In many cases they appear to greatly simplify programming by allowing design in terms of simple autonomous entities focused on a single task. In fact in some cases they do simplify design and coding. However, in almost all cases they also make debugging, testing, and maintenance vastly more difficult and sometimes impossible. Neither the training, experience, or actual practices of most programmers, nor the tools we have to help us, are designed to cope with the non-determinism. For example, thorough testing (which is always difficult) becomes nearly impossible when bugs are timing dependent. This is particularly true in Java where one program can run on many different types of machines and OS platforms, and where each program must work under both preemptive or non-preemptive scheduling.

As a result of these inherent difficulties, we urge you to think twice about using threads in cases where they are not absolutely necessary. However, in some cases threads are necessary (or are imposed by other software packages) and so subArctic provides a thread-safe access mechanism. This section describes this mechanism and how to use it to safely manipulate the interactor tree from an independent thread.


The thread-safe mechanism they're referring to is very similar to the invokeLater() and invokeAndWait() methods provided by the SwingUtilities class.
[/Quote]
MSDBCSD 2010-06-24
  • 打赏
  • 举报
回复
同一个用户最多只能3次连续回帖~
qusic 2010-06-23
  • 打赏
  • 举报
回复
这是我在百度文库中看到的Thinking in java里关于线程部分的:

为什么说所有的用户界面动作都应该发生在事件调度线程中?
qusic 2010-06-23
  • 打赏
  • 举报
回复
[Quote=引用 3 楼 closewbq 的回复:]
两种虽然都可以,但是建议将任务交给另外一个线程去做。
因为Swing有专门的线程处理它的UI事件以及更新,如果我们通过主线程对其操作。可能会造成死锁和冲突。
我记得THINK IN JAVA线程那一章,说过这个问题。
[/Quote]
哦?哪为有关于这方面死锁的例子,发出来研究研究。
另:如果这两种写法只是个人习惯而已,那我也不必纠结了,呵呵~
closewbq 2010-06-23
  • 打赏
  • 举报
回复
两种虽然都可以,但是建议将任务交给另外一个线程去做。
因为Swing有专门的线程处理它的UI事件以及更新,如果我们通过主线程对其操作。可能会造成死锁和冲突。
我记得THINK IN JAVA线程那一章,说过这个问题。
qusic 2010-06-23
  • 打赏
  • 举报
回复
[Quote=引用 1 楼 healer_kx 的回复:]
都一样,main里面直接new也OK。
[/Quote]
那为啥sun的示例代码里都是这么写的?
他直接new不也行嘛?难道这只是那些写示例代码的程序员的个人习惯?
加载更多回复(1)
JAVA开发人员必备是HTML格式的 JavaTM 2 Platform Standard Edition 6 API 规范 本文档是 Java 2 Platform Standard Edition 6.0 的 API 规范。 请参见: 描述 Java 2 Platform 软件包 java.applet 提供创建 applet 所必需的类和 applet 用来与其 applet 上下文通信的类。 java.awt 包含用于创建用户界面和绘制图形图像的所有类。 java.awt.color 提供用于颜色空间的类。 java.awt.datatransfer 提供在应用程序之间和在应用程序内部传输数据的接口和类。 java.awt.dnd Drag 和 Drop 是一种直接操作动作,在许多图形用户界面系统中都会遇到它,它提供了一种机制,能够在两个与 GUI 中显示元素逻辑相关的实体之间传输信息。 java.awt.event 提供处理由 AWT 组件所激发的各类事件的接口和类。 java.awt.font 提供与字体相关的类和接口。 java.awt.geom 提供用于在与二维几何形状相关的对象上定义和执行操作的 Java 2D 类。 java.awt.im 提供输入方法框架所需的类和接口。 java.awt.im.spi 提供启用可以与 Java 运行时环境一起使用的输入方法开发的接口。 java.awt.image 提供创建和修改图像的各种类。 java.awt.image.renderable 提供用于生成与呈现无关的图像的类和接口。 java.awt.print 为通用的打印 API 提供类和接口。 java.beans 包含与开发 beans 有关的类,即基于 JavaBeansTM 架构的组件。 java.beans.beancontext 提供与 bean 上下文有关的类和接口。 java.io 通过数据流、序列化和文件系统提供系统输入和输出。 java.lang 提供利用 Java 编程语言进行程序设计的基础类。 java.lang.annotation 为 Java 编程语言注释设施提供库支持。 java.lang.instrument 提供允许 Java 编程语言代理检测运行在 JVM 上的程序的服务。 java.lang.management 提供管理接口,用于监视和管理 Java 虚拟机以及 Java 虚拟机在其上运行的操作系统。 java.lang.ref 提供了引用对象类,支持在某种程度上与垃圾回收器之间的交互。 java.lang.reflect 提供类和接口,以获得关于类和对象的反射信息。 java.math 提供用于执行任意精度整数算法 (BigInteger) 和任意精度小数算法 (BigDecimal) 的类。 java.net 为实现网络应用程序提供类。 java.nio 定义作为数据容器的缓冲区,并提供其他 NIO 包的概述。 java.nio.channels 定义了各种通道,这些通道表示到能够执行 I/O 操作的实体(如文件和套接字)的连接;定义了用于多路复用的、非阻塞 I/O 操作的选择器。 java.nio.channels.spi 用于 java.nio.channels 包的服务提供者类。 java.nio.charset 定义用来在字节和 Unicode 字符之间转换的 charset、解码器和编码器。 java.nio.charset.spi java.nio.charset 包的服务提供者类。 java.rmi 提供 RMI 包。 java.rmi.activation 为 RMI 对象激活提供支持。 java.rmi.dgc 为 RMI 分布式垃圾回收提供了类和接口。 java.rmi.registry 提供 RMI 注册表的一个类和两个接口。 java.rmi.server 提供支持服务器端 RMI 的类和接口。 java.security 为安全框架提供类和接口。 java.security.acl 此包中的类和接口已经被 java.security 包中的类取代。 java.security.cert 提供用于解析和管理证书、证书撤消列表 (CRL) 和证书路径的类和接口。 java.security.interfaces 提供的接口用于生成 RSA Laboratory Technical Note PKCS#1 中定义的 RSA(Rivest、Shamir 和 Adleman AsymmetricCipher 算法)密钥,以及 NIST 的 FIPS-186 中定义的 DSA(数字签名算法)密钥。 java.security.spec 提供密钥规范和算法参数规范的类和接口。 java.sql 提供使用 JavaTM 编程语言访问并处理存储在数据源(通常是一个关系数据库)中的数据的 API。 java.text 提供以与自然语言无关的方式来处理文本、日期、数字和消息的类和接口。 java.text.spi java.text 包中类的服务提供者类。 java.util 包含 collection 框架、遗留的 collection 类、事件模型、日期和时间设施、国际化和各种实用工具类(字符串标记生成器、随机数生成器和位数组)。 java.util.concurrent 在并发编程中很常用的实用工具类。 java.util.concurrent.atomic 类的小工具包,支持在单个变量上解除锁的线程安全编程。 java.util.concurrent.locks 为锁和等待条件提供一个框架的接口和类,它不同于内置同步和监视器。 java.util.jar 提供读写 JAR (Java ARchive) 文件格式的类,该格式基于具有可选清单文件的标准 ZIP 文件格式。 java.util.logging 提供 JavaTM 2 平台核心日志工具的类和接口。 java.util.prefs 此包允许应用程序存储并获取用户和系统首选项和配置数据。 java.util.regex 用于匹配字符序列与正则表达式指定模式的类。 java.util.spi java.util 包中类的服务提供者类。 java.util.zip 提供用于读写标准 ZIP 和 GZIP 文件格式的类。 javax.accessibility 定义了用户界面组件与提供对这些组件进行访问的辅助技术之间的协定。 javax.crypto 为加密操作提供类和接口。 javax.crypto.interfaces 根据 RSA Laboratories' PKCS #3 的定义,提供 Diffie-Hellman 密钥接口。 javax.crypto.spec 为密钥规范和算法参数规范提供类和接口。 javax.imageio Java Image I/O API 的主要包。 javax.imageio.event Java Image I/O API 的一个包,用于在读取和写入图像期间处理事件的同步通知。 javax.imageio.metadata 用于处理读写元数据的 Java Image I/O API 的包。 javax.imageio.plugins.bmp 包含供内置 BMP 插件使用的公共类的包。 javax.imageio.plugins.jpeg 支持内置 JPEG 插件的类。 javax.imageio.spi 包含用于 reader、writer、transcoder 和流的插件接口以及一个运行时注册表的 Java Image I/O API 包。 javax.imageio.stream Java Image I/O API 的一个包,用来处理从文件和流中产生的低级别 I/O。 javax.management 提供 Java Management Extensions 的核心类。 javax.management.loading 提供实现高级动态加载的类。 javax.management.modelmbean 提供了 ModelMBean 类的定义。 javax.management.monitor 提供 monitor 类的定义。 javax.management.openmbean 提供开放数据类型和 Open MBean 描述符类。 javax.management.relation 提供 Relation Service 的定义。 javax.management.remote 对 JMX MBean 服务器进行远程访问使用的接口。 javax.management.remote.rmi RMI 连接器是供 JMX Remote API 使用的一种连接器,后者使用 RMI 将客户端请求传输到远程 MBean 服务器。 javax.management.timer 提供对 Timer MBean(计时器 MBean)的定义。 javax.naming 为访问命名服务提供类和接口。 javax.naming.directory 扩展 javax.naming 包以提供访问目录服务的功能。 javax.naming.event 在访问命名和目录服务时提供对事件通知的支持。 javax.naming.ldap 提供对 LDAPv3 扩展操作和控件的支持。 javax.naming.spi 提供一些方法来动态地插入对通过 javax.naming 和相关包访问命名和目录服务的支持。 javax.net 提供用于网络应用程序的类。 javax.net.ssl 提供用于安全套接字包的类。 javax.print 为 JavaTM Print Service API 提供了主要类和接口。 javax.print.attribute 提供了描述 JavaTM Print Service 属性的类型以及如何分类这些属性的类和接口。 javax.print.attribute.standard 包 javax.print.attribute.standard 包括特定打印属性的类。 javax.print.event 包 javax.print.event 包含事件类和侦听器接口。 javax.rmi 包含 RMI-IIOP 的用户 API。 javax.rmi.CORBA 包含用于 RMI-IIOP 的可移植性 API。 javax.rmi.ssl 通过安全套接字层 (SSL) 或传输层安全 (TLS) 协议提供 RMIClientSocketFactory 和 RMIServerSocketFactory 的实现。 javax.security.auth 此包提供用于进行验证和授权的框架。 javax.security.auth.callback 此包提供与应用程序进行交互所必需的类,以便检索信息(例如,包括用户名和密码的验证数据)或显示信息(例如,错误和警告消息)。 javax.security.auth.kerberos 此包包含与 Kerberos 网络验证协议相关的实用工具类。 javax.security.auth.login 此包提供可插入的验证框架。 javax.security.auth.spi 此包提供用于实现可插入验证模块的接口。 javax.security.auth.x500 此包包含应该用来在 Subject 中存储 X500 Principal 和 X500 Private Crendentials 的类。 javax.security.cert 为公钥证书提供类。 javax.security.sasl 包含用于支持 SASL 的类和接口。 javax.sound.midi 提供用于 MIDI(音乐乐器数字接口)数据的 I/O、序列化和合成的接口和类。 javax.sound.midi.spi 在提供新的 MIDI 设备、MIDI 文件 reader 和 writer、或音库 reader 时提供服务提供者要实现的接口。 javax.sound.sampled 提供用于捕获、处理和回放取样的音频数据的接口和类。 javax.sound.sampled.spi 在提供新音频设备、声音文件 reader 和 writer,或音频格式转换器时,提供将为其创建子类的服务提供者的抽象类。 javax.sql 为通过 JavaTM 编程语言进行服务器端数据源访问和处理提供 API。 javax.sql.rowset JDBC RowSet 实现的标准接口和基类。 javax.sql.rowset.serial 提供实用工具类,允许 SQL 类型与 Java 编程语言数据类型之间的可序列化映射关系。 javax.sql.rowset.spi 第三方供应商在其同步提供者的实现中必须使用的标准类和接口。 javax.swing 提供一组“轻量级”(全部是 Java 语言)组件,尽量让这些组件在所有平台上的工作方式都相同。 javax.swing.border 提供围绕 Swing 组件绘制特殊边框的类和接口。 javax.swing.colorchooser 包含供 JColorChooser 组件使用的类和接口。 javax.swing.event 供 Swing 组件触发的事件使用。 javax.swing.filechooser 包含 JFileChooser 组件使用的类和接口。 javax.swing.plaf 提供一个接口和许多抽象类,Swing 用它们来提供自己的可插入外观功能。 javax.swing.plaf.basic 提供了根据基本外观构建的用户界面对象。 javax.swing.plaf.metal 提供根据 Java 外观(曾经代称为 Metal)构建的用户界面对象,Java 外观是默认外观。 javax.swing.plaf.multi 提供了组合两个或多个外观的用户界面对象。 javax.swing.plaf.synth Synth 是一个可更换皮肤 (skinnable) 的外观,在其中可委托所有绘制。 javax.swing.table 提供用于处理 javax.swing.JTable 的类和接口。 javax.swing.text 提供类 HTMLEditorKit 和创建 HTML 文本编辑器的支持类。 javax.swing.text.html 提供类 HTMLEditorKit 和创建 HTML 文本编辑器的支持类。 javax.swing.text.html.parser 提供默认的 HTML 解析器以及支持类。 javax.swing.text.rtf 提供一个类 (RTFEditorKit),用于创建富文本格式(Rich-Text-Format)的文本编辑器。 javax.swing.tree 提供处理 javax.swing.JTree 的类和接口。 javax.swing.undo 允许开发人员为应用程序(例如文本编辑器)中的撤消/恢复提供支持。 javax.transaction 包含解组期间通过 ORB 机制抛出的三个异常。 javax.transaction.xa 提供定义事务管理器和资源管理器之间的协定的 API,它允许事务管理器添加或删除 JTA 事务中的资源对象(由资源管理器驱动程序提供)。 javax.xml 根据 XML 规范定义核心 XML 常量和功能。 javax.xml.bind 为包含解组、编组和验证功能的客户端应用程序提供运行时绑定框架。 javax.xml.bind.annotation 定义将 Java 程序元素定制成 XML 模式映射的注释。 javax.xml.bind.annotation.adapters XmlAdapter 及其规范定义的子类允许任意 Java 类与 JAXB 一起使用。 javax.xml.bind.attachment 此包由基于 MIME 的包处理器实现,该处理器能够解释并创建基于 MIME 的包格式的已优化的二进制数据。 javax.xml.bind.helpers 仅由 JAXB 提供者用于: 提供某些 javax.xml.bind 接口的部分默认实现。 javax.xml.bind.util 有用的客户端实用工具类。 javax.xml.crypto 用于 XML 加密的通用类。 javax.xml.crypto.dom javax.xml.crypto 包的特定于 DOM 的类。 javax.xml.crypto.dsig 用于生成和验证 XML 数字签名的类。 javax.xml.crypto.dsig.dom javax.xml.crypto.dsig 包特定于 DOM 的类。 javax.xml.crypto.dsig.keyinfo 用来解析和处理 KeyInfo 元素和结构的类。 javax.xml.crypto.dsig.spec XML 数字签名的参数类。 javax.xml.datatype XML/Java 类型映射关系。 javax.xml.namespace XML 名称空间处理。 javax.xml.parsers 提供允许处理 XML 文档的类。 javax.xml.soap 提供用于创建和构建 SOAP 消息的 API。 javax.xml.stream javax.xml.stream.events javax.xml.stream.util javax.xml.transform 此包定义了用于处理转换指令,以及执行从源到结果的转换的一般 API。 javax.xml.transform.dom 此包实现特定于 DOM 的转换 API。 javax.xml.transform.sax 此包实现特定于 SAX2 的转换 API。 javax.xml.transform.stax 提供特定于 StAX 的转换 API。 javax.xml.transform.stream 此包实现特定于流和 URI 的转换 API。 javax.xml.validation 此包提供了用于 XML 文档验证的 API。 javax.xml.ws 此包包含核心 JAX-WS API。 javax.xml.ws.handler 该包定义用于消息处理程序的 API。 javax.xml.ws.handler.soap 该包定义用于 SOAP 消息处理程序的 API。 javax.xml.ws.http 该包定义特定于 HTTP 绑定的 API。 javax.xml.ws.soap 该包定义特定于 SOAP 绑定的 API。 javax.xml.ws.spi 该包定义用于 JAX-WS 2.0 的 SPI。 javax.xml.xpath 此包提供了用于 XPath 表达式的计算和访问计算环境的 object-model neutral API。 org.ietf.jgss 此包提供一个框架,该框架允许应用程序开发人员通过利用统一的 API 使用一些来自各种基础安全机制(如 Kerberos)的安全服务,如验证、数据完整性和和数据机密性。 org.omg.CORBA 提供 OMG CORBA API 到 JavaTM 编程语言的映射,包括 ORB 类,如果已实现该类,则程序员可以使用此类作为全功能对象请求代理(Object Request Broker,ORB)。 org.omg.CORBA_2_3 CORBA_2_3 包定义对 Java[tm] Standard Edition 6 中现有 CORBA 接口所进行的添加。 org.omg.CORBA_2_3.portable 提供输入和输出值类型的各种方法,并包含 org/omg/CORBA/portable 包的其他更新。 org.omg.CORBA.DynAnyPackage 提供与 DynAny 接口一起使用的异常(InvalidValue、Invalid、InvalidSeq 和 TypeMismatch)。 org.omg.CORBA.ORBPackage 提供由 ORB.resolve_initial_references 方法抛出的异常 InvalidName,以及由 ORB 类中的动态 Any 创建方法抛出的异常 InconsistentTypeCode。 org.omg.CORBA.portable 提供可移植性层,即可以使一个供应商生成的代码运行在另一个供应商 ORB 上的 ORB API 集合。 org.omg.CORBA.TypeCodePackage 提供用户定义的异常 BadKind 和 Bounds,它们将由 TypeCode 类中的方法抛出。 org.omg.CosNaming 为 Java IDL 提供命名服务。 org.omg.CosNaming.NamingContextExtPackage 此包包含以下在 org.omg.CosNaming.NamingContextExt 中使用的类: AddressHelper StringNameHelper URLStringHelper InvalidAddress 包规范 有关 Java[tm] Platform, Standard Edition 6 ORB 遵守的官方规范的受支持部分的明确列表,请参阅 Official Specifications for CORBA support in Java[tm] SE 6。 org.omg.CosNaming.NamingContextPackage 此包包含 org.omg.CosNaming 包的 Exception 类。 org.omg.Dynamic 此包包含 OMG Portable Interceptor 规范 http://cgi.omg.org/cgi-bin/doc?ptc/2000-08-06 的第 21.9 小节中指定的 Dynamic 模块。 org.omg.DynamicAny 提供一些类和接口使得在运行时能够遍历与 any 有关联的数据值,并提取数据值的基本成分。 org.omg.DynamicAny.DynAnyFactoryPackage 此包包含 DynamicAny 模块的 DynAnyFactory 接口中的类和异常,该模块在 OMG The Common Object Request Broker: Architecture and Specification http://cgi.omg.org/cgi-bin/doc?formal/99-10-07 的第 9.2.2 小节中指定。 org.omg.DynamicAny.DynAnyPackage 此包包含 DynAny 模块的 DynAnyFactory 接口中的类和异常,该模块在 OMG The Common Object Request Broker: Architecture and Specification http://cgi.omg.org/cgi-bin/doc?formal/99-10-07 的第 9.2 小节中指定。 org.omg.IOP 此包包含在 OMG 文档 The Common Object Request Broker: Architecture and Specification http://cgi.omg.org/cgi-bin/doc?formal/99-10-07 的 13.6.小节中指定的 IOP 模块。 org.omg.IOP.CodecFactoryPackage 此包包含 IOP::CodeFactory 接口中指定的异常(作为 Portable Interceptor 规范的一部分)。 org.omg.IOP.CodecPackage 此包根据 IOP::Codec IDL 接口定义生成。 org.omg.Messaging 此包包含 OMG Messaging Interceptor 规范 http://cgi.omg.org/cgi-bin/doc?formal/99-10-07 中指定的 Messaging 模块。 org.omg.PortableInterceptor 提供一个注册 ORB 钩子 (hook) 的机制,通过这些钩子 ORB 服务可以截取执行 ORB 的正常流。 org.omg.PortableInterceptor.ORBInitInfoPackage 此包包含 OMG Portable Interceptor 规范 http://cgi.omg.org/cgi-bin/doc?ptc/2000-08-06 的第 21.7.2 小节中指定的 PortableInterceptor 模块的 ORBInitInfo 本地接口中的异常和 typedef。 org.omg.PortableServer 提供一些类和接口,用来生成跨多个供应商 ORB 的可移植应用程序的服务器端。 org.omg.PortableServer.CurrentPackage 提供各种方法实现,这些实现能够访问调用方法的对象的身份。 org.omg.PortableServer.POAManagerPackage 封装 POA 关联的处理状态。 org.omg.PortableServer.POAPackage 允许程序员构造可在不同 ORB 产品间移植的对象实现。 org.omg.PortableServer.portable 提供一些类和接口,用来生成跨多个供应商 ORB 的可移植应用程序的服务器端。 org.omg.PortableServer.ServantLocatorPackage 提供定位 servant 的类和接口。 org.omg.SendingContext 为值类型的编组提供支持。 org.omg.stub.java.rmi 包含用于 java.rmi 包中出现的 Remote 类型的 RMI-IIOP Stub。 org.w3c.dom 为文档对象模型 (DOM) 提供接口,该模型是 Java API for XML Processing 的组件 API。 org.w3c.dom.bootstrap org.w3c.dom.events org.w3c.dom.ls org.xml.sax 此包提供了核心 SAX API。 org.xml.sax.ext 此包包含适合的 SAX 驱动程序不一定支持的 SAX2 设施的接口。 org.xml.sax.helpers 此包包含“帮助器”类,其中包括对引导基于 SAX 的应用程序的支持。

62,634

社区成员

发帖
与我相关
我的任务
社区描述
Java 2 Standard Edition
社区管理员
  • Java SE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧