Re: RFR: 8247370: Clean up unused printing code in awt_PrintJob.cpp

[Prasanta Sadhukhan]

On Thu, 18 Mar 2021 22:59:57 GMT, Phil Race  wrote:

> This removes a long time un-used code path.

Maybe we should put noreg-cleanup in JBS.

-

Marked as reviewed by psadhukhan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3083

Re: RFR: 8247370: Clean up unused printing code in awt_PrintJob.cpp

[Sergey Bylokhov]

On Thu, 18 Mar 2021 22:59:57 GMT, Phil Race  wrote:

> This removes a long time un-used code path.

Marked as reviewed by serb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3083

Re: Legacy Apple com.apple.eio.FileManager (in module java.desktop) removed at jdk 16?

[Michael Hall]

> On Mar 18, 2021, at 6:35 PM, Philip Race  wrote:
> 
> Many of the com.apple APIs were obsoleted in JDK 9 with 
> http://openjdk.java.net/jeps/272 
> 
> We (you and I) even discussed this and the absence from there of FileManager 
> 3 1/2 years ago 
> https://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013120.html 
> 
> 
> It was left off that you wrote here
> https://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013131.html 
> 
> 
> > All right. If RFE is in fact the correct way to go in resolving the status 
> > of the code I will try to figure out how to do that. 
> 
> And you did in fact file such an RFE 
> https://bugs.openjdk.java.net/browse/JDK-8187981 
>  but unfortunately it seems
> to be in "other-libs" and I don't know who even looks at that category and 
> don't know what really belongs there.
> core-libs would have been better. I've moved it but it probably needs more 
> than that to get action.
> 

I remember talking about it and at least temporarily kept it from getting 
eliminated. Appreciated that. I don’t remember the RFE. 

Google 
com.apple.eio.FileManager 2020
19,300 hits.
How many are active current actual uses I don’t know. 

I have a sort of involved workaround I will go ahead on. 

Up to you if you think there’s not enough use left to continue providing it. 
But it is not internal if that’s why it’s gone.

Re: Legacy Apple com.apple.eio.FileManager (in module java.desktop) removed at jdk 16?

[Philip Race]

Many of the com.apple APIs were obsoleted in JDK 9 with 
http://openjdk.java.net/jeps/272


We (you and I) even discussed this and the absence from there of 
FileManager 3 1/2 years ago

https://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013120.html

It was left off that you wrote here
https://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013131.html

> All right. If RFE is in fact the correct way to go in resolving the 
status of the code I will try to figure out how to do that.


And you did in fact file such an RFE 
https://bugs.openjdk.java.net/browse/JDK-8187981 but unfortunately it seems
to be in "other-libs" and I don't know who even looks at that category 
and don't know what really belongs there.
core-libs would have been better. I've moved it but it probably needs 
more than that to get action.


-phil.



On 3/18/21 2:20 PM, Michael Hall wrote:



On Mar 18, 2021, at 3:29 PM, Philip Race  wrote:

I think this is because of https://bugs.openjdk.java.net/browse/JDK-8256299

JDK 16   release notes here : http://jdk.java.net/16/release-notes


I think I ran into a couple related issues. I had a check to see if default 
Toolkit gave me a Sun class for some functionality VirtualBox seemed to have 
issues with. I turned it off. I’ll still have to test to see if that gives me 
VirtualBox issues.

For com.apple.eio.FileManager I personally would argue that it was a public not 
a internal API. It was meant to provide some Mac specific file niceties to 
developers.

I had some code on Github based on the com.apple.eio.FileManager code that I 
think the macport had as Oracle class exception. I think I reworked it based on 
a Mac nio FileSystem I did. I can probably with some work get to work for my 
application. Maybe eve possibly get it to work fairly easily for other apps. If 
this change is permanent.

It’s possible you might hear from some other developers who have older Mac java 
code that made use of this API.

Re: Legacy Apple com.apple.eio.FileManager (in module java.desktop) removed at jdk 16?

[Michael Hall]

> On Mar 18, 2021, at 6:13 PM, Alan Snyder  wrote:
> 
> I use moveToTrash and revealInFinder, but only with JDK 8. In later JDKs I 
> use Desktop.moveToTrash and browseFileDirectory.
> 

Desktop eliminated the need for some of the FileManager code. I use findFolder 
to try and determine appropriate file locations on OS/X.

