Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8130264

Change the mechanism by which JDK loads the platform-specific PrinterJob implementation


    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 6, 7, 8, 9
    • Fix Version/s: 12
    • Component/s: client-libs
    • Labels:
    • Subcomponent:
    • Introduced In Version:
    • Resolved In Build:


      Whilst examining the cases in which core reflection internally in the JDK it
      was noted that the implementation class of java.awt.print.PrinterJob is
      located via a System property java.awt.printerjob.

      This lead to a question as to whether this is a "pluggable" SPI that
      can be over-ridden by external code. There was in fact no such intention
      and it was just a convenience. See the docs in System.c which say :

        /* Note: java.awt.printerjob is an implementation private property which
           * just happens to have a java.* name because it is referenced in
           * a java.awt class. It is the mechanism by which the implementation
           * finds the appropriate class in the JRE for the platform.
           * It is explicitly not designed to be overridden by clients as
           * a way of replacing the implementation class, and in any case
           * the mechanism by which the class is loaded is constrained to only
           * find and load classes that are part of the JRE.
           * This property may be removed if that mechanism is redesigned
          PUTPROP(props, "java.awt.printerjob", sprops->printerJob);

      It may be best to do that and stop this internal property from polluting the public properties.


          Issue Links



              • Assignee:
                prr Philip Race
                prr Philip Race
              • Votes:
                0 Vote for this issue
                4 Start watching this issue


                • Created: