Java 中文官方教程 2022 版（四十六）(3)

Java 中文官方教程 2022 版（四十六）(2)https://developer.aliyun.com/article/1488455

将遗留代码转换为使用泛型

原文：docs.oracle.com/javase/tutorial/extra/generics/convert.html

之前，我们展示了新代码和旧代码如何互操作。现在，是时候看看更难的问题，即"泛型化"旧代码。

如果决定将旧代码转换为使用泛型，需要仔细考虑如何修改 API。

您需要确保泛型 API 不会过于限制性；它必须继续支持 API 的原始契约。再次考虑一些java.util.Collection的示例。预泛型 API 看起来像：

interface Collection {
    public boolean containsAll(Collection c);
    public boolean addAll(Collection c);
}

一个天真的泛型尝试可能是以下内容：

interface Collection<E> {
    public boolean containsAll(Collection<E> c);
    public boolean addAll(Collection<E> c);
}

虽然这肯定是类型安全的，但它并不符合 API 的原始契约。containsAll()方法适用于任何类型的传入集合。只有当传入集合确实只包含E的实例时才会成功，但：

• 传入集合的静态类型可能不同，也许是因为调用者不知道传入的集合的确切类型，或者是因为它是一个Collection，其中S是E的子类型。
  
• 使用不同类型的集合调用containsAll()是完全合法的。该例程应该正常工作，返回false。
  

在addAll()的情况下，我们应该能够添加任何由E的子类型的实例组成的集合。我们看到如何在泛型方法部分正确处理这种情况。

您还需要确保修改后的 API 与旧客户端保持二进制兼容性。这意味着 API 的擦除必须与原始的未泛型化 API 相同。在大多数情况下，这是自然而然的，但也有一些微妙的情况。我们将检查我们遇到的最微妙的情况之一，即方法Collections.max()。正如我们在通配符的更多乐趣部分看到的，max()的一个合理签名是：

public static <T extends Comparable<? super T>> 
        T max(Collection<T> coll)

这很好，除了这个签名的擦除是：

public static Comparable max(Collection coll)

这与max()的原始签名不同：

public static Object max(Collection coll)

当然可以为max()指定这个签名，但没有这样做，所有调用Collections.max()的旧二进制类文件都依赖于返回Object的签名。

我们可以通过在形式类型参数T的边界中明确指定一个超类来强制擦除不同。

public static <T extends Object & Comparable<? super T>> 
        T max(Collection<T> coll)

这是给类型参数多重边界的一个示例，使用语法T1 & T2 ... & Tn。具有多重边界的类型变量被认为是边界中列出的所有类型的子类型。当使用多重边界时，边界中提到的第一个类型被用作类型变量的擦除。

最后，我们应该记住max只从其输入集合中读取，因此适用于T的任何子类型的集合。

这将我们带到 JDK 中实际使用的签名：

public static <T extends Object & Comparable<? super T>> 
        T max(Collection<? extends T> coll)

在实践中很少会出现这么复杂的情况，但是专家库设计者在转换现有 API 时应该准备好仔细思考。

另一个需要注意的问题是协变返回，即在子类中细化方法的返回类型。在旧的 API 中不应该利用这个特性。为了理解为什么，让我们看一个例子。

假设你原始的 API 形式为：

public class Foo {
    // *Factory. Should create an instance of* 
    // *whatever class it is declared in.*
    public Foo create() {
        ...
    }
}
public class Bar extends Foo {
    // *Actually creates a Bar.*
    public Foo create() {
        ...
    }
}

利用协变返回，你将其修改为：

public class Foo {
    // *Factory. Should create an instance of* 
    // *whatever class it is declared in.*
    public Foo create() {
        ...
    }
}
public class Bar extends Foo {
    // *Actually creates a Bar.*
    public Bar create() {
        ...
    }
}

现在，假设你的代码的第三方客户写了以下内容：

public class Baz extends Bar {
    // *Actually creates a Baz.*
    public Foo create() {
        ...
    }
}

