ADDITIONAL SYSTEM INFORMATION :
I tried with Java 11, but I see the code hasn't changed recently.
Working under Linux (Xubuntu 22.04) here, so CUPS is the printing system.

A DESCRIPTION OF THE PROBLEM :
(Redirected from https://github.com/adoptium/adoptium-support/issues/559 and https://bugs.launchpad.net/ubuntu/+source/openjdk-lts/+bug/1985042)

When doing:

HashPrintRequestAttributeSet printRequestAttributes = new HashPrintRequestAttributeSet();
printRequestAttributes.add(new Copies(2));
if (selectedPrintService.isAttributeCategorySupported(SheetCollate.class)) {
    printRequestAttributes.add(SheetCollate.COLLATED); // ignored...
}

DocPrintJob printJob = selectedPrintService.createPrintJob();
printJob.print(printDocument, printRequestAttributes);

the .add(SheetCollate.COLLATED) line is completely ignored.

I think the problem is that the underlying lpr command does not get the -o collate=true option.

And I think this is due to UnixPrintJob.print() not implementing that option, while it should be an easy one.

It seems to me that the Java source code is completely lacking the management for that option under Unix:

https://github.com/openjdk/jdk/blob/2d4d850813235a7533cd3bbf776adf69f90f02e6/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#L212

    //CUPS has no sheet collate?

Yes, it has, for the last two decades at least :)

https://github.com/openjdk/jdk/blob/2d4d850813235a7533cd3bbf776adf69f90f02e6/src/java.desktop/unix/classes/sun/print/UnixPrintJob.java#L838-L904
It would be enough to pass the "-o collate" option to lpr.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
As stated above, just try:
printRequestAttributes.add(SheetCollate.COLLATED);

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The job should be collated, i.e. I should get pages 1,2,3,1,2,3...
ACTUAL -
...instead I keep on getting pages 1,1,2,2,3,3.

CUSTOMER SUBMITTED WORKAROUND :
As a workaround, one could add a default option to the printer via lpoptions.

FREQUENCY : always