On Mon, 28 Mar 2022 15:16:52 GMT, Phil Race wrote:
>> ExceptionClear(env) is removed from the `if (nameArray == NULL)` check.
>
> I should have said (as I did in the beginning) remove the clear - and the new
> throw - and just return null.
JNU_ThrowOutOfMemoryError is removed from code where na
cupsServer() function and not changing the interface string to
>> "localhost".
>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>> network-client access with print access. They don't seem interested in
>> loosening that change.
On Fri, 25 Mar 2022 17:31:37 GMT, Phil Race wrote:
>> The array creation error handling is implemented in the similar way as it is
>> done in the getMedia() function.
>> The ExceptionClear() has been added to the getMedia() by `8031001: [Parfait]
>> warnings from b121 for jdk/src/solaris/native
cupsServer() function and not changing the interface string to
>> "localhost".
>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>> network-client access with print access. They don't seem interested in
>> loosening that change.
On Tue, 24 Aug 2021 16:06:40 GMT, Alexander Scherbatiy
wrote:
>> src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 489:
>>
>>> 487: return domainSocketPathname;
>>> 488: }
>>> 489:
>>
>> You will need to s
cupsServer() function and not changing the interface string to
>> "localhost".
>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>> network-client access with print access. They don't seem interested in
>> loosening that change.
cupsServer() function and not changing the interface string to
>> "localhost".
>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>> network-client access with print access. They don't seem interested in
>> loosening that change.
>
On Tue, 24 Aug 2021 15:49:00 GMT, Alexander Scherbatiy
wrote:
>> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
>>
>> Create a native macOS app from the Hello.java file, sign and run it in
>> sandbox:
>>
>> import javax.print.*;
&g
On Tue, 24 Aug 2021 15:49:00 GMT, Alexander Scherbatiy
wrote:
>> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
>>
>> Create a native macOS app from the Hello.java file, sign and run it in
>> sandbox:
>>
>> import javax.print.*;
&g
On Tue, 24 Aug 2021 15:49:00 GMT, Alexander Scherbatiy
wrote:
>> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
>>
>> Create a native macOS app from the Hello.java file, sign and run it in
>> sandbox:
>>
>> import javax.print.*;
&g
On Wed, 15 Sep 2021 05:52:54 GMT, Alexander Scherbatiy
wrote:
> FontManagerFactory class uses reflection to load platform specific
> FontManager classes from "sun.font.fontmanager" property.
>
> Fix proposes creating FontManager platform specific classes directly in th
tManager from subclassing and using by a
> user.
>
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific
> classes. May be FontManager creation code needs to be placed in its own info
> classes.
Alexander Scherbatiy has updated the pull request incrementa
On Mon, 20 Sep 2021 17:56:25 GMT, Alexey Ivanov wrote:
> Should `PlatformFontInfo` classes be marked `final`? They're not supposed to
> be subclassed.
The final keyword is added to the `PlatformFontInfo` clases.
-
PR: https://git.openjdk.java.net/jdk/pull/5517
On Sat, 18 Sep 2021 23:08:21 GMT, Sergey Bylokhov wrote:
>> The method `FontManagerFactory.getInstance()` is updated to use DLC.
>>
>> I used synchronization on FontManagerFactory.class in the first check to be
>> consistent with the previous behavior where synchronization was on the
>> `FontM
On Sat, 18 Sep 2021 22:51:34 GMT, Sergey Bylokhov wrote:
>> Alexander Scherbatiy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Change Solaris default implementation to Mac OS in FontManagerFactory
>>
tManager from subclassing and using by a
> user.
>
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific
> classes. May be FontManager creation code needs to be placed in its own info
> classes.
Alexander Scherbatiy has updated the pull request incremental
On Fri, 17 Sep 2021 12:37:34 GMT, Prasanta Sadhukhan
wrote:
>> Alexander Scherbatiy has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Remove obsolete imports from FontManagerFactory
>> -
tManager from subclassing and using by a
> user.
>
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific
> classes. May be FontManager creation code needs to be placed in its own info
> classes.
Alexander Scherbatiy has updated the pull request incrementa
On Fri, 17 Sep 2021 07:57:46 GMT, Sergey Bylokhov wrote:
>> Alexander Scherbatiy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move createFontManager() code to sun.font.PlatformFontInfo class
>
> src/
On Fri, 17 Sep 2021 07:57:06 GMT, Sergey Bylokhov wrote:
>> Alexander Scherbatiy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move createFontManager() code to sun.font.PlatformFontInfo class
>
> src/
tManager from subclassing and using by a
> user.
>
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific
> classes. May be FontManager creation code needs to be placed in its own info
> classes.
Alexander Scherbatiy has updated the pull request incrementall
On Thu, 16 Sep 2021 13:38:37 GMT, Alexander Scherbatiy
wrote:
>> FontManagerFactory class uses reflection to load platform specific
>> FontManager classes from "sun.font.fontmanager" property.
>>
>> Fix proposes creating FontManager platform specific classes
tManager from subclassing and using by a
> user.
>
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific
> classes. May be FontManager creation code needs to be placed in its own info
> classes.
Alexander Scherbatiy has updated the pull request incrementa
Hello,
LazyPainter class from Defaults.template uses reflection to create a
Painter classes [1].
There are some fixes which replace LazyValue with lambdas [2], [3]:
8039750: KSS: Replace MetalLazyValue with lambda
8035313: Change SwingLazyValue usage to lambda
Would it be useful to get ri
tManager from subclassing and using by a
> user.
>
> The fix reuses PlatformGraphicsInfo to create FontManager platform specific
> classes. May be FontManager creation code needs to be placed in its own info
> classes.
Alexander Scherbatiy has updated the pull request incrementa
On Wed, 15 Sep 2021 06:12:32 GMT, Prasanta Sadhukhan
wrote:
>> Alexander Scherbatiy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typo in sun.font.fontmanager property name. Load AWT lib in test
&
FontManagerFactory class uses reflection to load platform specific FontManager
classes from "sun.font.fontmanager" property.
Fix proposes creating FontManager platform specific classes directly in the
similar way as it has been already done for GraphicsEnvironment and AWT Toolkit
([JDK-8130266]
Hello,
There are two fixes which avoid using reflection during
GraphicsEnvironment and Toolkit platform specific classes loading [1], [2]:
8130266 Change the mechanism by which JDK loads the platform-specific
GraphicsEnvironment class
8212700 Change the mechanism by which JDK loads the plat
28 matches
Mail list logo