if (option == USER) {
f = new 
File(FileManager.findFolder(FileManager.kUserDomain, 
FileManager.OSTypeToInt("asup")),app);
if (!f.exists()) f.mkdir();
return f.toPath();  
}

else if (option == LOG) {
f = new 
File(FileManager.findFolder(FileManager.kUserDomain, 
FileManager.OSTypeToInt("logs")),app);
if (!f.exists()) f.mkdir();
return f.toPath();
}

Thats the code having problems now. I may have other forgotten uses scattered 
across the application.

Re: Legacy Apple com.apple.eio.FileManager (in module java.desktop) removed at jdk 16?

[Alan Snyder]

I use moveToTrash and revealInFinder, but only with JDK 8. In later JDKs I use 
Desktop.moveToTrash and browseFileDirectory.

> On Mar 18, 2021, at 2:20 PM, Michael Hall  wrote:
> 
> 
> 
>> On Mar 18, 2021, at 3:29 PM, Philip Race  wrote:
>> 
>> I think this is because of https://bugs.openjdk.java.net/browse/JDK-8256299
>> 
>> JDK 16   release notes here : http://jdk.java.net/16/release-notes
>> 
> 
> I think I ran into a couple related issues. I had a check to see if default 
> Toolkit gave me a Sun class for some functionality VirtualBox seemed to have 
> issues with. I turned it off. I’ll still have to test to see if that gives me 
> VirtualBox issues.
> 
> For com.apple.eio.FileManager I personally would argue that it was a public 
> not a internal API. It was meant to provide some Mac specific file niceties 
> to developers.
> 
> I had some code on Github based on the com.apple.eio.FileManager code that I 
> think the macport had as Oracle class exception. I think I reworked it based 
> on a Mac nio FileSystem I did. I can probably with some work get to work for 
> my application. Maybe eve possibly get it to work fairly easily for other 
> apps. If this change is permanent.
> 
> It’s possible you might hear from some other developers who have older Mac 
> java code that made use of this API. 
> 

RFR: 8247370: Clean up unused printing code in awt_PrintJob.cpp

[Phil Race]

This removes a long time un-used code path.

-

Commit messages:
 - 8247370: Clean up unused printing code in awt_PrintJob.cpp

Changes: https://git.openjdk.java.net/jdk/pull/3083/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3083&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247370
  Stats: 29 lines in 1 file changed: 0 ins; 19 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3083.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3083/head:pull/3083

PR: https://git.openjdk.java.net/jdk/pull/3083

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM [v3]

[Sergey Bylokhov]

On Wed, 17 Mar 2021 00:57:24 GMT, Henry Jen  wrote:

>> This patch ensure launcher won't crash JVM for the new static Methods from 
>> local/anonymous class on MacOS.
>> 
>> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug 
>> when the launcher trying to grab class name to be displayed as the 
>> Application name on the menu.
>> 
>> The fix is to not setting name, test shows that GUI java application shows 
>> 'bin' as the application name. It's possible for us to set the name to 
>> something more friendly, for example, "Java", but I am not sure that should 
>> be launcher's responsibility to choose such a default name. It seems to me 
>> the consumer of the JAVA_MAIN_CLASS_%d environment variable should be 
>> responsible to pick such name in case the environment variable is not set.
>
> Henry Jen has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Add copyright and another test case

Looks fine from the client point of view.

-

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2999

Re: Legacy Apple com.apple.eio.FileManager (in module java.desktop) removed at jdk 16?

[Michael Hall]

> On Mar 18, 2021, at 3:29 PM, Philip Race  wrote:
> 
> I think this is because of https://bugs.openjdk.java.net/browse/JDK-8256299
> 
> JDK 16   release notes here : http://jdk.java.net/16/release-notes
> 

I think I ran into a couple related issues. I had a check to see if default 
Toolkit gave me a Sun class for some functionality VirtualBox seemed to have 
issues with. I turned it off. I’ll still have to test to see if that gives me 
VirtualBox issues.

For com.apple.eio.FileManager I personally would argue that it was a public not 
a internal API. It was meant to provide some Mac specific file niceties to 
developers.

I had some code on Github based on the com.apple.eio.FileManager code that I 
think the macport had as Oracle class exception. I think I reworked it based on 
a Mac nio FileSystem I did. I can probably with some work get to work for my 
application. Maybe eve possibly get it to work fairly easily for other apps. If 
this change is permanent.

It’s possible you might hear from some other developers who have older Mac java 
code that made use of this API. 

Re: Legacy Apple com.apple.eio.FileManager (in module java.desktop) removed at jdk 16?

[Philip Race]

I think this is because of https://bugs.openjdk.java.net/browse/JDK-8256299

JDK 16   release notes here : http://jdk.java.net/16/release-notes

-phil

On 3/18/21 1:07 PM, Michael Hall wrote:

If I remember correctly this group ended up the keepers of this code. If that 
is not right please point me to the correct group.

I am getting…
Exception in thread "main" java.lang.IllegalAccessError: class 
us.hall.osx.OSXApplication (in unnamed module @0x2a5ca609) cannot access class 
com.apple.eio.FileManager (in module java.desktop) because module java.desktop does not 
export com.apple.eio to unnamed module @0x2a5ca609

Could you verify that this is intentional and not accidental?

Legacy Apple com.apple.eio.FileManager (in module java.desktop) removed at jdk 16?

[Michael Hall]

If I remember correctly this group ended up the keepers of this code. If that 
is not right please point me to the correct group.

I am getting…
Exception in thread "main" java.lang.IllegalAccessError: class 
us.hall.osx.OSXApplication (in unnamed module @0x2a5ca609) cannot access class 
com.apple.eio.FileManager (in module java.desktop) because module java.desktop 
does not export com.apple.eio to unnamed module @0x2a5ca609

Could you verify that this is intentional and not accidental?

Integrated: 8261352: Create implementation for component peer for all the components who should be ignored in a11y interactions

[Alexander Zuev]

On Mon, 15 Mar 2021 17:21:01 GMT, Alexander Zuev  wrote:

> Initial implementation
> Moved the CAccessibility ignore list initialization to the new code
> Some cleanup
> Expose a new API - isAccessibilityElement instead of deprecated 
> accessibilityIsIgnored

This pull request has now been integrated.

Changeset: e543a500
Author:Alexander Zuev 
URL:   https://git.openjdk.java.net/jdk/commit/e543a500
Stats: 140 lines in 5 files changed: 101 ins; 36 del; 3 mod

8261352: Create implementation for component peer for all the components who 
should be ignored in a11y interactions

Reviewed-by: serb

-

PR: https://git.openjdk.java.net/jdk/pull/3015

Integrated: 8263311: Watch registry changes for remote printers update instead of polling

[Alexey Ivanov]

On Wed, 10 Mar 2021 15:38:27 GMT, Alexey Ivanov  wrote:

> [JDK-8153732](https://bugs.openjdk.java.net/browse/JDK-8153732) implemented 
> polling for remote printers.
> That bug description also mentions watching the registry for changes and 
> links to the article which describes the method yet it does so in terms of 
> WMI. Using WMI is not necessary to watch for the registry updates.
> 
> It is possible to replace polling mechanism with registry change 
> notifications. If the registry at `HKCU\Printers\Connections` is updated, 
> refresh the list of print services.
> 
> It works perfectly well in my own testing with sharing a Generic / Text Only 
> printer from another laptop. The notification comes as soon as the printer is 
> installed, it results in a new key created under `Connections`. If a remote 
> printer is removed, the notification is also triggered as the key 
> corresponding to that printer is removed from the registry.
> 
> I updated the steps in the manual test: `RemotePrinterStatusRefresh.java`.

This pull request has now been integrated.

Changeset: a85dc557
Author:Alexey Ivanov 
URL:   https://git.openjdk.java.net/jdk/commit/a85dc557
Stats: 207 lines in 3 files changed: 31 ins; 158 del; 18 mod

8263311: Watch registry changes for remote printers update instead of polling

Reviewed-by: psadhukhan, serb

-

PR: https://git.openjdk.java.net/jdk/pull/2915

Re: RFR: 8262470: Printed GlyphVector outline with low DPI has bad quality on Windows [v2]

[Alexander Scherbatiy]

> Printing text using GlyphVector outline has bad quality on printers with low 
> DPI on Windows.
> The GDI system used for text printing on Windows accepts only integer path 
> coordinates.
> Rounding GlyphVector outline coordinates leads to distorted printed text.
> 
> The issue had been reported as JDK-8256264 but was reverted because of the 
> regression JDK-8259007 "This test printed a blank page".
> 
> The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo()  
> methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down.
> 
> The regression was in the WPathGraphics.deviceDrawLine() method which uses 
> wPrinterJob.moveTo()/lineTo() methods without surrounding them with 
> wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up.
> 
> I tried to put wPrinterJob.beginPath()/endPath()  methods around 
> wPrinterJob.moveTo()/lineTo()   in the method WPathGraphics.deviceDrawLine()  
> but the line was not drawn at all even without scaling coordinates up and 
> transform down (without JDK-8256264 fix). It looks like GDI treats this case 
> as an empty shape.
> 
> The proposed fix applies path coordinates and transform scaling only in 
> WPathGraphics.convertToWPath() method.
> The one more PathPrecisionScaleFactorShapeTest.java manual test is added 
> which checks that all methods that draw paths in WPathGraphics are used: line 
> in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in 
> WPathGraphics.convertToWPath() .
> 
> The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were 
> run on Windows 10 Pro with the fix.
> 
> There are two failed automated tests which fail without the fix as well:
> java/awt/print/PrinterJob/GlyphPositions.java 
> java/awt/print/PrinterJob/PSQuestionMark.java
> 
> The following manual tests have issues on my system:
> - `java/awt/print/Dialog/PrintDlgPageable.java` 
> java.lang.IllegalAccessException: class 
> com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member 
> of class PrintDlgPageable with modifiers "public static"
> 
> - `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages 
> radio button, press the print button but the test does not finish and I do 
> not see any other dialogs with pass/fail buttons.
> 
> - `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests 
> that there is no ClassCastException thrown in printing checkbox and scrollbar 
> with XAWT. Error. Can't find HTML file: 
> test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html
> 
> 
> - `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with 
> instructions is shown but it does not contain  print/pass/fail buttons and it 
> is not possible to close the window.
> 
> - The tests below fail with "Error. Parse Exception: Arguments to `manual' 
> option not supported: yesno" message:
> java/awt/print/Dialog/DialogOrient.java
> java/awt/print/Dialog/DialogType.java
> java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
> java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java
> java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java
> java/awt/print/PrinterJob/PageDialogTest.java
> java/awt/print/PrinterJob/PageRanges.java
> java/awt/print/PrinterJob/PageRangesDlgTest.java
> java/awt/print/PrinterJob/PrintGlyphVectorTest.java
> java/awt/print/PrinterJob/PrintLatinCJKTest.java
> java/awt/print/PrinterJob/PrintTextTest.java
> java/awt/print/PrinterJob/SwingUIText.java
> java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java
> java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java
> java/awt/PrintJob/SaveDialogTitleTest.java

Alexander Scherbatiy has updated the pull request incrementally with two 
additional commits since the last revision:

 - Use DASSERT to check SetGraphicsMode and WorldTransform results
 - Change setGraphicsMode() type to void

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2756/files
  - new: https://git.openjdk.java.net/jdk/pull/2756/files/e0278acd..8105885f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2756&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2756&range=00-01

  Stats: 21 lines in 2 files changed: 8 ins; 2 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2756.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2756/head:pull/2756

PR: https://git.openjdk.java.net/jdk/pull/2756

Re: RFR: 8262470: Printed GlyphVector outline with low DPI has bad quality on Windows [v2]

[Alexander Scherbatiy]

On Wed, 10 Mar 2021 09:31:32 GMT, Prasanta Sadhukhan  
wrote:

>> Alexander Scherbatiy has updated the pull request incrementally with two 
>> additional commits since the last revision:
>> 
>>  - Use DASSERT to check SetGraphicsMode and WorldTransform results
>>  - Change setGraphicsMode() type to void
>
> src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1025:
> 
>> 1023:  * {@code GM_COMPATIBLE} or {@code GM_ADVANCED}.
>> 1024:  */
>> 1025: private int setGraphicsMode(int mode) {
> 
> Is there any need of "int" return value? I dont see it is used in 
> restoreTransform()

I updated the code to return void from setGraphicsMode() method.

> src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 2033:
> 
>> 2031: xForm.eDy  = (FLOAT) elems[5];
>> 2032: 
>> 2033: ::SetWorldTransform((HDC)printDC, &xForm);
> 
> Probably we should check for the return value of all this system APIs 
> SetGraphicsMode, GetWorldTransform, SetWorldTransform, ModifyWorldTransform 
> to see if it succeeded?

I added DASSERT to check SetGraphicsMode and Get/Set/ModifyWorldTransform 
results.

-

PR: https://git.openjdk.java.net/jdk/pull/2756