Java 虚拟机不直接支持具有不同返回类型的方法重写。这个特性由编译器支持。因此，除非重新编译类Baz，否则它将无法正确重写Bar的create()方法。此外，Baz将需要修改，因为代码将被拒绝——Baz中的create()的返回类型不是Bar中create()的返回类型的子类型。

致谢

原文：docs.oracle.com/javase/tutorial/extra/generics/acknowledgements.html

Erik Ernst, Christian Plesner Hansen, Jeff Norton, Mads Torgersen, Peter von der Ahe 和 Philip Wadler 为本教程贡献了材料。

感谢 David Biesack, Bruce Chapman, David Flanagan, Neal Gafter, Orjan Petersson, Scott Seligman, Yoshiki Shibata 和 Kresten Krab Thorup 对本教程早期版本提供的宝贵反馈。如果有遗漏的人，请谅解。

教程：全屏独占模式 API

原文：docs.oracle.com/javase/tutorial/extra/fullscreen/index.html

作者：迈克尔·马塔克

您想在 Java 开发环境中使用高性能图形吗？您一直想编写游戏，但是您的图像移动得不够快吗？您的幻灯片程序因为无法控制用户的显示分辨率而无法正常工作吗？如果您一直在问这些问题，那么在 1.4 版本中引入的全屏独占模式 API 可能是您正在寻找的东西。

全屏独占模式

全屏独占模式是一个强大的新功能，它使您能够暂停窗口系统，以便直接在屏幕上进行绘制。

显示模式

本节描述了如何选择和设置显示模式。还讨论了为什么首先要设置显示模式。

被动渲染 vs. 主动渲染

本节讨论了被动渲染和主动渲染的优点。例如，在主事件循环中使用paint方法绘制是被动的，而在自己的线程中渲染是主动的。还列出了主动渲染的技巧。

双缓冲和页面翻转

本节解释了双缓冲并介绍了页面翻转，这是全屏独占模式中可用的双缓冲技术。

BufferStrategy 和 BufferCapabilities

本节介绍了java.awt.image.BufferStrategy类，该类允许您在不知道使用的缓冲区数量或显示它们的技术的情况下绘制到表面和组件。本节还回顾了java.awt.BufferCapabilities类，该类可以帮助您确定图形设备的功能。

示例

本页面列出了几个全屏独占模式示例。

全屏独占模式

原文：docs.oracle.com/javase/tutorial/extra/fullscreen/exclusivemode.html

使用微软的 DirectX API 的程序员可能已经熟悉全屏独占模式。其他程序员可能对这个概念有些陌生。无论哪种情况，全屏独占模式是 J2SE™ 1.4 版本的一个强大功能，允许程序员暂停窗口系统，以便直接向屏幕绘制。

这是与许多传统 GUI 程序有些微的范式转变。在传统的 Java GUI 程序中，AWT 负责从操作系统通过事件分发线程传播绘制事件，并在适当时调用 AWT 的Component.paint方法。在全屏独占应用程序中，绘制通常由程序自身主动完成。此外，传统的 GUI 应用程序受限于用户选择的屏幕位深和大小。在全屏独占应用程序中，程序可以控制屏幕的位深和大小（显示模式）。最后，许多更高级的技术，如翻页（下文讨论）和立体缓冲（利用为每只眼睛使用单独一组帧的系统）在某些平台上要求应用程序首先处于全屏独占模式。

硬件加速图像基础知识

要理解全屏独占模式 API，您需要了解一些关于硬件加速图像的基本原理。VolatileImage接口封装了一个表面，该表面可能会或可能不会利用硬件加速。这些表面可能会因操作系统的要求而失去其硬件加速或内存（因此称为“易失性”）。有关易失性图像的更多信息，请参阅VolatileImage 教程（即将推出）。

全屏独占模式通过java.awt.GraphicsDevice对象处理。要获取所有可用屏幕图形设备的列表（在单个或多监视器系统中），可以在本地java.awt.GraphicsEnvironment上调用getScreenDevices方法；对于默认（主要）屏幕（在单监视器系统中唯一的屏幕），可以调用getDefaultScreenDevice方法。

