On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov wrote:
> This is a review request for the bug particularly fixed some time ago:
> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
>
> In that review request it was found that the old fix does not work well in
> all cases,
On Wed, 17 Feb 2021 18:50:11 GMT, Phil Race wrote:
> That should be irrelevant. jtreg should only be invoking tests which do NOT
> have the printer keyword since the test job has this : keywords=headful &
> !printer which are handed directly to jtreg. In other words it is not
> filtering on
On Wed, 17 Feb 2021 18:50:11 GMT, Phil Race wrote:
>> Maybe @key printer is not being taken seriously during system setup which is
>> why no real printer is being used.
>
>> Maybe @key printer is not being taken seriously during system setup which is
>> why no real printer is being used.
>
>
On Wed, 17 Feb 2021 18:07:27 GMT, Prasanta Sadhukhan
wrote:
> Maybe @key printer is not being taken seriously during system setup which is
> why no real printer is being used.
That should be irrelevant. jtreg should only be invoking tests which do NOT
have the printer keyword since the test
On Wed, 17 Feb 2021 18:02:49 GMT, Phil Race wrote:
>> This test was timing out in windows in mach5 nightly testing. Investigation
>> reveals that 70% of the time, it is failing due to printer being chosen was
>> Microsoft Print to PDF which opens up a File Save Dialog when "OK" was
>> clicked
On Wed, 17 Feb 2021 18:05:41 GMT, Prasanta Sadhukhan
wrote:
>> The problem I have with this is that it does not scale.
>> It is a maintenance nightmare every possible "file printer" on Windows to
>> every test.
>> and back porting it too ?
>> removing or disabling one note and the rest s
On Wed, 17 Feb 2021 03:21:03 GMT, Prasanta Sadhukhan
wrote:
> This test was timing out in windows in mach5 nightly testing. Investigation
> reveals that 70% of the time, it is failing due to printer being chosen was
> Microsoft Print to PDF which opens up a File Save Dialog when "OK" was
>
On Wed, 17 Feb 2021 17:34:22 GMT, Alexander Zuev wrote:
>> This test was timing out in windows in mach5 nightly testing. Investigation
>> reveals that 70% of the time, it is failing due to printer being chosen was
>> Microsoft Print to PDF which opens up a File Save Dialog when "OK" was
>>
On Wed, 17 Feb 2021 03:21:03 GMT, Prasanta Sadhukhan
wrote:
> This test was timing out in windows in mach5 nightly testing. Investigation
> reveals that 70% of the time, it is failing due to printer being chosen was
> Microsoft Print to PDF which opens up a File Save Dialog when "OK" was
>
On Wed, 17 Feb 2021 15:55:04 GMT, Alexey Ivanov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> javadoc change
>
> Marked as reviewed by aivanov (Reviewer).
Thanks @aivanov-jdk . Would you mind adding
On Wed, 17 Feb 2021 15:54:22 GMT, Prasanta Sadhukhan
wrote:
>> The API doc for Graphics2D.clip(shape s) claims that passing a null argument
>> would actually clear the existing clipping area, which is incorrect.
>> This statement is applicable only to G2D.setClip() and not for the clip()
>>
On Tue, 16 Feb 2021 06:24:05 GMT, Vladimir Kempik wrote:
>> This is when passing a float, yes? In the case where we have more float
>> arguments than n_float_register_parameters_c.
>> I don't understand why you think it's acceptable to bail in this case. Can
>> you explain, please?
>
> it's
On Mon, 15 Feb 2021 17:45:32 GMT, Anton Kozlov wrote:
>> I'm not sure it can wait. This change turns already-messy code into
>> something significantly messier, to the extent that it's not really good
>> enough to go into mainline.
>
> The latest merge with JDK-8261071 should resolve the
On Wed, 17 Feb 2021 15:48:12 GMT, Prasanta Sadhukhan
wrote:
>> The API doc for Graphics2D.clip(shape s) claims that passing a null argument
>> would actually clear the existing clipping area, which is incorrect.
>> This statement is applicable only to G2D.setClip() and not for the clip()
>>
> The API doc for Graphics2D.clip(shape s) claims that passing a null argument
> would actually clear the existing clipping area, which is incorrect.
> This statement is applicable only to G2D.setClip() and not for the clip()
> method. G2D.clip() would throw a NullPointerException when it
On Wed, 17 Feb 2021 15:38:10 GMT, Prasanta Sadhukhan
wrote:
>> The API doc for Graphics2D.clip(shape s) claims that passing a null argument
>> would actually clear the existing clipping area, which is incorrect.
>> This statement is applicable only to G2D.setClip() and not for the clip()
>>
> The API doc for Graphics2D.clip(shape s) claims that passing a null argument
> would actually clear the existing clipping area, which is incorrect.
> This statement is applicable only to G2D.setClip() and not for the clip()
> method. G2D.clip() would throw a NullPointerException when it
On Wed, 17 Feb 2021 15:25:35 GMT, Alexey Ivanov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> javadoc change
>
> src/java.desktop/share/classes/java/awt/Graphics2D.java line 1206:
>
>> 1204: * with
> The API doc for Graphics2D.clip(shape s) claims that passing a null argument
> would actually clear the existing clipping area, which is incorrect.
> This statement is applicable only to G2D.setClip() and not for the clip()
> method. G2D.clip() would throw a NullPointerException when it
On Wed, 17 Feb 2021 15:08:58 GMT, Prasanta Sadhukhan
wrote:
>> The API doc for Graphics2D.clip(shape s) claims that passing a null argument
>> would actually clear the existing clipping area, which is incorrect.
>> This statement is applicable only to G2D.setClip() and not for the clip()
>>
On Wed, 17 Feb 2021 14:20:47 GMT, Alexey Ivanov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> javdoc tag for NPE
>
> src/java.desktop/share/classes/java/awt/Graphics2D.java line 1205:
>
>> 1203: *
> The API doc for Graphics2D.clip(shape s) claims that passing a null argument
> would actually clear the existing clipping area, which is incorrect.
> This statement is applicable only to G2D.setClip() and not for the clip()
> method. G2D.clip() would throw a NullPointerException when it
On Mon, 15 Feb 2021 12:48:01 GMT, Prasanta Sadhukhan
wrote:
>> The API doc for Graphics2D.clip(shape s) claims that passing a null argument
>> would actually clear the existing clipping area, which is incorrect.
>> This statement is applicable only to G2D.setClip() and not for the clip()
>>
On Tue, 2 Feb 2021 22:42:22 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/share/logging/logStream.hpp line 35:
>
>> 33: class LogStream :
On Mon, 15 Feb 2021 16:21:53 GMT, Bernhard Urban-Forster
wrote:
>> This is the version of w^x on-demand switch implemented by microsoft guys.
>> This is enabled only for debug builds.
>> @lewurm could you comment here please
>
> Those values can be observed in the debugger, but aren't
On Tue, 2 Feb 2021 21:51:56 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 31:
>
>> 29:
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks
> JDK-8253817, JDK-8253818)
27 matches
Mail list logo
