Re: [OpenJDK 2D-Dev] RFR: 8130264 : change the mechanism by which JDK loads the platform-specific PrinterJob implementation
Can someone review the CSR : https://bugs.openjdk.java.net/browse/JDK-8214322 ? Also my email below pointed to the webrev twice .. the bug id for this issue is here : https://bugs.openjdk.java.net/browse/JDK-8130264 -phil. On 11/16/18 1:36 PM, Sergey Bylokhov wrote: Looks fine. On 15/11/2018 13:41, Phil Race wrote: bug: http://cr.openjdk.java.net/~prr/8130264/ webrev: http://cr.openjdk.java.net/~prr/8130264/ Currently java launcher code embeds the name of the java.desktop module's PrinterJob implementation class for each platform in a system property which is later read by the java.desktop code to use to reflectively locate the class and instantiate it. This fix removes that entirely from the launcher code and the desktop module now looks it up internally via a simple platform proxy class. This builds on all platforms and we rely on existing printing tests to verify that we can still locate the implementation class. The new regression test just verifies the system property name space is no longer polluted. I didn't find any test (apart from this new one) that references it. Since that system property has been around for a long time I am thinking I should file a CSR to document its removal .. unless there is a concensus it is not necessary. -phil.
Re: [OpenJDK 2D-Dev] RFR: 8130264 : change the mechanism by which JDK loads the platform-specific PrinterJob implementation
Looks fine. On 15/11/2018 13:41, Phil Race wrote: bug: http://cr.openjdk.java.net/~prr/8130264/ webrev: http://cr.openjdk.java.net/~prr/8130264/ Currently java launcher code embeds the name of the java.desktop module's PrinterJob implementation class for each platform in a system property which is later read by the java.desktop code to use to reflectively locate the class and instantiate it. This fix removes that entirely from the launcher code and the desktop module now looks it up internally via a simple platform proxy class. This builds on all platforms and we rely on existing printing tests to verify that we can still locate the implementation class. The new regression test just verifies the system property name space is no longer polluted. I didn't find any test (apart from this new one) that references it. Since that system property has been around for a long time I am thinking I should file a CSR to document its removal .. unless there is a concensus it is not necessary. -phil. -- Best regards, Sergey.
Re: [OpenJDK 2D-Dev] RFR: 8130264 : change the mechanism by which JDK loads the platform-specific PrinterJob implementation
Hi Phil, Looks fine from the core-libs perspective. Thanks, thanks for removing this cross module dependency. Roger On 11/15/2018 04:41 PM, Phil Race wrote: bug: http://cr.openjdk.java.net/~prr/8130264/ webrev: http://cr.openjdk.java.net/~prr/8130264/ Currently java launcher code embeds the name of the java.desktop module's PrinterJob implementation class for each platform in a system property which is later read by the java.desktop code to use to reflectively locate the class and instantiate it. This fix removes that entirely from the launcher code and the desktop module now looks it up internally via a simple platform proxy class. This builds on all platforms and we rely on existing printing tests to verify that we can still locate the implementation class. The new regression test just verifies the system property name space is no longer polluted. I didn't find any test (apart from this new one) that references it. Since that system property has been around for a long time I am thinking I should file a CSR to document its removal .. unless there is a concensus it is not necessary. -phil.
[OpenJDK 2D-Dev] RFR: 8130264 : change the mechanism by which JDK loads the platform-specific PrinterJob implementation
bug: http://cr.openjdk.java.net/~prr/8130264/ webrev: http://cr.openjdk.java.net/~prr/8130264/ Currently java launcher code embeds the name of the java.desktop module's PrinterJob implementation class for each platform in a system property which is later read by the java.desktop code to use to reflectively locate the class and instantiate it. This fix removes that entirely from the launcher code and the desktop module now looks it up internally via a simple platform proxy class. This builds on all platforms and we rely on existing printing tests to verify that we can still locate the implementation class. The new regression test just verifies the system property name space is no longer polluted. I didn't find any test (apart from this new one) that references it. Since that system property has been around for a long time I am thinking I should file a CSR to document its removal .. unless there is a concensus it is not necessary. -phil.