一旦获得了图形设备，可以调用以下方法之一：

• public boolean isFullScreenSupported()
  此方法返回全屏独占模式是否可用。在不支持全屏独占模式的系统上，最好在固定大小的窗口模式下运行应用程序，而不是设置全屏窗口。
  
• public void setFullScreenWindow(Window w)
  给定一个窗口，该方法使用该窗口进入全屏独占模式。如果全屏独占模式不可用，则窗口将定位在(0,0)并调整大小以适应屏幕。使用带有null参数的方法退出全屏独占模式。
  

编程提示

以下是关于使用全屏独占模式进行编程的一些建议：

• 在进入全屏独占模式之前检查isFullScreenSupported。如果不支持，性能可能会降低。
  
• 进入和退出全屏模式时，使用try...finally子句更加健壮。这不仅是良好的编码实践，还可以防止程序停留在全屏独占模式中的时间超过应有的时间：

GraphicsDevice myDevice;
Window myWindow;
try {
    myDevice.setFullScreenWindow(myWindow);
    ...
} finally {
    myDevice.setFullScreenWindow(null);
}

• 大多数全屏独占应用程序更适合使用无装饰窗口。使用setUndecorated方法在框架或对话框中关闭装饰。
  
• 全屏独占应用程序不应该是可调整大小的，因为调整全屏应用程序的大小可能会导致不可预测的（或可能危险的）行为。
  
• 出于安全原因，在应用程序中使用全屏独占模式时，用户必须授予fullScreenExclusive权限。
  

显示模式

原文：docs.oracle.com/javase/tutorial/extra/fullscreen/displaymode.html

一旦应用程序处于全屏独占模式，它可能能够利用主动设置显示模式。显示模式（java.awt.DisplayMode）由尺寸（以像素为单位的监视器宽度和高度）、位深度（每像素的位数）和刷新率（监视器更新自身的频率）组成。一些操作系统允许您同时使用多个位深度，此时特殊值BIT_DEPTH_MULTI用于位深度的值。此外，一些操作系统可能无法控制刷新率（或者您可能不关心刷新率设置）。在这种情况下，特殊值REFRESH_RATE_UNKNOWN用于刷新率值。

如何设置显示模式

要获取当前显示模式，只需在图形设备上调用getDisplayMode方法。要获取所有可能的显示模式列表，请调用getDisplayModes方法。无论您是否处于全屏独占模式，都可以随时调用getDisplayMode和getDisplayModes。

在尝试更改显示模式之前，您应该首先调用isDisplayChangeSupported方法。如果此方法返回false，则操作系统不支持更改显示模式。

只有在全屏独占模式下才能更改显示模式。要更改显示模式，请使用所需的显示模式调用setDisplayMode方法。如果显示模式不可用，不支持显示模式更改，或者您未在全屏独占模式下运行，则会抛出运行时异常。

更改显示模式的原因

设置显示模式的主要原因是性能。如果应用程序选择显示的图像与屏幕具有相同的位深度，应用程序可以运行得更快。此外，如果您可以依赖显示器具有特定尺寸，那么绘制到该显示器会简单得多，因为您不必根据用户设置的显示方式缩放或放大物体。

编程提示

以下是选择和设置显示模式的一些建议：

• 在尝试更改图形设备上的显示模式之前，请检查isDisplayChangeSupported方法返回的值。
  
• 在尝试更改显示模式之前，请确保您处于全屏独占模式。
  
• 与使用全屏模式一样，设置显示模式在try...finally子句中更加健壮：

GraphicsDevice myDevice;
Window myWindow;
DisplayMode newDisplayMode;
DisplayMode oldDisplayMode 
    = myDevice.getDisplayMode();
try {
    myDevice.setFullScreenWindow(myWindow);
    myDevice.setDisplayMode(newDisplayMode);
    ...
} finally {
    myDevice.setDisplayMode(oldDisplayMode);
    myDevice.setFullScreenWindow(null);
}

