Hi!
Thank you Anton!
The updated webrev is:
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/7081580/webrev.01/
--Semyon
On 3/12/2015 1:42 PM, Anton V. Tarasov wrote:
Hi Semyon, Sergey,
I agree with that the modified javadoc is not good.
1. When you say something is done by calling
specification) and returns. See for example
Toolkit.getToolkit and Toolkit. areExtraMouseButtonsEnabled(). It is
not necessary write so specific specification but at least it should
be clear.
It would be good to rephrase it somehow.
12.03.15 0:09, Semyon Sadetsky wrote:
Hi Sergey,
I didn't find any
Hi Sergey,
Thank you for your response.
I have added max+-1 cases to the test.
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/8072769/webrev.05/
cases 0,1, etc are not related to the bug. I understand you worries
about test coverage but I think it's better to follow the process.
You can
. Probably we can simplify it and state
that we use numeric value from desktop property or something like that?
11.03.15 22:52, Semyon Sadetsky wrote:
Hello,
please review fix for jdk9.
Webrev:
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/7081580/webrev.00/
Bug: https://bugs.openjdk.java.net
Hello,
please review fix for jdk9.
Webrev:
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/7081580/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-7081580
Thanks,
--Semyon
Hi Anton,
the code was changed according to our offline discussion:
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/6980209/webrev.01/
added a test case for deterministic scenario
bug root cause description extended
--Semyon
On 3/27/2015 5:32 PM, Anton V. Tarasov wrote:
Hi Semyon
from an event pump or
sleep.
Also, please put a space b/w if and brace at the line 177.
Thanks,
Anton.
On 30.03.2015 16:07, Semyon Sadetsky wrote:
Hi Anton,
the code was changed according to our offline discussion:
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/6980209/webrev.01/
added
accepted.
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/8072769/webrev.03/
On 3/3/2015 1:16 PM, Alexander Scherbatiy wrote:
Just few comments about the test:
- The test sets WindowsLookAndFeel and seems fails on non Windows
platforms.
- There is the second SystemTray.isSupported
Hello,
the next JBS issue were closed as not an issue:
https://bugs.openjdk.java.net/browse/JDK-8073454
https://bugs.openjdk.java.net/browse/JDK-8065359
https://bugs.openjdk.java.net/browse/JDK-8055750
https://bugs.openjdk.java.net/browse/JDK-8050248
Hello,
Test was added. Please review.
webrev:
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/8072769/webrev.02/
bug: https://bugs.openjdk.java.net/browse/JDK-8072769
On 2/26/2015 10:46 AM, Semyon Sadetsky wrote:
fix updated:
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/8072769
tray.remove(trayIcon); at the end of the test, otherwise
it can hang, when will be run w/o jtreg.
On 03.03.2015 15:32, Semyon Sadetsky wrote:
accepted.
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/8072769/webrev.03/
On 3/3/2015 1:16 PM, Alexander Scherbatiy wrote:
Just few comments about
15:08, Semyon Sadetsky wrote:
I think it's more like bug regression test policy. Since I'm a novice
in the project maybe you or somebody can advise me the right process.
Lets see what we have here:
The fix is connected to the windows platform native code only. It is
a platform specific corner case
the updated webrev:
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/8072769/webrev.04/
On 3/4/2015 4:33 PM, Semyon Sadetsky wrote:
Sergey,
OK. You can file a request to improve TrayIcon test coverage but it's
an another story. Here we are discussing regression test for a
specific bug.
I
Hello,
AWT Dev [9] review request for 8061636: Fix for JDK-7079254 changes
behavior of MouseListener, MouseMotionListener
please review the fix
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/8072769/webrev/
http://cr.openjdk.java.net/%7Eazvegint/jdk/9/8061636/00
for the issue
https
fix updated:
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/8072769/webrev.01/
On 2/24/2015 12:12 PM, Semyon Sadetsky wrote:
Hello,
AWT Dev [9] review request for 8061636: Fix for JDK-7079254 changes
behavior of MouseListener, MouseMotionListener
please review the fix:
http
Hello,
Please review fix for JDK9.
Bug: https://bugs.openjdk.java.net/browse/JDK-6980209#comment-13623256
Webrev:
http://cr.openjdk.java.net/~alexsch/semyon-sadetsky/6980209/webrev.00/
***The root cause:
There are 2 issues in WaitDispatchSupport:
1. If exit() is called before the secondary
Hello,
Please review fix for JDK9.
webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8003399
***THE ROOT CAUSE
JDK uses legacy WINAPI special folders calls while MS introduced a new
interfaces IKnownFolder and IShellLibrary to manage
you please raise the supportness of this in the java.io on the
core-libs alias.
Does the open filedialog will work after the fix?
On 07.05.15 11:14, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9.
webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/
bug: https
On 5/8/2015 3:45 PM, Sergey Bylokhov wrote:
On 07.05.15 15:29, Semyon Sadetsky wrote:
Hi Sergey,
Yes, after the fix filedialog produces usual filesystem paths for
libraries which are readable for java.io.
Just to clarify: after the fix, both Open and Save dialog works?
Open file in library
Hello,
Please review fix for JDK9.
webrev: http://cr.openjdk.java.net/~ssadetsky/7155957/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-7155957
*THE ROOT CAUSE
A number of concurrency bugs in AWT Toolkit.
When menus are modified concurrently there is a big chance that the
internal
Hello,
Please review fix for JDK9.
webrev: http://cr.openjdk.java.net/~ssadetsky/7042645/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-7042645
*ROOT CAUSE:
The assertion fails message triggered in awt_Button.cpp because a WinAPI
function used to draw button focus rectangle returns
before push?
Thanks,
Alexander.
On 04/06/2015 03:11 PM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9.
webrev: http://cr.openjdk.java.net/~ssadetsky/7042645/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-7042645
*ROOT CAUSE:
The assertion fails message triggered
, guid, Ljava/lang/String;);
+DASSERT(field_guid != NULL);
+CHECK_NULL_RETURN(field_guid, NULL);
To call it like:
DEFINE_FIELD_ID(field_guid, cl, guid, Ljava/lang/String;);
You would reduce the code a lot and make it more readable.
Regards,
Anton.
On 19.05.2015 18:45, Semyon Sadetsky wrote
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8085895
webrev: http://cr.openjdk.java.net/~ssadetsky/8085895/webrev.00/
In 8074028 overridden getPeer() was simply removed in XWindows peers of
TextField and TextArea but that was not enough to preserve the
Hi Sergey,
as I promised I add the updated Library check:
http://cr.openjdk.java.net/~ssadetsky/8022057/webrev.01/
--Semyon
On 6/2/2015 5:57 PM, Semyon Sadetsky wrote:
Hi Sergey,
I will update this library detection when the preceding fix (about
columns) is approved.
--Semyon
On 6/2
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8085948
webrev: http://cr.openjdk.java.net/~ssadetsky/8085948/webrev.00/
It is a regression of JDK-8035302. The charset name is requested from a
dummy stream reader. But it requires creating of the charset decoder
Hello,
Please review fix for JDK9-JIGSAW:
bug: https://bugs.openjdk.java.net/browse/JDK-8051636
webrev: http://cr.openjdk.java.net/~ssadetsky/8051636/webrev.00/
I have found only one run-time dependency on java.rmi module in
sun.datatransfer.DataFlavorUtil.RMI class.
Now it checks module
locales?
On 26.05.15 8:09, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8017487
webrev: http://cr.openjdk.java.net/~ssadetsky/8017487/webrev.00/
File details view columns obtained by the legacy special folder API for
the virtual Windows
recommendations can eliminate delays +
I added Windows libraries icons.
--Semyon
On 6/1/2015 5:41 PM, Anton V. Tarasov wrote:
Hi Semyon,
The idea of the fix looks ok to me.
On 28.05.2015 9:44, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8022057
webrev: http://cr.openjdk.java.net/~ssadetsky/8022057/webrev.00/
The full story can be found in the jira's comments and NetBeans tracker
(https://netbeans.org/bugzilla/show_bug.cgi?id=188001).
It seems
Semyon,
The idea of the fix looks ok to me.
On 28.05.2015 9:44, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8022057
webrev: http://cr.openjdk.java.net/~ssadetsky/8022057/webrev.00/
The full story can be found in the jira's comments
Hi Pete,
I heard that you got performance issue in b68 connected to text components.
It can be caused by https://bugs.openjdk.java.net/browse/JDK-8098835.
The next patch can help:
---
old/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java
2015-06-16 20:20:42.678311800
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8130242
webrev: http://cr.openjdk.java.net/~ssadetsky/8130242/webrev.00/
Data transfer's flavor comparator violates transitivity.
--Semyon
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8017487
webrev: http://cr.openjdk.java.net/~ssadetsky/8017487/webrev.00/
File details view columns obtained by the legacy special folder API for
the virtual Windows libraries are not consistent with child files
spaces in if(
On 21.05.15 18:15, Anton Tarasov wrote:
So, it looks fine to me now. Thanks.
Anton.
On 20/05/15 17:12, Semyon Sadetsky wrote:
Hi Anton,
http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.02/
I have added the macro you requested.
--Semyon
On 5/20/2015 3:34 PM, Anton V. Tarasov
Hi Anton,
here is an updated version:
http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.01/
--Semyon
On 5/8/2015 5:01 PM, Semyon Sadetsky wrote:
On 5/8/2015 3:45 PM, Sergey Bylokhov wrote:
On 07.05.15 15:29, Semyon Sadetsky wrote:
Hi Sergey,
Yes, after the fix filedialog produces
:
java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=java.lang.String]
X Y Z but X Z
--Semyon
On 7/6/2015 5:21 PM, Alexander Scherbatiy wrote:
On 7/6/2015 2:17 PM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8132664
webrev: http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.00/
DoDragDrop() is blocking, so upon drag operation is triggered the
toolkit thread is blocked and the WM_AWT_WAIT cannot be processed which
that some of the peers
has utility methods for this(like XDecoratedPeer.handleMoved).
On 31.07.15 11:52, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8011616
webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/
WM sends
.
On 31.07.15 16:07, Semyon Sadetsky wrote:
Is it possible to reproduce the scenario using simple native
application which embeds the Java VM?
On 7/31/2015 3:37 PM, Sergey Bylokhov wrote:
On 31.07.15 10:30, Semyon Sadetsky wrote:
JMC-4034 is not an OpenJDK project. Souldn't this test be copied
Is it possible to reproduce the scenario using simple native application
which embeds the Java VM?
On 7/31/2015 3:37 PM, Sergey Bylokhov wrote:
On 31.07.15 10:30, Semyon Sadetsky wrote:
JMC-4034 is not an OpenJDK project. Souldn't this test be copied to
the client-libs test base?
JDK-8132469
the private logging to the test(it was removed
recently)? Why Logger cannot be used? I suggest to set
setAutoDelay+setAutoWaitForIdle in the main method also.
On 17.07.15 16:37, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8131670
webrev
to fix the issue because 10 seconds is too big
interval. But for consistency it is not bad to have a time limit.
http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.01/
On 03.08.15 17:26, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK
On 8/3/2015 4:41 PM, Sergey Bylokhov wrote:
On 31.07.15 21:34, Semyon Sadetsky wrote:
On 7/31/2015 6:28 PM, Sergey Bylokhov wrote:
On 31.07.15 18:12, Semyon Sadetsky wrote:
On 7/31/2015 5:55 PM, Sergey Bylokhov wrote:
On 31.07.15 17:29, Semyon Sadetsky wrote:
So the test could use one
On 7/31/2015 5:55 PM, Sergey Bylokhov wrote:
On 31.07.15 17:29, Semyon Sadetsky wrote:
So the test could use one of these java resources inside the native
app without any external libraries only using JNI library, right?
Since we do not place a binary files to the ws, It will require
methods for this(like XDecoratedPeer.handleMoved).
On 31.07.15 11:52, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8011616
webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/
WM sends the real window position
So the test could use one of these java resources inside the native app
without any external libraries only using JNI library, right?
On 7/31/2015 5:18 PM, Sergey Bylokhov wrote:
On 31.07.15 16:51, Semyon Sadetsky wrote:
There are plenty classes extending CFRetainedResource, TryIcon
On 7/31/2015 6:28 PM, Sergey Bylokhov wrote:
On 31.07.15 18:12, Semyon Sadetsky wrote:
On 7/31/2015 5:55 PM, Sergey Bylokhov wrote:
On 31.07.15 17:29, Semyon Sadetsky wrote:
So the test could use one of these java resources inside the native
app without any external libraries only using
( jmc_plugintest/swt
case) and JDK-8132469(swingnode/fx case).
On 30.07.15 9:49, Semyon Sadetsky wrote:
Hi Sergey,
You've marked the bug as noreg-sqe. I could not find the existing
test that crashes during the bug scenario. Could add this info?
--Semyon
On 7/29/2015 6:51 PM, Sergey Bylokhov
, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8041519
webrev: http://cr.openjdk.java.net/~ssadetsky/8041519/webrev.00/
This is regression from JDK-6342381. When a modal dialog blocks drop
operation in progress state consequent mouse events
On 8/5/2015 12:27 PM, Sergey Bylokhov wrote:
On 04.08.15 14:54, Semyon Sadetsky wrote:
On 8/3/2015 6:05 PM, Sergey Bylokhov wrote:
Hi, Semyon
Did you try to change dwMilliseconds from INFINITE to the timeout(10
seconds by default?) which is passed to the method? It does not
help? Because
On 8/5/2015 1:39 PM, Sergey Bylokhov wrote:
On 05.08.15 13:18, Semyon Sadetsky wrote:
On 8/5/2015 12:27 PM, Sergey Bylokhov wrote:
On 04.08.15 14:54, Semyon Sadetsky wrote:
On 8/3/2015 6:05 PM, Sergey Bylokhov wrote:
Hi, Semyon
Did you try to change dwMilliseconds from INFINITE
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8014725
webrev: http://cr.openjdk.java.net/~ssadetsky/8014725/webrev.00/
The test is moved from closed to open repo. Initially it was a test
issue: new document html flavor parameters introduced in 7075105 were
Hi Sergey,
You've marked the bug as noreg-sqe. I could not find the existing test
that crashes during the bug scenario. Could add this info?
--Semyon
On 7/29/2015 6:51 PM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk9.
In the fix 8068886[1] the new native resources
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8011616
webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/
WM sends the real window position in the configuration event but window
peer does not set it to the target. Solution is: do set.
--Semyon
to the
application on the toolkit thread. This code should be carefully
checked to remove appcontext related stuff from the toolkit thread.
On 21.07.15 12:40, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8130895
webrev: http
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8130471
webrev: http://cr.openjdk.java.net/~ssadetsky/8130471/webrev.00/
This is a regression from 8041470 in which mouse event modifiers was
changed for all wheel events including button click event. That caused
on the toolkit thread. This code should be carefully
checked to remove appcontext related stuff from the toolkit thread.
On 21.07.15 12:40, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8130895
webrev: http://cr.openjdk.java.net
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8131670
webrev: http://cr.openjdk.java.net/~ssadetsky/8131670/webrev.00/
1ms auto-delay was set to the robot to improve stability on Linux
platforms.
Also additional focus request procedure added to improve focus
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8025815
wbrev: http://cr.openjdk.java.net/~ssadetsky/8025815/webrev.00/
The root cause is a mixing of GTK and XLib windows. Normally Java uses
XLib windows and manage focus transitivity on its side. But for the
This is concurrency issue. Such test would be unstable or take a lot of
time.
On 7/14/2015 1:08 PM, Sergey Bylokhov wrote:
On 13.07.15 16:59, Semyon Sadetsky wrote:
Yet another issue I found in the GTK file chooser code is a dispose
concurrency issue. The GTK dialog widget is being created
The fix is stable.
On 7/14/2015 3:02 PM, Sergey Bylokhov wrote:
On 14.07.15 14:16, Semyon Sadetsky wrote:
This is concurrency issue. Such test would be unstable or take a lot
of time.
I guess after the fix it should be stable? or there are some other
issues?
On 7/14/2015 1:08 PM, Sergey
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8130769
webrev: http://cr.openjdk.java.net/~ssadetsky/8130769/webrev.00/
This is regression from JDK-7155957. Menu should be added to MenuBar
collection before the adding it to MenuBar's peer otherwise it is not
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8041519
webrev: http://cr.openjdk.java.net/~ssadetsky/8041519/webrev.00/
This is regression from JDK-6342381. When a modal dialog blocks drop
operation in progress state consequent mouse events clear the drop
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8130895
webrev: http://cr.openjdk.java.net/~ssadetsky/8130895/webrev.00/
realSync() used in the test's TestRunnable class causes events come to
the XAWT event loop but there are no any windows created at the
On 10/29/2015 12:20 AM, Sergey Bylokhov wrote:
On 06.10.15 9:15, Semyon Sadetsky wrote:
Sorry. I meant it is not guaranteed to be sent by every WM.
But fetch the data of 100 times also doesn't guarantee that we
will get the necessary data. It will be better at least to try to
check
,
jdk 1.8 & build dependencies prompted by sh configure.
As we see the difference in behavior, what kind of system information
would be needed with the JIRA issue ?
Many Thanks,
Ambarish
*From:*Semyon Sadetsky
*Sent:* Thursday, November 05, 2015 6:24 PM
*To:* Ambarish Rapte; Prasanta Sadhu
called twice.
There is a difference in behavior for event.
The cause of this difference in behavior should be identified before
proceeding further.
Please provide any inputs if possible.
Many Thanks,
Ambarish
*From:*Semyon Sadetsky
*Sent:* Tuesday, November 03, 2015 3:18 PM
*To:* Ambarish Rapte
nta
-
Prasanta also has verified similar way, that the test passes.
Kindly request you to try again.
Also If possible, please share the execution log of failure for me to
verify.
Many Thanks,
Ambarish
*From:*Semyon Sadetsky
*Sent:* Friday, October 30, 2015 10:07
On 11/5/2015 5:50 PM, Alexander Scherbatiy wrote:
On 10/19/2015 2:08 PM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8139227
webrev: http://cr.openjdk.java.net/~ssadetsky/8139227/webrev.00/
Win32 window owner query returns
Hi Ambarish,
After your fix applying the test still fails.
--Semyon
On 10/29/2015 5:00 PM, Ambarish Rapte wrote:
Dear All,
Kindly review the fix for JDK9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8048171
Webrev:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8139227
webrev: http://cr.openjdk.java.net/~ssadetsky/8139227/webrev.00/
Win32 window owner query returns the browser frame for applet's child
window because there are no any other overlapped or popup windows on
getCause_NonCLientCode like we usually do when the user
is able to override it.
Please review the modified fix
http://cr.openjdk.java.net/~ssadetsky/8080395/webrev.01/
On 11.09.15 0:15, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/b
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8134669
webrev: http://cr.openjdk.java.net/~ssadetsky/8134669/webrev.00/
The Gnome WM does not set extended hints with insets, so they are
unavailable. As solution it is proposed to query the single screen
The fix looks good.
--Semyon
On 10/7/2015 5:38 PM, Alexander Scherbatiy wrote:
On 10/7/2015 5:25 PM, Semyon Sadetsky wrote:
Hi Alexander,
I wonder, what is the reason for main/othervm in the test if it
starts a separate process anyway?
I do not have any particular reason to use
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8074810
webrev: http://cr.openjdk.java.net/~ssadetsky/8074810/webrev.00/
The mentioned in the bug dependencies are eliminated.
--Semyon
one does. It looks
messy.
--Semyon
Thanks,
Alexander
On 10/15/2015 9:09 PM, Semyon Sadetsky wrote:
Hi Alexander,
Since you are doing cosmetic changes, could please wrap the amended
lines to 80 characters per line?
Also some notes:
MultiResolutionImage.java interface has a mix of verbose
On 10/19/2015 8:41 PM, Sergey Bylokhov wrote:
On 15.10.15 9:57, Semyon Sadetsky wrote:
- Why did you add a check to the new constructor of FocusEvent? This
check should be done already in the EventObject, and executes before
your new check? Is it a typo and it should be cause? When why do
On 10/19/2015 8:12 PM, Sergey Bylokhov wrote:
On 18.09.15 18:50, Semyon Sadetsky wrote:
Why do you think so? Each app context KFM has own keystrokes if it is
initialized from the thread that belongs to its ThreadGroup.
Sorry. I see what you mean. That is corrected as well:
http
On 10/20/2015 6:13 PM, Sergey Bylokhov wrote:
On 20.10.15 13:33, Semyon Sadetsky wrote:
On 10/19/2015 8:12 PM, Sergey Bylokhov wrote:
On 18.09.15 18:50, Semyon Sadetsky wrote:
Why do you think so? Each app context KFM has own keystrokes if it is
initialized from the thread that belongs
Hi Alexander,
The fix looks good.
--Semyon
On 10/7/2015 4:25 PM, Alexander Scherbatiy wrote:
Hello,
Could you review the fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8136999
webrev: http://cr.openjdk.java.net/~alexsch/8136999/webrev.00
The test sets drop target to null in the
On 10/13/2015 6:03 PM, Sergey Bylokhov wrote:
On 09/29/2015 08:51 PM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8022334
webrev: http://cr.openjdk.java.net/~ssadetsky/8022334/webrev.00/
The Unity WM cannot switch top-level
Hi Alexander,
Since you are doing cosmetic changes, could please wrap the amended
lines to 80 characters per line?
Also some notes:
MultiResolutionImage.java interface has a mix of verbose/implicit method
modifiers. It would be nice to reduce it to the uniform style.
MenuComponent.java :
Hi Alexander,
I wonder, what is the reason for main/othervm in the test if it starts a
separate process anyway?
--Semyon
On 10/7/2015 5:09 PM, Alexander Scherbatiy wrote:
Hello,
Could you review the fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8139050
webrev:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8081457
webrev: http://cr.openjdk.java.net/~ssadetsky/8081457/webrev.00/
In OEL7 the system tray was changed a lot. It is totally hidden by
default and its tray icons only capable to receive click events. Mouse
Sorry. I meant it is not guaranteed to be sent by every WM.
On 10/6/2015 9:03 AM, Semyon Sadetsky wrote:
In is extended event. In does not guaranteed to be sent by any WM.
On 10/5/2015 6:12 PM, Sergey Bylokhov wrote:
Why we cannot treat such a XA_NET_FRAME_EXTENTS as a ConfigureNotify
In is extended event. In does not guaranteed to be sent by any WM.
On 10/5/2015 6:12 PM, Sergey Bylokhov wrote:
Why we cannot treat such a XA_NET_FRAME_EXTENTS as a ConfigureNotify
in which only insets are changed, and the window bounds/insets should
be revalidated?
On 05.10.15 14:56, Semyon
of these changes
are unnecessary. Did you run them on jake? I guess they are passed on
jake even before the fix, no?
What about SoundBug.java and JPEGInputStreamTest.java which are
mentioned in the comments?
On 08.10.15 22:21, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https
Sergey, thanks, again!
http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.02/
--Semyon
On 7/8/2015 2:35 PM, Sergey Bylokhov wrote:
On 08.07.15 12:37, Semyon Sadetsky wrote:
Thanks, Sergey!
The update fix: http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.01/
You forgot to update
Thanks, Sergey!
The update fix: http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.01/
--Semyon
On 7/7/2015 9:46 PM, Sergey Bylokhov wrote:
Hi, Semyon.
It seems that the javadoc of this method/class should be updated via ccc?
On 07.07.15 13:38, Semyon Sadetsky wrote:
Hello,
Please review
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8130390
webrev: http://cr.openjdk.java.net/~ssadetsky/8130390/webrev.00/
The FlipBufferStrategy did not take an Applet possibility into account.
--Semyon
On 8/5/2015 2:33 PM, Sergey Bylokhov wrote:
On 05.08.15 14:20, Semyon Sadetsky wrote:
On 8/5/2015 1:39 PM, Sergey Bylokhov wrote:
On 05.08.15 13:18, Semyon Sadetsky wrote:
On 8/5/2015 12:27 PM, Sergey Bylokhov wrote:
On 04.08.15 14:54, Semyon Sadetsky wrote:
On 8/3/2015 6:05 PM
Guys, just a reminder.
On 8/4/2015 3:34 PM, Semyon Sadetsky wrote:
Hi Sergey,
It was not me. webrev diff to the last repository version.
the updated fix: http://cr.openjdk.java.net/~ssadetsky/8131670/webrev.01/
--Semyon
http://cr.openjdk.java.net/~ssadetsky/8131670/webrev.01/
On 7/22/2015
Any other reviewers? Alexander, Sergey?
On 8/26/2015 4:34 PM, Alexander Scherbatiy wrote:
The fix looks good to me.
Thanks,
Alexandr.
On 8/4/2015 1:22 PM, Semyon Sadetsky wrote:
On 7/29/2015 2:06 PM, Alexander Scherbatiy wrote:
On 7/23/2015 9:21 PM, Semyon Sadetsky wrote:
Hello
-Dswing.bufferPerWindow. When this option
is passed the backbuffer should be created automatically if supported.
On 04.09.15 14:03, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8134732
webrev: http://cr.openjdk.java.net/~ssadetsky
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8134732
webrev: http://cr.openjdk.java.net/~ssadetsky/8134732/webrev.00/
It's a test bug: when the flip buffer is not available on the platform
its creation attempt causes exception.
Solution: ignore the
Yes, I thought about that. But flip buffer is potentially allowed to
throw other exceptions caused by the platform.
Wouldn't it be excessive to introduce such unspecified expectation?
On 9/4/2015 5:01 PM, Sergey Bylokhov wrote:
On 04.09.15 15:12, Semyon Sadetsky wrote:
The original bug
We cannot guarantee that the used way of the creation of the buffer
strategy will not cause any unchecked exceptions. We don't need to
stumble on them.
On 9/7/2015 2:59 PM, Sergey Bylokhov wrote:
On 04.09.15 17:42, Semyon Sadetsky wrote:
Yes, I thought about that. But flip buffer
On 9/7/2015 3:28 PM, Sergey Bylokhov wrote:
On 03.09.15 17:43, Semyon Sadetsky wrote:
On 8/5/2015 2:33 PM, Sergey Bylokhov wrote:
On 05.08.15 14:20, Semyon Sadetsky wrote:
On 8/5/2015 1:39 PM, Sergey Bylokhov wrote:
On 05.08.15 13:18, Semyon Sadetsky wrote:
On 8/5/2015 12:27 PM
On 9/7/2015 6:56 PM, Sergey Bylokhov wrote:
On 07.09.15 16:41, Semyon Sadetsky wrote:
On 9/7/2015 3:28 PM, Sergey Bylokhov wrote:
On 03.09.15 17:43, Semyon Sadetsky wrote:
On 8/5/2015 2:33 PM, Sergey Bylokhov wrote:
On 05.08.15 14:20, Semyon Sadetsky wrote:
On 8/5/2015 1:39 PM
1 - 100 of 605 matches
Mail list logo
