Hello,
Could you please review the following fix for the bug.
Bug: https://bugs.openjdk.java.net/browse/JDK-8181192
Webrev: http://cr.openjdk.java.net/~alitvinov/8181192/jdk9/webrev.00
The bug is a showstopper bug consisting in hanging during the call to
"javafx.print.PrinterJob.showPrintDialo
y Bylokhov wrote:
The fix is fine but rather than deleting the test just mark it @ignore
.. it can be then updated
with a new version of the fix.
+1
-phil.
On 6/1/17, 11:19 AM, Anton Litvinov wrote:
Hello,
Could you please review the following fix for the bug.
Bug: https://bugs.openjdk.java.
Hello Prasanta and Phil,
Could you please review the following fix for the bug consisting in
creation of the alternative version of the fix for
(https://bugs.openjdk.java.net/browse/JDK-8167102). I am writing to you
directly, because you reviewed my first fix for this bug, which then
caused t
/JDK-8025990 which is why it is
used only on mac, so I think it is OK to assume it can be modified to
fix a further Mac bug. So this seems OK. -phil.
On 11/23/2017 08:54 AM, Anton Litvinov wrote:
Hello Prasanta and Phil,
Could you please review the following fix for the bug consisting in
Hello,
Could you please review the following fix for the bug.
Bug: https://bugs.openjdk.java.net/browse/JDK-8201818
Webrev: http://cr.openjdk.java.net/~alitvinov/8201818/jdk12/webrev.00
The bug consists in the fact that, if any one printing attribute is
contained in "PrintRequestAttributeSet"
102, whose fix was
backed out
Is this new bug a regression caused by the previous fix ?
Have you verified the previous fix is still functional ?
What tests have been run ?
Can you make sure this works in the cases of
a) no dialog
b) swing dialog
c) native dialog.
-phil.
On 8/17/18, 12:42 PM, Ant
should put the fix
in more generic place!!
Regards
Prasanta
On 8/23/2018 12:29 AM, Anton Litvinov wrote:
Hello Phil,
Thank you for review of this fix. It is correct, this code area was
already touched by 3 fixes which you specified, but they are just 2
attempts to fix the same issue and 1 r
Hello Phil,
Do you approve this version of the fix?
Thank you,
Anton
On 22/08/2018 19:59, Anton Litvinov wrote:
Hello Phil,
Thank you for review of this fix. It is correct, this code area was
already touched by 3 fixes which you specified, but they are just 2
attempts to fix the same issue
I am sorry for an additional e-mail. In the previous e-mail I forgot to
specify, that during the experiment not only JDK 11+28 was used, but
also JDK 8u181 b13 was used. The correction in the first sentence below
is marked with the bold font style.
On 23/08/2018 16:32, Anton Litvinov wrote
s
Prasanta
On 8/23/2018 9:49 PM, Anton Litvinov wrote:
I am sorry for an additional e-mail. In the previous e-mail I forgot
to specify, that during the experiment not only JDK 11+28 was used,
but also JDK 8u181 b13 was used. The correction in the first sentence
below is marked with the bold font s
Hello,
Could you please review the following fix which adds two blocks of
source code comments to two files.
Bug: https://bugs.openjdk.java.net/browse/JDK-8211165
Webrev: http://cr.openjdk.java.net/~alitvinov/8211165/jdk12/webrev.00
Thank you,
Anton
e now
and leave just "2015," sub-string.
Thank you,
Anton
On 26/09/2018 17:50, Phil Race wrote:
Looks good to me.
Not sure if including 2018 is strictly needed since the only change in
2018 is to add
the legal notice itself :-)
-phill
On 09/26/2018 09:40 AM, Anton Litvinov wrote
Hello,
Could you please review the following fix for the bug. The fix is
backing out of the fix for the bug JDK-8214579 which caused this JCK
test failure. If this fix is accepted, then a new separate bug for
readdressing the bug reported in JDK-8214579 will be filed.
Bug: https://bugs.openj
is the RDP
process ..
-phil.
On 7/10/19 5:00 AM, Anton Litvinov wrote:
Hello,
Could you please review the following fix for the bug. The fix is
backing out of the fix for the bug JDK-8214579 which caused this JCK
test failure. If this fix is accepted, then a new separate bug for
readdressing the
ong repo. You have to go clone 13 and apply the patch there
anyway ...
-phil.
On 7/11/19, 5:44 AM, Anton Litvinov wrote:
Hello Phil,
Thank you for review and the important remark about the need to work
with "jdk/jdk13" stabilization repository, I forgot about this
feature of post R
the test - after confirming that this backout resolves that as I
expect it will.
-phil.
On 7/11/19, 9:20 AM, Anton Litvinov wrote:
By your request regenerated the webrev specifically against
(http://hg.openjdk.java.net/jdk/jdk13) repository.
JDK 13 specific webrev:
http://cr.openjdk.java.net/~
ate the test to not exit
so quickly and grab a screen
shot of the failure and add it to the bug.
-phil.
On 7/11/19 11:13 AM, Anton Litvinov wrote:
Hello Phil,
Thank you for these additional details. I have tried to run the test
"open/test/jdk/java/awt/Color/AlphaColorTest.java"
/webrev.01
Thank you,
Anton
On 12/07/2019 19:42, Phil Race wrote:
> Would such a workaround be acceptable as part of this back out fix?
Yes, very much so !
-phil.
On 7/12/19 11:34 AM, Anton Litvinov wrote:
Hello Phil,
I tried to apply your code and can confirm that value of "c
On Fri, 14 May 2021 18:37:46 GMT, Anton Litvinov wrote:
> Hello,
>
> Could you please review the following fix for the bug specific to macOS. The
> bug consists in the fact that if the method
> "java.awt.print.Printable.print(Graphics, Page
On Wed, 19 May 2021 15:19:23 GMT, Phil Race wrote:
>> Hello,
>>
>> Could you please review the following fix for the bug specific to macOS. The
>> bug consists in the fact that if the method
>> "java.awt.print.Printable.print(Graphics, PageFormat, int)" throws
>> "java.awt.print.PrinterExcep
On Wed, 19 May 2021 15:22:27 GMT, Phil Race wrote:
>> Hello,
>>
>> Could you please review the following fix for the bug specific to macOS. The
>> bug consists in the fact that if the method
>> "java.awt.print.Printable.print(Graphics, PageFormat, int)" throws
>> "java.awt.print.PrinterExcep
On Wed, 19 May 2021 15:25:34 GMT, Phil Race wrote:
>> Hello,
>>
>> Could you please review the following fix for the bug specific to macOS. The
>> bug consists in the fact that if the method
>> "java.awt.print.Printable.print(Graphics, PageFormat, int)" throws
>> "java.awt.print.PrinterExcep
On Wed, 19 May 2021 21:40:49 GMT, Phil Race wrote:
>> Hello,
>>
>> Could you please review the following fix for the bug specific to macOS. The
>> bug consists in the fact that if the method
>> "java.awt.print.Printable.print(Graphics, PageFormat, int)" throws
>> "java.awt.print.PrinterExcep
On Wed, 19 May 2021 15:23:48 GMT, Phil Race wrote:
>> Anton Litvinov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Second version of the fix
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrint
the user on a non-EDT thread;
> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute
> "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is
> called on EDT thread.
>
> The regression test which is part of the fix was also
On Fri, 21 May 2021 20:16:41 GMT, Anton Litvinov wrote:
>> Hello,
>>
>> Could you please review the following fix for the bug specific to macOS. The
>> bug consists in the fact that if the method
>> "java.awt.print.Printable.print
On Sun, 30 May 2021 18:08:01 GMT, Phil Race wrote:
>> Anton Litvinov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Second version of the fix
>
> test/jdk/java/awt/print/PrinterJob/ExceptionFromPrintabl
On Sun, 30 May 2021 18:08:38 GMT, Phil Race wrote:
>> Anton Litvinov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Second version of the fix
>
> test/jdk/java/awt/print/PrinterJob/ExceptionFromPrintabl
On Sun, 30 May 2021 18:09:36 GMT, Phil Race wrote:
>> Anton Litvinov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Second version of the fix
>
> test/jdk/java/awt/print/PrinterJob/ExceptionFromPrintable
On Sun, 30 May 2021 18:11:18 GMT, Phil Race wrote:
>> Anton Litvinov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Second version of the fix
>
> test/jdk/java/awt/print/PrinterJob/ExceptionFromPrintable
the user on a non-EDT thread;
> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute
> "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is
> called on EDT thread.
>
> The regression test which is part of the fix was also su
the user on a non-EDT thread;
> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute
> "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is
> called on EDT thread.
>
> The regression test which is part of the fix was also
On Fri, 11 Jun 2021 17:06:24 GMT, Anton Litvinov wrote:
>> Hello,
>>
>> Could you please review the following fix for the bug specific to macOS. The
>> bug consists in the fact that if the method
>> "java.awt.print.Printable.print
On Fri, 11 Jun 2021 17:06:24 GMT, Anton Litvinov wrote:
>> Hello,
>>
>> Could you please review the following fix for the bug specific to macOS. The
>> bug consists in the fact that if the method
>> "java.awt.print.Printable.print
On Fri, 14 May 2021 18:37:46 GMT, Anton Litvinov wrote:
> Hello,
>
> Could you please review the following fix for the bug specific to macOS. The
> bug consists in the fact that if the method
> "java.awt.print.Printable.print(Graphics, Page
Hello,
Please review the following fix for a bug.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005607
https://jbs.oracle.com/bugs/browse/JDK-8005607
Webrev: http://cr.openjdk.java.net/~alitvinov/8005607/webrev.00
The bug consists in a crash which is caused by a stack overfl
ava code (see
XToolkit.SAVED_ERROR_HANDLER() and the surrounding logic). I believe
that we should somehow share this machinery with the 2D code to avoid
this sort of problems. Though I'm not sure if this will eliminate this
exact issue.
2D/AWT folks: any other thoughts?
--
best regard
andler logic is now located in Java code (see
XToolkit.SAVED_ERROR_HANDLER() and the surrounding logic). I believe
that we should somehow share this machinery with the 2D code to avoid
this sort of problems. Though I'm not sure if this will eliminate this
exact issue.
2D/AWT folks: any other
sic problem.
--
best regards,
Anthony
On 1/11/2013 14:44, Anton Litvinov wrote:
Hello Jim,
Thank you very much for the review and provision of a new idea of a
solution. Elimination of the logic, which sets/unsets
J2DXErrHandler() for each call "XShmAttach(awt_display, &shminfo))&qu
could also introduce a macro (such as the
old EXEC_WITH_XERROR_HANDLER but now with other arguments) that would
minimize all the JNU_ calls required to use this machinery.
Otherwise the fix looks great.
--
best regards,
Anthony
On 1/30/2013 20:14, Anton Litvinov wrote:
Hello Anthony,
Hello,
Please review the following fix for a bug.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
The bug consists in the fact that Java cross-platform Page Setup and
Print dialogs do not always list all media size
awt/awt_util.h" file.
Thank you,
Anton
On 1/31/2013 7:42 PM, Anton Litvinov wrote:
Hello Anthony,
Thank you for the review and these remarks. Surely, the comment will
be added. I think that all JNI code related to XShmAttach can be
definitely transferred into a separate dedicated func
Hello Anthony,
Thank you very much for approval of this fix.
Thank you,
Anton
On 2/15/2013 4:18 PM, Anthony Petrov wrote:
Hi Anton,
The fix looks great to me. Thanks for all your hard work!
--
best regards,
Anthony
On 2/13/2013 20:57, Anton Litvinov wrote:
Hello Anthony,
Could you
rror be private instead of package
protected?
2. XErrorHandlerUtil.getDisplay() seems to be redundant.
In general, the fix looks perfectly fine to me. Please, wait for
comments from Java2D team, though.
Thanks,
Artem
On 2/13/2013 8:57 PM, Anton Litvinov wrote:
Hello Anthony,
Could you please review the third ver
rev.03
Thank you,
Anton
On 2/18/2013 4:23 PM, Artem Ananiev wrote:
On 2/18/2013 4:04 PM, Anton Litvinov wrote:
Hello Artem,
Thank you very much for the review of this fix. My responses to your
questions are provided below in the same order, which you defined.
1. I think that "XErrorHandle
Hello,
I am sorry for inconvenience. This is a reminder message. I am still
interested in reception of the response to this review request and just
want to be sure that it is not lost on the mail alias's archive.
Thank you,
Anton
On 2/8/2013 8:09 PM, Anton Litvinov wrote:
Hello,
P
/bugdatabase/view_bug.do?bug_id=8005607
Webrev: http://cr.openjdk.java.net/~alitvinov/8005607/webrev.03
Thank you,
Anton
On 2/20/2013 5:43 PM, Artem Ananiev wrote:
Looks fine.
Thanks,
Artem
On 2/18/2013 8:08 PM, Anton Litvinov wrote:
Hello Artem,
Could you please review a new version of the
://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
Thank you,
Anton
On 2/21/2013 6:53 PM, Anton Litvinov wrote:
Hello,
I am sorry for inconvenience. This is a reminder message. I am still
interested in reception of the response to this review request and
just want to be sure that it is not lost on the
nton
On 2/20/2013 5:43 PM, Artem Ananiev wrote:
Looks fine.
Thanks,
Artem
On 2/18/2013 8:08 PM, Anton Litvinov wrote:
Hello Artem,
Could you please review a new version of the fix. The method
"XErrorHandlerUtil.getDisplay()" was removed and
"XErrorHandlerUtil.XSync()&q
s' even if we already have the
lock on this thread and its
a Reentrant lock but it does increase the risk of deadlock, plus its
got JNI up-call overhead ..
but we seem to have a ton of that anyway.
-phil.
On 3/26/2013 5:40 AM, Anton Litvinov wrote:
Hello,
Please review the following fix f
oever this fix
still will not allow "Postcard (100 x 148 mm)" to be displayed.
Thank you,
Anton
On 3/29/2013 11:26 PM, Jennifer Godinez wrote:
Hi Anton,
What printer and printer driver version did you use to test your fix?
Thanks.
Jennifer
On 3/11/2013 1:41 AM, Anton Litvinov wrote:
M, Jennifer Godinez wrote:
Thanks Anton. I will test your fix and let you know.
Jennifer
On 4/17/2013 5:53 AM, Anton Litvinov wrote:
Hello Jennifer,
Thank you very much for the review of this fix. For reproduction of
this bug and testing of the fix the printer "PrimoPDF" with its
drive
edger,
Tabloid, Ledger Borderless, and Ledger Borderless/ShortGrain. I think
our use of Tabloid is still not right. I'm leaning towards either
changing all the names but this is up for discussion.
Jennifer
On 4/19/2013 9:23 AM, Anton Litvinov wrote:
Hello Jennifer,
I am sorr
mment
the line:
120 // return
XlibWrapper.CallErrorHandler(saved_error_handler, display, error.pData);
for debugging purposes w/o having to wire up all the
saved_error_handler machinery anew. This is needed rarely but may be
useful in some cases.
I'd prefer to leave it as is.
Hello,
Could you please review the following fix for the bug.
Bug: https://bugs.openjdk.java.net/browse/JDK-8167102
Webrev: http://cr.openjdk.java.net/~alitvinov/8167102/jdk9/webrev.00
The bug consists in the fact that, if the user's application specifies
the required page size (media size) th
le() with that
"adjusted" pageformat. If user pass 0,0,fullpaperwidth,fullpaperheight
as imageablearea, then he should not expect this setting to be used
since printer will have its own hardware limitation (and use some
offset printing)
BTW, a regression testcase (even if it is manual) sho
c also, we need to do away with
getPageFormatFromAttributes() call and call getPageFormat(pageIndex)
from CPrinterJob.m#javaPrinterJobToNSPrintInfo().
Regards
Prasanta
On 3/21/2017 8:15 PM, Anton Litvinov wrote:
Hello Prasanta,
Thank you for review of this fix. I have tried to ap
ase, I see it
is called from CPrinterJob.java#printAndGetPageFormatArea()
which is called from PrinterView.m#rectForPage. And before calling
printAndGetPageFormatArea() it calls
getPageformatPrintablePeekgraphics() which calls
pageable.getPageFormat(pageIndex), so it should behave same as
windows. Am I missing so
to address it separately from this bug (JDK-8167102). Would you agree
with this suggestion? Would you approve the second version of the fix
for the bug JDK-8167102?
Thank you,
Anton
On 3/28/2017 12:46 PM, Prasanta Sadhukhan wrote:
Hi Anton,
On 3/27/2017 10:05 PM, Anton Litvinov wrote:
He
:23 PM, Prasanta Sadhukhan wrote:
On 3/28/2017 6:25 PM, Anton Litvinov wrote:
Hello Prasanta,
The correct "PageFormat" for each separate page is retrieved in the
native function "PrinterView.m::rectForPage:(NSInteger)" by invoking
the Java method "CPrinterJob.getPagefo
p supplies an attribute set that *does* have one or
more attributes that affect PageFormat. It might well be that
these are applied already but I'd like assurance that has been verified.
Some of the code references below seem to be a bit munged by mail
so I can't work out what is
61 matches
Mail list logo