• 在为应用程序选择显示模式时，您可能希望保留首选显示模式列表，然后从可用显示模式列表中选择最佳显示模式。
  
• 作为备用方案，如果您想要的显示模式不可用，您可能希望以固定大小的窗口模式运行。
  

被动渲染 vs. 主动渲染

原文：docs.oracle.com/javase/tutorial/extra/fullscreen/rendering.html

正如之前提到的，大多数全屏应用程序通常在绘制时更好地处于控制状态。在传统的窗口化 GUI 应用程序中，绘制的时间通常由操作系统处理。在窗口化环境中，这是完全合理的。窗口化应用程序不知道用户何时会移动、调整大小、暴露或被另一个窗口覆盖，直到实际发生。在 Java GUI 应用程序中，操作系统向 AWT 传递一个绘画事件，AWT 找出需要绘制的内容，创建一个带有适当裁剪区域的java.awt.Graphics对象，然后使用该Graphics对象调用paint方法：

// Traditional GUI Application paint method:
// This can be called at any time, usually 
// from the event dispatch thread
public void paint(Graphics g) {
    // Use g to draw my Component
}

这有时被称为被动渲染。可以想象，这样的系统会产生很多开销，让许多性能敏感的 AWT 和 Swing 程序员感到恼火。

在全屏独占模式下，您不再需要担心窗口被调整大小、移动、暴露或遮挡（除非您忽略了我关于关闭调整大小的建议）。相反，应用程序窗口直接绘制到屏幕上（主动渲染）。这样做可以简化绘制过程，因为您永远不需要担心绘画事件。事实上，在全屏独占模式下，由操作系统传递的绘画事件甚至可能在不适当或不可预测的时间传递。

在全屏独占模式下，不要依赖paint方法，绘制代码通常更适合在渲染循环中完成：

public void myRenderingLoop() {
    while (!done) {
        Graphics myGraphics = getPaintGraphics();
        // Draw as appropriate using myGraphics
        myGraphics.dispose();
    }
}

这样的渲染循环可以在任何线程中完成，可以是自己的辅助线程，也可以作为主应用程序线程的一部分。

编程提示

一些关于使用主动渲染的提示：

• 不要将绘制代码放在paint方法中。您永远不知道该方法何时会被调用！相反，使用另一个方法名，比如render(Graphics g)，在窗口模式下可以从paint方法中调用，或者在渲染循环中使用自己的图形调用。
  
• 使用setIgnoreRepaint方法在应用程序窗口和组件上关闭所有从操作系统完全分派的绘画事件，因为这些事件可能在不适当的时间调用，或者更糟糕的是，调用paint，这可能导致 AWT 事件线程和您的渲染循环之间的竞争条件。
  
• 将绘制代码与渲染循环分开，以便在全屏独占和窗口模式下都能完全运行。
  
• 优化您的渲染，以便您不会始终在屏幕上绘制所有内容（除非您使用翻页或双缓冲，下面将讨论）。
  
• 不要依赖update或repaint方法来传递绘画事件。
  
• 不要使用重量级组件，因为这些组件仍会产生涉及 AWT 和平台窗口系统的开销。
  
• 如果您使用轻量级组件，比如 Swing 组件，您可能需要稍微调整它们，以便它们使用您的Graphics进行绘制，而不是直接调用paint方法。请随意从您的渲染循环直接调用 Swing 方法，如paintComponents、paintComponent、paintBorder和paintChildren。
  
• 如果您只想要一个简单的全屏 Swing 或 AWT 应用程序，可以随意使用被动渲染，但请记住，在全屏独占模式下，绘制事件可能有些不可靠或不必要。此外，如果您使用被动渲染，您将无法使用更高级的技术，如翻页。最后，请务必小心避免死锁，如果您决定同时使用主动和被动渲染—这种方法并不推荐。
  

双缓冲和页面翻转

原文：docs.oracle.com/javase/tutorial/extra/fullscreen/doublebuf.html

