--- old/src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html 2017-10-23 13:51:00.000000000 -0700 +++ new/src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html 2017-10-23 13:51:00.000000000 -0700 @@ -1,5 +1,11 @@ + + + + + AWT Threading Issues + - - - - - - + -

AWT Threading Issues

+

AWT Threading Issues

- +

Listeners and threads

Unless otherwise noted all AWT listeners are notified on the event @@ -41,7 +42,7 @@
For example, if a key listeners is added from another key listener, the newly added listener is only notified on subsequent key events. - +

Auto-shutdown

According to @@ -53,7 +54,7 @@ one of two things happens: @@ -84,13 +85,15 @@ posted to the EventQueue can be coalesced) are dispatched:
  • There is at least one alive non-daemon thread while there is at @@ -98,7 +101,7 @@ application (see Component.isDisplayable). -The implications of the third restriction are as follows: +The implications of the third restriction are as follows: It depends on the implementation if and when the non-daemon helper -threads are terminated once all components are made undisplayable. -The implementation-specific details are given below. +threads are terminated once all components are made undisplayable. +The implementation-specific details are given below.

    Implementation-dependent behavior. @@ -147,7 +150,7 @@ Note, that while an application following these recommendations will exit cleanly under normal conditions, it is not guaranteed that it -will exit cleanly in all cases. Two examples: +will exit cleanly in all cases. Two examples: On the other hand, if you require the JVM to continue running even after the application has made all components undisplayable you should start a -non-daemon thread that blocks forever. +non-daemon thread that blocks forever.
    -        <...>
    +        <...>
             Runnable r = new Runnable() {
                 public void run() {
                     Object o = new Object();
    @@ -183,7 +186,7 @@
             Thread t = new Thread(r);
             t.setDaemon(false);
             t.start();
    -        <...>
    +        <...>
     
    The Java™ Virtual Machine Specification --- old/src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html 2017-10-23 13:51:01.000000000 -0700 +++ new/src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html 2017-10-23 13:51:01.000000000 -0700 @@ -1,5 +1,11 @@ + + + + + AWT Desktop Properties + - - - - - - + -

    AWT Desktop Properties

    +

    AWT Desktop Properties

    The following refers to standard AWT desktop properties that may be obtained via the @@ -76,7 +77,7 @@

    Desktop Font Rendering Hints

    -Desktop Property: "awt.font.desktophints" +Desktop Property: "awt.font.desktophints"

    Modern desktops support various forms of text antialiasing (font smoothing).

    @@ -116,7 +117,7 @@ using a PropertyChangeListener :

    
    -tk.addPropertyChangeListener("awt.font.desktophints", pcl); 
    +tk.addPropertyChangeListener("awt.font.desktophints", pcl);
     
    Listening for changes is recommended as users can, on rare occasions, reconfigure a desktop environment whilst applications are running @@ -194,7 +195,7 @@ and dynamic updates will not be available. This is a typical behaviour if the JDK does not recognise the desktop environment, or it is one which has no such settings. The Headless toolkit is one such example. -Therefore it is important to test against null before using the map. +Therefore it is important to test against null before using the map.

  • If non-null the value will be a Map of RenderingHints such that every key is an instance of @@ -229,7 +230,7 @@ the per-device property name.

    Mouse Functionality

    -Desktop Property: "sun.awt.enableExtraMouseButtons" +Desktop Property: "sun.awt.enableExtraMouseButtons"

    This property determines if events from extra mouse buttons (if they are exist and are enabled by the underlying operating system) are allowed to be processed and posted into @@ -245,7 +246,7 @@ Current value could also be queried using getDesktopProperty("sun.awt.enableExtraMouseButtons") method.
    -If the property is set to {@code true} then +If the property is set to {@code true} then


    -If the property is set to {@code false} then +If the property is set to {@code false} then - +

    Overview of KeyboardFocusManager

    The focus model is centralized around a single class, @@ -160,7 +159,7 @@ define new focus cycle but only modifies the order by which its children are traversed "forward" and "backward". Focus traversal policy provider can be set using - setFocusTraversalPolicyProvider on the Container. + setFocusTraversalPolicyProvider on the Container.

    @@ -180,7 +179,7 @@ descendants.

    - Here is an example:
    Three groups as described below: ABCF BDE and DGH.

    Assume the following: @@ -193,7 +192,7 @@

  • G, H, E, and F are all Components. - + There are a total of three focus cycle roots in this example:
      @@ -213,7 +212,7 @@ implementation in the DefaultKeyboardFocusManager class. - +

      KeyboardFocusManager and Browser Contexts

      Some browsers partition applets in different code bases into separate @@ -229,7 +228,7 @@ owner, focused Window, or active Window, per ClassLoader. - +

      KeyEventDispatcher and KeyEventPostProcessor

      While the user's KeyEvents should generally be delivered to the focus @@ -272,7 +271,7 @@ KeyEventPostProcessor, and similar restrictions apply to its use in that capacity. - +

      FocusEvent and WindowEvent

      The AWT defines the following six event types central to the focus @@ -296,7 +295,7 @@ not a Frame or Dialog) when it is no longer the active Window.

    - +

    Event Delivery

    If the focus is not in java application and the user clicks on a focusable @@ -347,7 +346,7 @@ and VetoableChangeListener. - +

    Opposite Components and Windows

    Each event includes information about the "opposite" Component or @@ -371,7 +370,7 @@ using the opposite Component of a focus change that occurred within a top-level Window. - +

    Temporary FocusEvents

    FOCUS_GAINED and FOCUS_LOST events are @@ -380,7 +379,7 @@ Temporary FOCUS_LOST events are sent when a Component is losing the focus, but will regain the focus shortly. These events can be useful when focus changes are used as triggers for validation -of data. For instance, a text Component may want to commit its +of data. For instance, a text Component may want to commit its contents when the user begins interacting with another Component, and can accomplish this by responding to FOCUS_LOST events. However, if the FocusEvent received is temporary, @@ -402,8 +401,8 @@ When a Component receives a temporary FOCUS_LOST event, the event's opposite Component (if any) may receive a temporary FOCUS_GAINED event, but could also receive a permanent -FOCUS_GAINED event. Showing a Menu or PopupMenu, or -clicking or dragging a Scrollbar, should generate a temporary +FOCUS_GAINED event. Showing a Menu or PopupMenu, or +clicking or dragging a Scrollbar, should generate a temporary FOCUS_GAINED event. Changing the focused Window, however, will yield a permanent FOCUS_GAINED event for the new focus owner. @@ -416,7 +415,7 @@ Components. This method is not intended for general use, but exists instead as a hook for lightweight Component libraries, such as Swing. - +

    Focus Traversal

    Each Component defines its own Set of focus traversal keys for a given @@ -428,11 +427,11 @@ recursively inherits a Set from its parent, and ultimately from a context-wide default set on the current KeyboardFocusManager.

    -Using the AWTKeyStroke API, client code can specify -on which of two specific KeyEvents, KEY_PRESSED or +Using the AWTKeyStroke API, client code can specify +on which of two specific KeyEvents, KEY_PRESSED or KEY_RELEASED, the focus traversal operation will occur. Regardless of which KeyEvent is specified, however, all KeyEvents -related to the focus traversal key, including the associated +related to the focus traversal key, including the associated KEY_TYPED event, will be consumed, and will not be dispatched to any Component. It is a runtime error to specify a KEY_TYPED event as mapping to a focus traversal operation, @@ -475,7 +474,7 @@ normal focus traversal. Thus, the current KeyboardFocusManager maintains a reference to the "current" focus cycle root, which is global across all contexts. The -current focus cycle root is used to resolve the ambiguity. +current focus cycle root is used to resolve the ambiguity.

    For up-cycle traversal, the focus owner is set to the current focus owner's focus cycle root, and the current focus cycle root is set to @@ -491,10 +490,10 @@ root, then no focus traversal operation occurs. - +

    FocusTraversalPolicy

    - + A FocusTraversalPolicy defines the order in which Components within a particular focus cycle root or focus traversal policy provider are traversed. Instances of FocusTraversalPolicy can be shared across @@ -524,7 +523,7 @@

    -A FocusTraversalPolicy may optionally provide an +A FocusTraversalPolicy may optionally provide an algorithm for the following:

    Given a Window, the "initial" Component in that Window. The initial @@ -551,7 +550,7 @@ ancestor. Top-levels initialize their focus traversal policies using the context default policy. The context default policy is established by using KeyboardFocusManager. setDefaultFocusTraversalPolicy. - +

    AWT provides two standard FocusTraversalPolicy implementations for use by client code. @@ -573,14 +572,14 @@

  • DefaultFocusTraversalPolicy: A subclass of ContainerOrderFocusTraversalPolicy which redefines the fitness test. If client code has explicitly set the - focusability of a Component by either overriding + focusability of a Component by either overriding Component.isFocusTraversable() or Component.isFocusable(), or by calling - Component.setFocusable(boolean), then a + Component.setFocusable(boolean), then a DefaultFocusTraversalPolicy behaves exactly like a ContainerOrderFocusTraversalPolicy. If, however, the Component is relying on default focusability, then a - DefaultFocusTraversalPolicy will reject all + DefaultFocusTraversalPolicy will reject all Components with non-focusable peers.
    The focusability of a peer is implementation-dependent. Sun @@ -627,7 +626,7 @@

    The figure below shows an implicit focus transfer: -
    Implicit focus transfer.
    +
    Implicit focus transfer.
    Assume the following:

      @@ -653,7 +652,7 @@ All other applications, including pure AWT applications, will use DefaultFocusTraversalPolicy by default. - +

      Focus Traversal Policy Providers

      A Container that isn't a focus cycle root has an option to provide a @@ -674,7 +673,7 @@ If focus traversal policy provider property is set on a focus cycle root, it isn't considered a focus traversal policy provider and behaves just like any other focus cycle root. - +

      The main difference between focus cycle roots and focus traversal policy providers is that the latter allow focus to enter and leave them just as all other @@ -740,7 +739,7 @@

    - +

    Programmatic Traversal

    In addition to user-initiated focus traversal, client code can @@ -811,7 +810,7 @@ unchanged. - +

    Focusability

    A focusable Component can become the focus owner ("focusability") and @@ -825,7 +824,7 @@ change this default by calling Component.setFocusable(boolean). - +

    Focusable Windows

    To support palette windows and input methods, client code can prevent @@ -877,7 +876,7 @@ all such focus change requests will fail. In this case, the global focus owner will be cleared and the focused Window will remain unchanged. - +

    Requesting Focus

    @@ -949,7 +948,7 @@ a temporary state. See Temporary FocusEvents - +

    Focus and PropertyChangeListener

    Client code can listen to changes in context-wide focus state, or to @@ -957,7 +956,7 @@ PropertyChangeListeners.

    The KeyboardFocusManager supports the following properties: - +

    1. focusOwner: the focus owner
    2. focusedWindow: the focused Window @@ -977,7 +976,7 @@

      A PropertyChangeListener installed on the current KeyboardFocusManager will only see these changes within -the KeyboardFocusManager's context, even though the +the KeyboardFocusManager's context, even though the focus owner, focused Window, active Window, and current focus cycle root comprise the global focus state shared by all contexts. We believe this is less intrusive than requiring client code to pass @@ -1001,7 +1000,7 @@ following focus-related properties:

        -
      1. downCycleFocusTraversalKeys: the Container's Set of +
      2. downCycleFocusTraversalKeys: the Container's Set of DOWN_CYCLE_TRAVERSAL_KEYS
      3. focusTraversalPolicy: the Container's focus traversal policy @@ -1020,10 +1019,10 @@ focusCycleRoot property. A Window is always a focus cycle root; this property cannot change.

        - +

        Focus and VetoableChangeListener

        -The KeyboardFocusManager also supports +The KeyboardFocusManager also supports VetoableChangeListeners for the following properties:

          @@ -1054,13 +1053,13 @@ KeyboardFocusManager is free to attempt to dispatch this event and it is the responsibility of the VetoableChangeListener to veto it as well. In addition, -during processing of the FOCUS_GAINED event, the +during processing of the FOCUS_GAINED event, the KeyboardFocusManager may attempt to resync the global focus state by synthesizing another FOCUS_LOST event. This event must be vetoed just as the first FOCUS_LOST event was.

          -A KeyboardFocusManager may not hold any locks while -notifying PropertyChangeListeners of a state change. +A KeyboardFocusManager may not hold any locks while +notifying PropertyChangeListeners of a state change. This requirement is relaxed for VetoableChangeListeners, however. Therefore, client-definied VetoableChangeListeners should avoid acquiring additional locks inside @@ -1089,13 +1088,13 @@ vetoed focus changes and recovery attempts. - +

          Z-Order

          On some native windowing systems, the Z-order of a Window can affect -its focused or active (if applicable) state. On Microsoft Windows, the -top-most Window is naturally the focused Window as well. However, on -Solaris, many window managers use a point-to-focus model that ignores +its focused or active (if applicable) state. On Microsoft Windows, the +top-most Window is naturally the focused Window as well. However, on +Solaris, many window managers use a point-to-focus model that ignores Z-order in determining the focused Window. When focusing or activating Windows, the AWT adheres to the UI @@ -1114,8 +1113,8 @@ Microsoft Windows and Solaris is as follows:

          • Window.toFront():
            - Microsoft Windows: The Window is moved to front, if possible. - While we will always be able to move this Window in front of other + Microsoft Windows: The Window is moved to front, if possible. + While we will always be able to move this Window in front of other Windows in the same VM, Windows 98 and Windows 2000 do not allow an application to bring any of its windows to the front unless one of that application's windows is already in the foreground. In @@ -1129,15 +1128,15 @@ window manager, the focused Window will remain unchanged.
          • Window.toBack():
            - Microsoft Windows: The Window is moved to back. Note however - that Microsoft Windows insists that an owned Window always be in - front of all of its recursive owners. Thus, after the completion of - this operation, the Window may not be the lowest Java Window in the - Z-order. If the Window, or any of its owners, was the focused Window, + Microsoft Windows: The Window is moved to back. Note however + that Microsoft Windows insists that an owned Window always be in + front of all of its recursive owners. Thus, after the completion of + this operation, the Window may not be the lowest Java Window in the + Z-order. If the Window, or any of its owners, was the focused Window, then the focused Window is reset to the top-most Window in the VM.
            - Solaris: The Window is moved to back. Like Microsoft Windows, - some window managers insist than an owned Window always be in front + Solaris: The Window is moved to back. Like Microsoft Windows, + some window managers insist than an owned Window always be in front of all of its recursive owners. Thus, after the completion of this operation, the Window may not be the lowest Java Window in the Z-order. If the Window was the focused Window, it will lose @@ -1156,7 +1155,7 @@
          • Window.hide()/Window.setVisible(false)/Window.dispose()/ Frame.setState(ICONIFIED):
            - Microsoft Windows: If the Window was the focused Window, the focused + Microsoft Windows: If the Window was the focused Window, the focused Window is reset to a window chosen by the OS, or to no window. The window may be in a native application, or a Java application in another VM. @@ -1169,7 +1168,7 @@ application in another VM.
          - +

          Replacing DefaultKeyboardFocusManager

          KeyboardFocusManagers are pluggable at the browser context @@ -1238,7 +1237,7 @@ heavyweight Container, not the focus owner.

        1. A FOCUS_LOST event must be retargeted to the focus owner. Again, this is necessary because the peer layer is - unaware of lightweight Components. + unaware of lightweight Components.
        2. A WINDOW_LOST_FOCUS event must be retargeted to the focused Window. The implementation of the Window class may cause the native focused Window to differ from the Java @@ -1269,7 +1268,7 @@ to set the global focus owner to a non-focusable Component.
        3. If the KeyboardFocusManager attempts to set the global focused Window to a non-focusable Window. -
        4. If the change is rejected by an installed +
        5. If the change is rejected by an installed VetoableChangeListener.

          @@ -1302,13 +1301,13 @@ recent focus owner.

        6. The KeyboardFocusManager must ensure that the opposite Component or Window are as accurate as the native - windowing platform permits. For example, the + windowing platform permits. For example, the KeyboardFocusManager may need to retarget the opposite Component to a lightweight child of the heavyweight initially specified by the peer layer.
          If the peer layer states that the opposite Component or Window is - null, it is acceptable for the + null, it is acceptable for the KeyboardFocusManager to propagate this value. null indicates that it is highly probably that no other Component or Window was involved @@ -1325,7 +1324,7 @@ events. - +

          Incompatibilities with Previous Releases

          Cross-platform changes:

            @@ -1343,7 +1342,7 @@
          1. KeyListeners installed on Components will no longer see KeyEvents that map to focus traversal operations, and - Component.handleEvent() will no longer be invoked + Component.handleEvent() will no longer be invoked for such events. Previously, AWT Components saw these events and had an opportunity to consume them before AWT initiated focus traversal. Code that requires this @@ -1352,7 +1351,7 @@ itself. Alternately, the code can use an AWTEventListener or KeyEventDispatcher to pre-listen to all - KeyEvents. + KeyEvents.

          Changes specific to Microsoft Windows:

            --- old/src/java.desktop/share/classes/java/awt/doc-files/Modality.html 2017-10-23 13:51:03.000000000 -0700 +++ new/src/java.desktop/share/classes/java/awt/doc-files/Modality.html 2017-10-23 13:51:03.000000000 -0700 @@ -1,5 +1,11 @@ + + + + + The AWT Modality + - - - - - - - The AWT Modality - - + - - -

            The AWT Modality

            +

            The AWT Modality

            This document, together with the API documentation for modality-related @@ -53,7 +49,7 @@

          1. Examples
          2. - +

            Definitions

            @@ -63,7 +59,7 @@ Every window belongs to some document — its root can be found as the closest ancestor window without an owner.

            - + Modal blocked window - a window, that:

            • doesn't receive any user input events @@ -73,7 +69,7 @@

              Warning! Some window managers allow users to change the window - Z-order in an arbitrary way — in that case the last requirement + Z-order in an arbitrary way — in that case the last requirement may not be met.
              @@ -87,7 +83,7 @@ then all its owned windows and child components are also excluded.

              Scope of blocking (SB) - the set of windows (instances of - java.awt.Window and all derived classes) that are blocked by + java.awt.Window and all derived classes) that are blocked by the modal dialog while it is visible.


              Note: Everywhere in this document the notion of "window" is equal @@ -95,7 +91,7 @@ an instance of java.awt.Window or any descendant class.
              - +

              Modality types

              @@ -159,7 +155,7 @@ dialog may have no effect until it is hidden and then shown again.


  • - +

    Show/hide blocking

    @@ -171,7 +167,7 @@

    Showing the modal dialog: "M"
    When modal dialog M is shown, all the visible windows fall into one of - three distinct groups: + three distinct groups:

    - +

    Compatibility

    The default modality type is application-modal. It is used by the API - calls: Dialog.setModal(true), + calls: Dialog.setModal(true), Dialog(owner, true), etc. Prior to JDK 6 the default type was toolkit-modal, but the only distinction between application- and toolkit-modality is for applets and applications launched from Java Web Start. - +

    Examples

    @@ -429,7 +425,7 @@ it's in the same application
  • Di is shown
  • Di becomes blocked by Dii — it's its owner
    -
  • Diii remains unblocked — it blocks Dii and +
  • Diii remains unblocked — it blocks Dii and Dii blocks Di

    --- old/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/bmp_metadata.html 2017-10-23 13:51:04.000000000 -0700 +++ new/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/bmp_metadata.html 2017-10-23 13:51:04.000000000 -0700 @@ -1,8 +1,11 @@ - - + + + + BMP Metadata Format Specification + -BMP Metadata Format Specification - - -

    -BMP Metadata Format Specification -

    +

    BMP Metadata Format Specification

    The XML schema for the native image metadata format is as follows: @@ -108,7 +106,7 @@ </xsd:element> <!-- Color space --> - <xsd:element name="ColorSpaceType" type="xsd:unsignedInt" + <xsd:element name="ColorSpaceType" type="xsd:unsignedInt" minOccurs="0"/> <!-- CIE XYZ for the LCS_CALIBRATED_RGB color space --> --- old/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html 2017-10-23 13:51:05.000000000 -0700 +++ new/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html 2017-10-23 13:51:05.000000000 -0700 @@ -1,8 +1,11 @@ - - + + + + GIF Metadata Format Specification + -GIF Metadata Format Specification - - - + -

    -GIF Metadata Format Specification -

    - -

    -GIF Stream Metadata Format Specification -

    +

    GIF Metadata Format Specification

    + +

    GIF Stream Metadata Format Specification

    @@ -59,7 +55,7 @@

     <!DOCTYPE "javax_imageio_gif_stream_1.0" [
     
    -  <!ELEMENT "javax_imageio_gif_stream_1.0" (Version?, 
    +  <!ELEMENT "javax_imageio_gif_stream_1.0" (Version?,
         LogicalScreenDescriptor?, GlobalColorTable?)>
     
         <!ELEMENT "Version" EMPTY>
    @@ -98,7 +94,7 @@
           <!-- The global color table -->
           <!-- Min children: 2 -->
           <!-- Max children: 256 -->
    -      <!ATTLIST "GlobalColorTable" "sizeOfGlobalColorTable" ("2" | 
    +      <!ATTLIST "GlobalColorTable" "sizeOfGlobalColorTable" ("2" |
             "4" | "8" | "16" | "32" | "64" | "128" | "256") #REQUIRED>
             <!-- The number of entries in the global color table -->
           <!ATTLIST "GlobalColorTable" "backgroundColorIndex" #CDATA
    @@ -135,10 +131,8 @@
               <!-- Max value: 255 (inclusive) -->
     ]>
     
    - -

    -GIF Image Metadata Format Specification -

    + +

    GIF Image Metadata Format Specification

    The GIF image metadata format encodes the image descriptor, local @@ -180,8 +174,8 @@

     <!DOCTYPE "javax_imageio_gif_image_1.0" [
     
    -  <!ELEMENT "javax_imageio_gif_image_1.0" (ImageDescriptor?, 
    -    LocalColorTable?, GraphicControlExtension?, PlainTextExtension?, 
    +  <!ELEMENT "javax_imageio_gif_image_1.0" (ImageDescriptor?,
    +    LocalColorTable?, GraphicControlExtension?, PlainTextExtension?,
         ApplicationExtensions?, CommentExtensions?)>
     
         <!ELEMENT "ImageDescriptor" EMPTY>
    @@ -214,7 +208,7 @@
           <!-- The local color table -->
           <!-- Min children: 2 -->
           <!-- Max children: 256 -->
    -      <!ATTLIST "LocalColorTable" "sizeOfLocalColorTable" ("2" | 
    +      <!ATTLIST "LocalColorTable" "sizeOfLocalColorTable" ("2" |
             "4" | "8" | "16" | "32" | "64" | "128" | "256") #REQUIRED>
             <!-- The number of entries in the local color table -->
           <!ATTLIST "LocalColorTable" "sortFlag" ("TRUE" | "FALSE")
    @@ -246,13 +240,13 @@
     
         <!ELEMENT "GraphicControlExtension" EMPTY>
           <!-- A graphic control extension -->
    -      <!ATTLIST "GraphicControlExtension" "disposalMethod" ("none" | 
    -        "doNotDispose" | "restoreToBackgroundColor" | 
    -        "restoreToPrevious" | "undefinedDisposalMethod4" | 
    -        "undefinedDisposalMethod5" | "undefinedDisposalMethod6" | 
    +      <!ATTLIST "GraphicControlExtension" "disposalMethod" ("none" |
    +        "doNotDispose" | "restoreToBackgroundColor" |
    +        "restoreToPrevious" | "undefinedDisposalMethod4" |
    +        "undefinedDisposalMethod5" | "undefinedDisposalMethod6" |
             "undefinedDisposalMethod7") #REQUIRED>
             <!-- The disposal method for this frame -->
    -      <!ATTLIST "GraphicControlExtension" "userInputFlag" ("TRUE" | 
    +      <!ATTLIST "GraphicControlExtension" "userInputFlag" ("TRUE" |
             "FALSE") #REQUIRED>
             <!-- True if the frame should be advanced based on user input -->
           <!ATTLIST "GraphicControlExtension" "transparentColorFlag" (
    @@ -350,8 +344,7 @@
     

    - -

    +
  • @@ -399,9 +392,7 @@
    Mapping of Standard to GIF Native Stream Metadata
    /Version@value
    - -
    @@ -443,7 +434,6 @@ "TRUE")
    Mapping of Standard to GIF Native Image Metadata
    -
    --- old/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html 2017-10-23 13:51:06.000000000 -0700 +++ new/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html 2017-10-23 13:51:06.000000000 -0700 @@ -1,8 +1,11 @@ - - + + + + JPEG Metadata Format Specification and Usage Notes + -JPEG Metadata Format Specification and Usage Notes - - - + -

    -JPEG Metadata Format Specification and Usage Notes -

    +

    JPEG Metadata Format Specification and Usage Notes

    JPEG Metadata
    @@ -46,11 +44,11 @@ Image Metadata DTD
    Stream Metadata DTD

    -NOTE: It is important to call dispose() -on the JPEG reader and writer objects when they are no longer needed, as -they consume significant native resources which are not adequately recovered -by garbage collection. Both reader and writer call dispose() -in their finalizers, but those finalizers may not be called before the native +NOTE: It is important to call dispose() +on the JPEG reader and writer objects when they are no longer needed, as +they consume significant native resources which are not adequately recovered +by garbage collection. Both reader and writer call dispose() +in their finalizers, but those finalizers may not be called before the native code has exhausted native memory.

    @@ -58,45 +56,45 @@ The JPEG writer does not support replacing pixels.

    -JPEG Metadata +JPEG Metadata

    JPEG metadata consists of the data contained in marker segments in a JPEG stream. The image metadata object returned from a read describes the -contents of the marker segments between the SOI marker and -the EOI marker for that image. The image metadata object -passed into a write determines the contents of the stream between the -SOI marker and the EOI marker for that image, +contents of the marker segments between the SOI marker and +the EOI marker for that image. The image metadata object +passed into a write determines the contents of the stream between the +SOI marker and the EOI marker for that image, subject to the controls in any ImageWriteParam.

    -Stream metadata is used only for tables-only images found (or to be -placed) at the beginning of a stream containing abbreviated images. -Tables-only images are not treated as images and do not consume an +Stream metadata is used only for tables-only images found (or to be +placed) at the beginning of a stream containing abbreviated images. +Tables-only images are not treated as images and do not consume an image index. The stream metadata object returned from a read describes the -contents of the marker segments between the SOI marker and -the EOI marker for the single tables-only image at the -beginning of the stream, if one is present. If no tables-only image is -present at the front of the stream, the getStreamMetadata -method of ImageReader returns null. If -stream metadata is provided to the writer, a single tables-only image -containing the tables from the stream metadata object will be written at +contents of the marker segments between the SOI marker and +the EOI marker for the single tables-only image at the +beginning of the stream, if one is present. If no tables-only image is +present at the front of the stream, the getStreamMetadata +method of ImageReader returns null. If +stream metadata is provided to the writer, a single tables-only image +containing the tables from the stream metadata object will be written at the beginning of the stream. If the stream metadata object contains no tables, default tables will be written. As the sole purpose of stream -metadata is for specifying tables-only images at the front of abbreviated -streams, the stream metadata argument is useful only on the -ImageWriter.prepareWriteSequence method. It is ignored on all +metadata is for specifying tables-only images at the front of abbreviated +streams, the stream metadata argument is useful only on the +ImageWriter.prepareWriteSequence method. It is ignored on all other methods. -

    -The ImageWriter.getDefaultStreamMetadata method returns an -object containing the tables from the ImageWriteParam argument, -if it is a JPEGImageWriteParam and contains tables. Otherwise, +

    +The ImageWriter.getDefaultStreamMetadata method returns an +object containing the tables from the ImageWriteParam argument, +if it is a JPEGImageWriteParam and contains tables. Otherwise, the returned object will contain default tables. -

    The ImageWriter.getDefaultImageMetadata method returns a -metadata object containing no tables if the -ImageWriteParam argument contains tables. Otherwise the -returned metadata object will contain default visually lossless tables. +

    The ImageWriter.getDefaultImageMetadata method returns a +metadata object containing no tables if the +ImageWriteParam argument contains tables. Otherwise the +returned metadata object will contain default visually lossless tables. Of course, only a JPEGImageWriteParam may contain tables.

    @@ -105,59 +103,59 @@ metadata will.

    -Abbreviated Streams +Abbreviated Streams

    -Both the reader and the writer retain their tables from one operation to the -next, thus permitting the use of abbreviated streams quite naturally, with a -few minor restrictions: +Both the reader and the writer retain their tables from one operation to the +next, thus permitting the use of abbreviated streams quite naturally, with a +few minor restrictions:
      -
    1. Abbreviated streams may contain only one tables-only image, which must +
    2. Abbreviated streams may contain only one tables-only image, which must come first in the stream. Subsequent tables-only images will cause undefined behavior.
    3. Abbreviated streams must be read fully and in order. No random access - is allowed, in either direction. The same image may be read multiple + is allowed, in either direction. The same image may be read multiple times. If a call is made with an image index that is not the same as or one greater than the most recent call (or 0 if no calls have been made), then an IllegalArgumentException is thrown.
    -These restrictions mean that streams may contain abbreviated images +These restrictions mean that streams may contain abbreviated images interspersed with images containing tables. As required by JPEG, any tables appearing in the stream override previous tables, regardless of the source -of the previous tables. +of the previous tables.

    Note that once a tables-only image has been read, it's contents is available as stream metadata from the reader until either another tables-only image is read from another stream or the reader is reset. Changing the input does not reset the stream metadata. This is useful for reading the tables from -one file, then changing the input to read an abbreviated stream containing +one file, then changing the input to read an abbreviated stream containing a sequence of images. The tables will be used automatically, and will remain available as "stream" metadata.

    -Abbreviated streams are written using the sequence methods of -ImageWriter. Stream metadata is used to write a tables-only +Abbreviated streams are written using the sequence methods of +ImageWriter. Stream metadata is used to write a tables-only image at the beginning of the stream, and the tables are set up for use, using -ImageWriter.prepareWriteSequence. If no stream metadata is -supplied to ImageWriter.prepareWriteSequence, then no +ImageWriter.prepareWriteSequence. If no stream metadata is +supplied to ImageWriter.prepareWriteSequence, then no tables-only image is written. If stream metadata containing no tables is supplied to ImageWriter.prepareWriteSequence, then a tables-only image containing default visually lossless tables is written.

    -Sources of Tables +Sources of Tables

    -Images are written with tables if tables are present in their metadata objects +Images are written with tables if tables are present in their metadata objects or without them if no tables are present in their metadata objects. If no -metadata object is present then the tables are written. The tables used for -compression are taken from one of the following sources, which are consulted -in order: +metadata object is present then the tables are written. The tables used for +compression are taken from one of the following sources, which are consulted +in order:

    1. If there is an ImageWriteParam and the compression mode is set to EXPLICIT, default tables constructed using the - quality setting are used. They are written only if the metadata - contains tables or if there is no metadata, but they replace the + quality setting are used. They are written only if the metadata + contains tables or if there is no metadata, but they replace the tables in the metadata.
    2. If there is an ImageWriteParam and the compression mode is set to DEFAULT, default visually lossles tables are used. @@ -176,39 +174,39 @@
    -This ordering implements the design intention that tables should be included -in JPEGImageWriteParams only as a means of specifying tables +This ordering implements the design intention that tables should be included +in JPEGImageWriteParams only as a means of specifying tables when no other source is available, and this can occur only when writing to an -abbreviated stream without tables using known non-standard tables for +abbreviated stream without tables using known non-standard tables for compression.

    -When reading, tables in a JPEGImageReadParam are consulted only -if tables have not been set by any previous read. Tables set from a -JPEGImageReadParam are overridden by any tables present in the +When reading, tables in a JPEGImageReadParam are consulted only +if tables have not been set by any previous read. Tables set from a +JPEGImageReadParam are overridden by any tables present in the stream being read.

    -Note that if no image metadata object is specified for a particular image, a +Note that if no image metadata object is specified for a particular image, a default object is used, which includes default tables.

    -Colorspace Transformations and Conventional Markers +Colorspace Transformations and Conventional Markers

    Colorspace transformations are controlled by the destination type for both reading and writing of images. When Rasters are -read, no colorspace transformation is performed, and any destination type -is ignored. A warning is sent to any listeners if a destination type is -specified in this case. When Rasters are written, any +read, no colorspace transformation is performed, and any destination type +is ignored. A warning is sent to any listeners if a destination type is +specified in this case. When Rasters are written, any destination type is used to interpret the bands. This might result in a -JFIF or Adobe header being written, or different component ids being written -to the frame and scan headers. If values present in a metadata object do not -match the destination type, the destination type is used and a warning is sent +JFIF or Adobe header being written, or different component ids being written +to the frame and scan headers. If values present in a metadata object do not +match the destination type, the destination type is used and a warning is sent to any listeners.

    -Optional ColorSpace support: +Optional ColorSpace support: Handling of PhotoYCC (YCC), PhotoYCCA (YCCA), RGBA and YCbCrA color spaces by the standard plugin, as described below, is dependent on capabilities of the libraries used to interpret the JPEG data. Thus all consequential @@ -219,7 +217,7 @@ When writing, an Exception may be thrown if no suitable conversion can be applied before encoding. But where the support for these color spaces is available, the behavior -must be as documented. +must be as documented.

    When reading, the contents of the stream are interpreted by the usual @@ -232,7 +230,7 @@ the YCbCr is converted to RGB according to the formulas given in the JFIF spec, and the ICC profile is assumed to refer to the resulting RGB space. -

  • If an Adobe APP14 marker segment is present, the +
  • If an Adobe APP14 marker segment is present, the colorspace is determined by consulting the transform flag. The transform flag takes one of three values:
  • If neither marker segment is present, the following procedure is @@ -253,9 +251,9 @@ YCbCr. Subject to the availability of the optional color space support described above, if these values are 1-4 for a 4-channel image, - then the image is assumed to be YCbCrA. - If these values are > 4, they are checked - against the ASCII codes for 'R', 'G', 'B', 'A', 'C', 'c'. These can + then the image is assumed to be YCbCrA. + If these values are > 4, they are checked + against the ASCII codes for 'R', 'G', 'B', 'A', 'C', 'c'. These can encode the following colorspaces:


    RGB @@ -263,28 +261,28 @@
    YCC (as 'Y','C','c'), assumed to be PhotoYCC
    YCCA (as 'Y','C','c','A'), assumed to be PhotoYCCA

    - Otherwise, 3-channel subsampled images are assumed to be YCbCr, - 3-channel non-subsampled images are assumed to be RGB, 4-channel + Otherwise, 3-channel subsampled images are assumed to be YCbCr, + 3-channel non-subsampled images are assumed to be RGB, 4-channel subsampled images are assumed to be YCCK, and 4-channel, non-subsampled images are assumed to be CMYK.

  • All other images are declared uninterpretable and an exception is - thrown if an attempt is made to read one as a - BufferedImage. Such an image may be read only as a + thrown if an attempt is made to read one as a + BufferedImage. Such an image may be read only as a Raster. If an image is interpretable but there is no Java - ColorSpace available corresponding to the encoded - colorspace (e.g. YCbCr), then + ColorSpace available corresponding to the encoded + colorspace (e.g. YCbCr), then ImageReader.getRawImageType will return null. -Once an encoded colorspace is determined, then the target colorspace is +Once an encoded colorspace is determined, then the target colorspace is determined as follows: