J2SE Version (please include all output from java -version flag):
java version "1.8.0_75"
Java(TM) SE Runtime Environment (build 1.8.0_75-b07)
Java HotSpot(TM) Client VM (build 25.75-b07, mixed mode)

Does this problem occur on J2SE 6ux or 7ux or 8ux?  Yes / No (pick one)
  8U72, maybe more

Operating System Configuration Information (be specific):
  HP EliteBook 8760W
  Windows 7 Professional 64-bit (SP1)
  8G Ram

Bug Description:
  Having a trouble to have the print jobs finish when used a page range.  It 
might be coming from a thread race condition.

  The printer queue shows them as being completely spooled and ready to 
print, but the java thread that initiated the print is stuck.

---------------------------------------------------
com.sun.prism.j2d.print.J2DPrinterJob

The only place that pageDone is set to "true" is in waitForNextPage(int 
pageIndex)

If pJob2D.print() ever completes, and sets jobDone to true, waitForNextPage() may never be called. 
If this occurs, than the wait loop that the initiating thread is stuck in will never return.
It seems like the wait loops should always be checking on error and termination conditions.

---------------------------------------------------

                pJob2D.print(printReqAttrSet);
                jobDone = true;

        public int print(Graphics g, PageFormat pf, int pageIndex) {
            if (jobError || jobDone || !getPage(pageIndex)) {   *** If the 
jobDone is true, getPage() will not be called ***
                return Printable.NO_SUCH_PAGE;
            }

                while (!pageDone) { *** Not checking to see if an error 
occurred or if the job is done. ***
                    synchronized (monitor) {
                        try {
                            monitor.wait(1000);
                        } catch (InterruptedException e) {
                        }
                    }
                }

---------------------------------------------------

On a side note, these 1 second wait loops are way too long.  My pages print almost instantaneously.  These waits make these jobs take an order of 
magnitude longer to spool.  At the very least, they should be cut in half (or 
a tenth) which, in the greater scheme of things, would likely not put any 
significant burden on platforms currently capable of printing.

The real solution would actually be to "notify()" the "monitor" object when a 
page was completed so that it wouldn't have to always incur that 1 second wait to begin with.

Steps to Reproduce (be specific):

In the real application, this time slice hits every time.  In my test program, it does not and not sure why. (Threads...)

still working an creating a test program that will force the race condition 
to occur.