假设您必须逐像素或逐行在屏幕上绘制整个图片。如果您直接将这样的东西绘制到屏幕上（使用Graphics.drawLine），您可能会发现需要一些时间。您甚至可能会注意到您的图片是如何绘制的可见痕迹。与观看以这种方式和速度绘制事物不同，大多数程序员使用一种称为双缓冲的技术。

在 Java 应用程序中，双缓冲的传统概念相当简单：创建一个屏幕外图像，使用图像的图形对象绘制到该图像，然后，在一步中，使用目标窗口的图形对象和屏幕外图像调用drawImage。您可能已经注意到，Swing 在其许多组件中使用了这种技术，通常默认启用，使用setDoubleBuffered方法。

屏幕表面通常被称为主表面，用于双缓冲的屏幕外图像通常被称为后备缓冲区。将内容从一个表面复制到另一个表面的行为通常被称为块线传输，或blitting（blt 通常发音为"blit"，不应与 BLT 三明治混淆）。

主表面通常通过任何显示组件的图形对象进行操作；在全屏模式下，使用全屏窗口的图形进行任何操作是对屏幕内存的直接操作。因此，您可以利用全屏独占模式中可能由于窗口系统的开销而无法使用的其他功能。在全屏独占模式中仅可用的一种技术是一种称为页面翻转的双缓冲形式。

页面翻转

许多显卡都有视频指针的概念，它只是视频内存中的一个地址。这个指针告诉显卡在下一个刷新周期期间要显示的视频内容在哪里。在一些显卡和一些操作系统中，这个指针甚至可以通过编程方式进行操作。假设你在视频内存中创建了一个与屏幕精确宽度、高度和位深度相同的后备缓冲区，然后像使用双缓冲区一样向该缓冲区绘制。现在想象一下，如果不像双缓冲区那样将图像传输到屏幕上，而是简单地将视频指针更改为你的后备缓冲区，那会发生什么。在下一次刷新期间，显卡现在将使用你的图像来显示。这种切换称为翻页，与基于 blt 的双缓冲区相比，性能提升在于只需要在内存中移动一个指针，而不是将整个内容从一个缓冲区复制到另一个缓冲区。

当发生页面翻转时，旧后备缓冲区的指针现在指向主表面，旧主表面的指针现在指向后备缓冲区内存。这会自动为下一个绘制操作做好准备。

有时在翻页链中设置多个后备缓冲区是有利的。当绘制所花费的时间大于显示器的刷新率时，这是特别有用的。翻页链简单地是两个或更多后备缓冲区（有时称为中间缓冲区）加上主表面（有时称为三重缓冲、四重缓冲等）。在翻页链中，下一个可用的后备缓冲区变为主表面，依此类推，一直到用于绘制的最后一个后备缓冲区。

双缓冲和翻页的好处

如果你的性能指标只是双缓冲或翻页发生的速度与直接渲染相比，你可能会感到失望。你可能会发现，直接渲染的数字远远超过双缓冲的数字，而双缓冲的数字远远超过翻页的数字。这些技术都是用于改善感知性能，在图形应用程序中比数值性能更重要。

双缓冲主要用于消除可见的绘制，这可以使应用程序看起来业余、迟缓或闪烁。翻页主要用于消除撕裂，这是一种在绘制到屏幕上比显示器的刷新率更快时发生的分裂效果。更平滑的绘制意味着更好的感知性能和更好的用户体验。

BufferStrategy 和 BufferCapabilities

原文：docs.oracle.com/javase/tutorial/extra/fullscreen/bufferstrategy.html

BufferStrategy

在 Java 2 标准版中，您无需担心视频指针或视频内存就可以充分利用双缓冲或翻页。新的类java.awt.image.BufferStrategy已经添加，以便处理绘制到表面和组件的通用方式，无论使用的缓冲区数量或显示它们的技术。

缓冲策略为您提供了两种通用的绘图方法：getDrawGraphics 和 show。当您想开始绘图时，获取一个绘图对象并使用它。当您完成绘图并希望将信息呈现到屏幕上时，请调用 show。这两种方法被设计得相当优雅，可以很好地适应渲染循环：

BufferStrategy myStrategy;
while (!done) {
    Graphics g = myStrategy.getDrawGraphics();
    render(g);
    g.dispose();
    myStrategy.show();
}

缓冲策略还设置了帮助您监视VolatileImage问题。在全屏独占模式下，VolatileImage问题尤为重要，因为窗口系统有时会收回它给您的视频内存。一个重要的例子是当用户在 Windows 中按下ALT+TAB组合键时，突然您的全屏程序在后台运行，您的视频内存就会丢失。您可以调用contentsLost方法来查看是否发生了这种情况。同样，当窗口系统将内存还给您时，您可以使用contentsRestored方法来查找。

BufferCapabilities

如前所述，不同的操作系统，甚至同一操作系统上的不同显卡，都有不同的可用技术。这些能力被暴露出来，以便您可以为应用程序选择最佳技术。

类java.awt.BufferCapabilities封装了这些功能。每个缓冲策略都由其缓冲能力控制，因此为您的应用程序选择正确的缓冲能力非常关键。要找出哪些功能可用，请从您的图形设备上可用的GraphicsConfiguration对象调用getBufferCapabilities方法。

Java 2 标准版 1.4 版中提供的功能有：

• isPageFlipping
  此功能返回此图形配置上是否可用硬件翻页。
  
• isFullScreenRequired
  此功能返回在尝试硬件翻页之前是否需要全屏独占模式。
  
• isMultiBufferAvailable
  此功能返回硬件中是否可用多缓冲（两个或更多后备缓冲区加上主表面）。
  
• getFlipContents
  此功能返回用于执行硬件翻页的技术提示。这很重要，因为在使用的技术不同的情况下，show后的后备缓冲区内容也会有所不同。返回的值可以为 null（如果isPageFlipping返回false）或以下值之一。只要isPageFlipping方法返回 true，就可以为缓冲策略指定任何值，尽管性能会根据可用功能而变化。
  
• FlipContents.COPIED
  此值意味着后备缓冲区的内容已复制到主表面。"翻页"可能是作为硬件位块传输执行的，这意味着硬件双缓冲可能是通过位块传输而不是真正的翻页完成的。这在理论上应该更快，或者至少与从VolatileImage到主表面的位块传输一样快，尽管实际效果可能有所不同。翻页后，后备缓冲区的内容与主表面相同。
  
• FlipContents.BACKGROUND
  此值意味着后备缓冲区的内容已用背景颜色清除。可能已执行真正的翻页或位块传输。
  
• FlipContents.PRIOR
  此值意味着后备缓冲区的内容现在是旧主表面的内容，反之亦然。通常，此值表示真正的翻页发生，尽管这并不是保证，再次强调，此操作的效果可能有所不同。
  
• FlipContents.UNKNOWN
  此值意味着翻页后的后备缓冲区内容未定义。您可能需要尝试找出哪种技术最适合您（或者您可能不在乎），并且您肯定需要每次绘制时自己设置后备缓冲区的内容。
  

要为组件创建缓冲策略，请调用createBufferStrategy方法，提供所需的缓冲区数量（此数字包括主表面）。如果需要任何特定的缓冲技术，请提供适当的BufferCapabilities对象。请注意，当您使用此方法的版本时，必须在您的选择不可用时捕获AWTException。还要注意，这些方法仅适用于Canvas和Window。

一旦为组件创建了特定的缓冲策略，您可以使用getBufferStrategy方法对其进行操作。请注意，此方法也仅适用于画布和窗口。

编程提示

关于使用缓冲能力和缓冲策略的一些建议：

• 在try...finally子句中更加稳健地获取、使用和释放图形对象：

BufferStrategy myStrategy;
while (!done) {
    Graphics g;
    try {
        g = myStrategy.getDrawGraphics();
        render(g);
    } finally {
        g.dispose();
    }
    myStrategy.show();
}

• 在使用缓冲策略之前，请检查可用的功能。
  
• 为了获得最佳效果，请在全屏独占窗口上创建您的缓冲策略。在使用翻页之前，请确保检查isFullScreenRequired和isPageFlipping功能。
  
• 不要对性能做任何假设。根据需要调整你的代码，但要记住不同的操作系统和显卡具有不同的功能。对你的应用程序进行性能分析！
  
• 你可能想要对你的组件进行子类化，以重写createBufferStrategy方法。使用一个适合你的应用程序的策略选择算法。FlipBufferStrategy和BltBufferStrategy内部类是受保护的，可以被子类化。
  
• 不要忘记你可能会丢失你的绘图表面！在绘制之前一定要检查contentsLost和contentsRestored。所有已丢失的缓冲区在恢复时都必须重新绘制。
  
• 如果在 Swing 应用程序中使用缓冲策略进行双缓冲，你可能希望关闭 Swing 组件的双缓冲，因为它们已经是双缓冲的。视频内存有一定的价值，应仅在绝对必要时使用。
  
• 使用多个后备缓冲区可能会导致浪费。当绘制时间超过执行show的时间时，多缓冲仅有用。对你的应用程序进行性能分析！
  

示例

原文：docs.oracle.com/javase/tutorial/extra/fullscreen/example.html

CapabilitiesTest 展示了在运行该程序的机器上可用的不同缓冲能力。

DisplayModeTest 展示了一个使用被动渲染的 Swing 应用程序。如果全屏独占模式可用，它将进入全屏独占模式。如果允许显示模式更改，它允许您在显示模式之间切换。

MultiBufferTest 进入全屏模式，并通过活动渲染循环使用多缓冲。

课程：准备 Java 程序员语言认证

原文：docs.oracle.com/javase/tutorial/extra/certification/index.html

Oracle 为 Java SE 8 程序员提供了两条认证路径：

• Oracle 认证 Java SE 8 程序员（Oracle Certified Associate, Java SE 8 Programmer）
  
• Oracle 认证 Java SE 8 专业程序员（Oracle Certified Professional, Java SE 8 Programmer）
  

想要学习 Java 语言的高级指南，请参阅 Java 教程学习路径。

教程：Java 命名和目录接口

原文：docs.oracle.com/javase/tutorial/jndi/index.html

本教程描述了 JNDI™（Java 命名和目录接口）是一个用于访问目录和命名服务的 API。在这里，您将了解基本的命名和目录服务以及如何使用 JNDI 编写简单的应用程序来使用这些服务。最流行的目录服务 LDAP 被用来演示使用 JNDI 访问目录服务。

从这里开始，了解命名和目录概念的概述。

为您提供了 JNDI、其架构和打包的概述。

描述了设置运行本教程中描述的示例以及任何其他 JNDI 应用程序所需的环境的说明和步骤。

描述了各种命名和目录操作，并通过许多示例演示了使用 JNDI 访问命名/目录服务。

针对 LDAP 用户的专门课程。它讨论了将 JNDI 建模为 LDAP API、如何执行 LDAP 认证、SSL 和在生产环境中管理连接等内容。

展示了如何将您的应用程序与目录集成，以便您可以将 Java 对象存储到目录中并从目录中检索。

介绍了 JDK 5.0 和 JDK 6 中可用的 JNDI 和 LDAP 服务提供程序中的功能。

注意： 本教程基于位于 docs.oracle.com/javase/jndi/tutorial/ 的独立 JNDI 教程。最后更新于 Java 2 SDK，标准版，v 1.4.2，全面介绍了 JNDI，但不再受支持。本教程从独立教程中摘录了基础知识，并包括了在 Java 平台标准版 5.0 和 6 发行版中添加的功能。

旧版 JNDI 教程被保留为 docs.oracle.com 上的存档。

教训：命名和目录概念

原文：docs.oracle.com/javase/tutorial/jndi/concepts/index.html

Java 中文官方教程 2022 版（四十六）(4)https://developer.aliyun.com/article/1488465