Hi, Chris,
code cleanups are always welcome, but should be done with care. Even
small refactorings could result in issues in someone else' apps.
Some minor comments below.
On 10/20/16, 2:32 PM, Chris wrote:
While working on SkinJob, I ran IntelliJ's Code Inspector tool over
OpenJDK AWT, and
of Simple Majority, results above are
enough to approve the nomination.
[4] http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011465.html
[5] http://openjdk.java.net/bylaws#simple-majority
Thanks,
Artem
On 6/10/16 6:39 PM, Artem Ananiev wrote:
Hi, AWT team,
I hereby nominate Sergey
Vote: yes (obviously)
Arten
On 6/10/16 6:39 PM, Artem Ananiev wrote:
Hi, AWT team,
I hereby nominate Sergey Bylokhov (OpenJDK user name: serb) to AWT Group
Lead [1].
Sergey is a member of Java Client group at Oracle. He has been one of
the most active contributors to AWT (and other Java
Hi, AWT team,
I hereby nominate Sergey Bylokhov (OpenJDK user name: serb) to AWT Group
Lead [1].
Sergey is a member of Java Client group at Oracle. He has been one of
the most active contributors to AWT (and other Java client libs: Swing,
Java2D, JavaFX, Java Sound, Java Beans) last few
Hi, AWT group,
for quite a while, I haven't been involved into AWT group activities as
much as I used to be. For the group to move on, I request to resign as
the group leader, as described in OpenJDK Bylaws:
http://openjdk.java.net/bylaws#group-lead
Thanks,
Artem
Hi, Hendrik,
as far as I remember, AWT team investigated the new file dialog, when
Vista was released. It looks fine, but there's an issue: it doesn't
provide a way to implement
FileDialog.setFilenameFilter(FilenameFilter filter)
method. The chances are Microsoft has introduced new APIs for
Hi, Sergey,
it looks fine to me now.
Thanks,
Artem
On 12/12/2014 5:30 PM, Sergey Bylokhov wrote:
Hi, Artem.
Thanks for review!
The new version:
http://cr.openjdk.java.net/~serb/7077826/webrev.01
On 10.12.2014 16:53, Artem Ananiev wrote:
Hi, Sergey,
the fix looks fine to me as well. Just
Hi, Sergey,
the fix looks fine to me as well. Just a few cosmetic comments:
1. When we don't care about return value, we usually use
PrivilegedActionVoid, not Object
2. For consistency with Boolean.toBoolean(), which is private, I would
suggest to change true.equals() to
The vote [1] for Alexander Zvegintsev (OpenJDK user name: azvegint) is
now closed.
Yes: 6
Veto: 0
Abstain: 0
According to the Bylaws definition of Lazy Consensus [2], this is
sufficient to approve the nomination.
[1]
http://mail.openjdk.java.net/pipermail/awt-dev/2014-September/008444.html
On 6/20/2014 3:19 PM, Anthony Petrov wrote:
Hi Petr,
I ran the following query:
https://www.google.com/#q=custom+flavormap.properties
and the search yielded the following forum thread:
https://community.oracle.com/thread/1293314?start=0tstart=0
where developers seem to suggest they do edit
Vote: yes
Artem
On 5/19/2014 11:51 PM, Anthony Petrov wrote:
I hereby nominate David DeHaven (OpenJDK user name: ddehaven) for jdk9
Committer
David has contributed a number of patches to JDK 7u, 8, 8u, and 9. Also,
he has reviewed many fixes that went into those releases. The AWT Group
I'm fine with the fix.
Thanks,
Artem
On 5/15/2014 9:36 PM, Petr Pchelko wrote:
Hello, David.
The fix looks good to me.
Artem was interested in the review, so we may want to wait for his final vote..
I can push the changeset for you. Please ping me when you decide it’s ready to
go.
Thank
On 5/12/2014 3:53 PM, Anthony Petrov wrote:
Hi David,
The fix looks good to me. To answer your questions:
1. Using the XAWT macro is correct. It is only defined if we're building
the XToolkit, which we don't on the Mac. However, everywhere else we
actually check
XAWT is a legacy macro,
Hi, Mikhail,
the fix looks fine.
The test looks fine as well, except the button field, which should be
volatile.
Thanks,
Artem
On 4/8/2014 6:03 PM, mikhail cherkasov wrote:
Hi again,
A regression test was added:
http://cr.openjdk.java.net/~mcherkas/8031075/webrev.01/
Could you please
Hi, Sergey,
it looks fine.
Have you verified that
@see InputStream#mark
is resolved by JavaDoc to the correct link? Shouldn't it be
@see java.io.InputStream#mark
?
MidiFileWriter: class JavaDoc contains both {@code} and {@link}, do we
need to use one of them? Other classes contain {@code}
Hi, Sergey,
I spotted a few differences, but I don't have a strong opinion whether
they should be fixed. Leaving them up to you.
In other words, I'm fine with the fix.
Thanks,
Artem
On 3/21/2014 3:47 PM, Sergey Bylokhov wrote:
On 3/21/14 3:17 PM, Artem Ananiev wrote:
Hi, Sergey
AM, Oleg Pekhovskiy wrote:
Hi all,
please review the next version of fix:
http://cr.openjdk.java.net/~bagiras/8031694.2/
We with Artem Ananiev had off-line discussion and he offered let the
dying EDT to die
and process unhandled events by forcing another EDT start.
Thanks,
Oleg
On 01/28/2014 05
On 2/10/2014 9:25 PM, Anthony Petrov wrote:
Looks okay. How faster does the Label work now, btw? :)
Earlier today Sergey told it would be about ~20% - AWT Label should be
very fast now :)
A minor comment from my side. Since we already use ?: in
Component.paramString(), we can also use it
On 2/7/2014 1:39 AM, Sergey Bylokhov wrote:
Hmm, we need someone else, who will solve a problem.
Artem, what do you think?
I would suggest to suppress all the AWT events from our internal
components. That is, if a component is accessible from application (e.g.
JScrollPane's viewport), its
Adding java-dev@apple alias to CC.
Artem
On 1/22/2014 7:23 PM, Alexander Scherbatiy wrote:
Hello,
Below is the code that shows that setting a component orientation for
the JProgressBar in Aqua LF does not work.
My assumption was that the Direction should be properly set to the
Since you're adding @Override in many places, didn't you think about
replacing some of the inner Runnable classes with lambdas?
Thanks,
Artem
On 1/24/2014 6:49 PM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
This is cleanup of the sun.awt.windows package:
-
On 12/19/2013 2:46 PM, Alexander Zvegintsev wrote:
Hello AWT team,
I am currently looking at JDK-6464548 issue[1], and as you can see in
javadoc[2]
we have only setMinimumSize() implemented in java.awt.Window and
setMaximumSize() is not implemented.
So my question is about how
Changeset: 20d504a20a87
Author:azvegint
Date: 2013-12-13 14:29 +0400
URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/20d504a20a87
8029923: Many Swing tests and SwingSet2 are failing under Solaris using GTK LaF
- Unable to load native GTK libraries
Reviewed-by: anthony, serb
!
Hi, Alan,
the changes look fine to me.
A short quick question: what is the reason to introduce a new
AWTPermissions class as a holder for various AWTPermission constants? We
can have the same fields directly in AWTPermission. The only difference
is that AWTPermission is in java.awt, while
Looks fine to me as well.
Thanks,
Artem
On 12/9/2013 5:15 PM, Anthony Petrov wrote:
Hi Anton,
The fix looks good to me.
--
best regards,
Anthony
On 12/07/2013 02:03 AM, Anton Litvinov wrote:
Hello Artem and Anthony,
Could you please review this backport of the fix, which was approved by
Hi, Anton,
the fix looks fine in general. A few minor comments:
1. xerror_code is not used now and can be removed. XERROR_SAVE seems to
be unused as well.
2. current_native_xerror_handler can be declared as extern in
awt_util.h, so you don't need to declare it in every file where it's
used
synthetic error handler first.
to
1270 // First call the native synthetic error handler declared
in awt_util.h file.
Thank you,
Anton
On 12/2/2013 12:19 PM, Artem Ananiev wrote:
Hi, Anton,
the fix looks fine in general. A few minor comments:
1. xerror_code is not used now and can be removed
Hi, Volker,
just a few very minor comments about the client changes:
1. mlib_sys.c: the change is fine, but it makes the following comment
obsolete.
2. XRBackendNative.c: the same comment here.
3. Awt2dLibraries.gmk: $(JDK_TOPDIR)/src/aix/porting/porting_aix.c would
be better than just
Hi, Mandy,
the fix looks fine to me. Other people might want to ask why these
methods are no longer used and can be safely removed, so be prepared to
the questions :)
Thanks,
Artem
On 11/13/2013 2:15 AM, Mandy Chung wrote:
Adding awt-dev for the review.
Mandy
On 11/12/2013 11:29 AM,
Looks fine.
Thanks,
Artem
On 11/13/2013 7:50 PM, Oleg Pekhovskiy wrote:
Hi all,
please review the fix
http://cr.openjdk.java.net/~bagiras/8028283.1/
for
https://bugs.openjdk.java.net/browse/JDK-8028283
It's just a JavaDoc reverse changes.
Thanks,
Oleg
On 11/8/2013 12:42 AM, Anthony Petrov wrote:
It's funny how TRUETRUE does the trick :)
Anyway, the fix looks fine to me. Thanks for resolving this issue.
Sergey, and/or Artem, could you please review it, too? We need this fix
in JDK 8.
The changes look fine to me.
I'm not a big fan of
,
Artem
--
best regards,
Anthony
On 11/08/2013 12:27 PM, Artem Ananiev wrote:
On 11/8/2013 12:42 AM, Anthony Petrov wrote:
It's funny how TRUETRUE does the trick :)
Anyway, the fix looks fine to me. Thanks for resolving this issue.
Sergey, and/or Artem, could you please review it, too? We need
Looks fine to me.
Thanks,
Artem
On 10/28/2013 2:42 PM, Petr Pchelko wrote:
Hello, Sergey.
Thank you for the review, here's the updated version:
http://cr.openjdk.java.net/~pchelko/8027152/webrev.03/
With best regards. Petr.
On 28.10.2013, at 14:19, Sergey Bylokhov
Hi, Alexander,
a few comments:
1. SunGraphics2D.java:3076 - should isHiDPIImage() be used here?
2. I'm not sure that the proposed getScaledImageName() implementation in
ScalableToolkitImage works perfectly for URLs like this:
http://www.exampmle.com/dir/image
In this case it will try to
Thanks.
Artem
On 10/25/2013 5:45 PM, Anton V. Tarasov wrote:
Hi Artem,
On 10/24/13 6:59 PM, Artem Ananiev wrote:
Hi, Anton,
it looks much better now. Is it possible to create a regression test
for this change?
Ok, I did that. Here's the test:
http://cr.openjdk.java.net/~ant/RT-32570
On 10/24/2013 9:30 PM, Sergey Bylokhov wrote:
Hi, Anthony.
After a small considering with Artem I decided to reduce changes as we
at zbb stage
here is a new small version:
http://cr.openjdk.java.net/~serb/7172770/webrev.01
Looks fine.
Thanks,
Artem
On 24.10.2013 18:22, Anthony Petrov
Hi, David,
.03 looks fine.
Thanks for investigation, addressing all our comments, and this cleanup
in general.
Artem
On 10/24/2013 7:52 AM, David DeHaven wrote:
Another option (I think would make everyone happy) would be to add a native
method to LWCToolkit.{java,m} that implements
Hi, Anton,
it looks much better now. Is it possible to create a regression test for
this change?
Thanks,
Artem
On 10/24/2013 6:35 PM, Anton V. Tarasov wrote:
Hello,
Please look at the new version:
http://cr.openjdk.java.net/~ant/RT-32570/webrev.1
It eliminates code dependency b/w awt
Hi, Anton,
can this code be moved to WLightweightFramePeer? It would help to get
rid of the nasty instanceof check.
Thanks,
Artem
On 10/23/2013 10:15 PM, Anton V. Tarasov wrote:
Hello,
Please, review the fix:
jira: https://bugs.openjdk.java.net/browse/JDK-8027157
webrev:
On 10/23/2013 4:34 PM, Anthony Petrov wrote:
On 10/23/2013 08:52 AM, David Holmes wrote:
On 23/10/2013 2:10 PM, David DeHaven wrote:
Updated webrev:
http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/
Summary of changes since last:
- Added awt_headless to java_props_t (set to NULL by
Hi, David,
thanks for additional cleanup.
I have only one concern. Before the fix, we checked if there is an
active Aqua session. When no session was found, we falled back to
HToolkit. I think this logic should be preserved, but slightly
corrected: fall back to HeadlessToolkit (with CToolkit
Hi, Sergey,
this version looks fine.
Thanks,
Artem
On 10/22/2013 3:19 PM, Sergey Bylokhov wrote:
New version here:
http://cr.openjdk.java.net/~serb/7090424/webrev.02/
On 22.10.2013 13:52, Anthony Petrov wrote:
Hi Sergey,
Sorry, but I can't review a fix w/o a webrev.
What kind of problems
Hi, David,
the changes look fine to me. See more comments below.
On 10/21/2013 3:56 AM, David DeHaven wrote:
CCing: build-dev, macosx-port-dev, hotspot-dev
Request for review of JDK-8025673:
https://bugs.openjdk.java.net/browse/JDK-8025673
Proposed changes:
Hi, David,
client (AWT, Java2D) part of the fix looks fine.
Thanks,
Artem
On 10/21/2013 3:53 AM, David DeHaven wrote:
CCing: build-dev, macosx-port-dev
Request for review of JDK-8016096:
https://bugs.openjdk.java.net/browse/JDK-8016096
Proposed changes:
Is .00 the latest version of the webrev? It looks fine to me.
Thanks,
Artem
On 10/17/2013 8:59 PM, Andrei Eremeev wrote:
Hi,
I am waiting for a second reviewer. Anthony's remark can be easily fixed.
If there are no objections, I will fix bug id in the comment and commit fix.
Andrei
-
Hi, Sergey,
we have a number of listener interfaces in java.awt.event, some of them
have a single method, others have multiple. For consistency, I would
refrain from marking some of them as @FunctionalInterfaces (though it's
technically possible).
KeyEventDispatcher and
Looks fine.
Thanks,
Artem
On 10/16/2013 6:55 PM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 8.
In the fix, synchronization on this under awttreelock was removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8026356
Webrev can be found at:
Looks fine.
Thanks,
Artem
On 10/17/2013 6:34 PM, Sergey Bylokhov wrote:
Hi, Artem.
Here is updated version.
http://cr.openjdk.java.net/~serb/8022657/webrev.01
On 17.10.2013 18:10, Artem Ananiev wrote:
Hi, Sergey,
we have a number of listener interfaces in java.awt.event, some of
them have
Hi, Kalyan,
it seems that the webrev doesn't correspond to 8026071, but to another
bug about javac warnings.
Thanks,
Artem
On 10/9/2013 11:07 PM, srikalyan chandrashekar wrote:
Hi team , could someone review the fix
Bug : https://bugs.openjdk.java.net/browse/JDK-8026071
On 10/16/2013 3:29 PM, Anthony Petrov wrote:
Hi Oleg,
The fix looks good to me. However, I don't recall all details about this
machinery, and removing a call to peekEvent() in
EventQueue.detachDispatchThread() looks a bit scary.
Could Artem or you clarify if AWTAutoShutdown() recreates the
Hi, Oleg,
as we discussed this fix earlier, it looks fine.
Thanks,
Artem
On 10/16/2013 2:31 PM, Oleg Pekhovskiy wrote:
Hi all,
please review the fix
http://cr.openjdk.java.net/~bagiras/2228674.1/
for
https://bugs.openjdk.java.net/browse/JDK-2228674
The fix covers two scenarios:
1. User
that this might cause...)
...jim
On 10/2/13 3:02 AM, Artem Ananiev wrote:
java.awt.image is one of the Java2D packages, so I'm adding 2d-dev to
CC. Please, wait for at least one approval from Java2D team.
For easier review, I put the webrev here:
http://cr.openjdk.java.net/~art/srikalyc
Hi, Anton,
thanks for details description of the bug and suggested fix. It helped a
lot.
My understanding is that the problem is not with step 2, but step 3.
Generating drag entered events on mouse press looks incompatible, I
can't predict side effects of such a change. Fixing step 3, so we
Hi, Sergey,
the fix looks acceptable (I can't say fine, because I can't predict
side effects). That's why could you also add the following information
to bug comments:
1. Current fix
2. Alternative fix, when we asynchronously update GD's full screen window
Thanks,
Artem
On 10/11/2013 6:10
Looks fine.
Thanks,
Artem
On 10/11/2013 12:59 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8026262
The fix is available at:
http://cr.openjdk.java.net/~pchelko/8026262/webrev.00/
The cause is a forgotten null check
.
Thanks,
Artem
---
Thanks
kalyan
On 10/9/2013 3:12 AM, Artem Ananiev wrote:
I put the updated webrev here:
http://cr.openjdk.java.net/~art/srikalyc/8022185.01/
A few comments:
1. DataFlavor.java: some of the lines got too long after the fix.
Please, reformat or add import statements.
2
haven't see your replies to Jim's questions, have you seen his email?
Thanks,
Artem
---
Thanks
kalyan
On 10/2/2013 3:02 AM, Artem Ananiev wrote:
java.awt.image is one of the Java2D packages, so I'm adding 2d-dev to
CC. Please, wait for at least one approval from Java2D team.
For easier
I put the updated webrev here:
http://cr.openjdk.java.net/~art/srikalyc/8022185.01/
A few comments:
1. DataFlavor.java: some of the lines got too long after the fix.
Please, reformat or add import statements.
2. DataFlavor.java: there are some redundant class casts left, e.g. at
line
Looks fine.
Thanks,
Artem
On 10/9/2013 12:50 PM, Anthony Petrov wrote:
Hello,
This is a reminder.
--
best regards,
Anthony
On 10/04/2013 03:11 PM, Anthony Petrov wrote:
Hello,
This is another forward-port (a direct one this time) that didn't make
it into JDK 8 yet:
bug:
Hi, Petr,
a few comments:
1. Can InvocationEvent.notifier be final instead of volatile?
2. InvocationEvent now has 4 ctors, 3 public and 1 private. Can all the
public ctors call the private one directly? Right now there is an extra
call from one public ctor to another, which then call the
Hi, Vladimir,
have you received this reply, or it was lost for some reason?
Thanks,
Artem
On 8/28/2013 5:52 PM, Artem Ananiev wrote:
Hi, Vladimir,
I agree that using a class with no equals/hashCode overridden as a key
for HashMap is not the best thing to do. However, in this case
fix is available here:
http://cr.openjdk.java.net/~pchelko/8025588/webrev.01/
With best regards. Petr.
On 09.10.2013, at 14:31, Artem Ananiev artem.anan...@oracle.com wrote:
Hi, Petr,
a few comments:
1. Can InvocationEvent.notifier be final instead of volatile?
2. InvocationEvent now has 4
testing.
Thanks,
Artem
On Oct 8, 2013, at 7:43 PM, Artem Ananiev artem.anan...@oracle.com wrote:
On 10/8/2013 6:54 PM, Leonid Romanov wrote:
Hi,
I tried different variations of your suggestion and none of them worked. The
reason is timing: suppose two threads, A and B, entered
Thanks,
Alexandr.
--
best regards,
Anthony
On 10/04/2013 03:29 PM, Sergey Bylokhov wrote:
Hello.
It is interesting what should happens if we set saot for the child, then
set it to the owner, and then remove this property from the owner.
On 04.10.2013 12:46, Artem Ananiev wrote:
On 10/4
, at 9:54 PM, Artem Ananiev artem.anan...@oracle.com wrote:
On 10/1/2013 9:17 PM, Anthony Petrov wrote:
Hi Petr,
MS Windows always sends WHEEL events to the focused window. And my
testing shows that when you scroll the wheel outside of an AWT window,
the scroll events are consumed (by AWT
. It will still be useful to prevent regression in the
future.
Thanks,
Artem
On Oct 4, 2013, at 1:06 PM, Artem Ananiev artem.anan...@oracle.com wrote:
Hi, Leonid,
the fix looks fine.
I believe it is possible to create a regression test for this fix. The test
should create several thread groups
Hi, Oleg,
could you provide information (here and in bug comments), what are the
values returned by GetWindowRect() and getWindowPlacement(), while the
window is being snapped and after it has been snapped, please?
Thanks,
Artem
On 10/7/2013 2:17 PM, Oleg Pekhovskiy wrote:
Hi All,
Please
Hi, Sergey,
the changes look fine.
Could you also remove deprecated methods in WTextArea, e.g.
insertText(), since you touch these files anyway, please?
Thanks,
Artem
On 10/2/2013 10:38 PM, Sergey Bylokhov wrote:
Hello,
Please review the fix for jdk 8. This is a code cleanup.
Bug:
On 10/4/2013 3:37 PM, Anthony Petrov wrote:
On 10/04/2013 02:57 PM, Artem Ananiev wrote:
On 10/4/2013 2:45 PM, Anthony Petrov wrote:
On 10/02/2013 05:07 PM, Artem Ananiev wrote:
You're right, it's not necessary. However, since we touch this code
anyway, I'd be glad to have this redundant
WComponentPeer.minimumSize also removed, because it is never used in
java or in native.
On 07.10.2013 18:03, Artem Ananiev wrote:
Hi, Sergey,
the changes look fine.
Could you also remove deprecated methods in WTextArea, e.g.
insertText(), since you touch these files anyway, please?
Thanks,
Artem
On 10/2/2013 10:38
On 10/4/2013 12:24 PM, Anthony Petrov wrote:
The fix looks good to me.
+1.
I would also add a comment to security exception [empty] handler that we
don't really expect exceptions here: either we have the permission, or
the owner is not alwaysOnTop.
Thanks,
Artem
--
best regards,
Hi, Leonid,
the fix looks fine.
I believe it is possible to create a regression test for this fix. The
test should create several thread groups and call AC.getAC() there, then
check that all the returned AC's are equal. Although it won't 100% fail
before your fix, it should 100% pass after
On 9/25/2013 2:46 PM, Jiaz wrote:
Hi,
could anyone with commit rights please apply the given bugfix in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7107490
I don't see the given bugfix, probably it was stripped by OpenJDK
mailer... According to the bug report, it's considered to be a
On 10/4/2013 2:45 PM, Anthony Petrov wrote:
On 10/02/2013 05:07 PM, Artem Ananiev wrote:
You're right, it's not necessary. However, since we touch this code
anyway, I'd be glad to have this redundant code removed.
It's not redundant. Please see my message below in the quote for
details.
Do
On 10/3/2013 11:30 AM, Oleg Pekhovskiy wrote:
Hi All,
please review the second version of fix:
http://cr.openjdk.java.net/~bagiras/7068423.2/
It looks fine to me.
Thanks,
Artem
Reason:
Discussed with Artem and Andrew, came to conclusion that there were
situations when returned object
Looks fine.
Thanks,
Artem
On 10/2/2013 5:34 PM, sergey malenkov wrote:
http://cr.openjdk.java.net/~malenkov/7081584.8.1/
http://cr.openjdk.java.net/%7Emalenkov/7081584.8.1/
The specification is updated.
SAM
On 02.10.2013 16:29, Artem Ananiev wrote:
On 10/2/2013 3:31 PM, sergey malenkov
java.awt.image is one of the Java2D packages, so I'm adding 2d-dev to
CC. Please, wait for at least one approval from Java2D team.
For easier review, I put the webrev here:
http://cr.openjdk.java.net/~art/srikalyc/8025684.00/
It looks fine to me. There is one unchecked warning still left,
Tho short questions:
1. Is a new weak reference (victimWindowRef) really required? Can't we
re-use weakThis, which is victim.weakThis?
2. When a window is deserialized, does it have an owner? Shouldn't we
call WDR.updateOwner() in initDeserializedWindow()?
Thanks,
Artem
On 10/1/2013
Looks fine.
Thanks,
Artem
On 10/2/2013 2:34 PM, Anthony Petrov wrote:
Hello,
Please review a long-awaited back-port of a fix for
https://bugs.openjdk.java.net/browse/JDK-7174704 at:
http://cr.openjdk.java.net/~anthony/8-61-headlessPrinting-7174704.0/
It is not a direct back-port because
On 10/2/2013 3:31 PM, sergey malenkov wrote:
This bug is about javadoc. What if I replace the default toolkit with
the current window toolkit?
The current window toolkit sounds strange. It should be clarified or
replaced with this window's toolkit + {@see #getToolkit}.
Thanks,
Artem
As
On 10/2/2013 4:26 PM, Anthony Petrov wrote:
On 10/02/2013 03:31 PM, sergey malenkov wrote:
This bug is about javadoc. What if I replace the default toolkit with
the current window toolkit?
I'd be fine with such a change.
As I understand the Peer API is not public. So we can modify it
Looks fine.
Thanks,
Artem
On 10/2/2013 4:17 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8024158
The fix is available at:
http://cr.openjdk.java.net/~pchelko/8024158/webrev.00/
The problem: Appkit thread could not
On 10/2/2013 4:38 PM, Anthony Petrov wrote:
On 10/02/2013 04:30 PM, Artem Ananiev wrote:
On 10/2/2013 4:26 PM, Anthony Petrov wrote:
On 10/02/2013 03:31 PM, sergey malenkov wrote:
This bug is about javadoc. What if I replace the default toolkit with
the current window toolkit?
I'd be fine
On 10/2/2013 5:01 PM, Sergey Bylokhov wrote:
Does anybody know why we use awtLock for soo long time in the toolkit
loop? Especially why we call dispatchEvent() under this lock?
It is by design. We do everything under the awtLock on the toolkit
thread, except waiting for incoming events.
On 10/1/2013 9:17 PM, Anthony Petrov wrote:
Hi Petr,
MS Windows always sends WHEEL events to the focused window. And my
testing shows that when you scroll the wheel outside of an AWT window,
the scroll events are consumed (by AWT, supposedly).
With your fix you seem to always redirect the
, Artem Ananiev wrote:
On 4/6/2012 8:25 PM, Sergey Bylokhov wrote:
05.04.2012 14:53, Artem Ananiev написал:
Hi, Sergey,
it's not clear why this particular change fixes the selection. Could
you add more comments to the bug evaluation, please?
comment added:
This happens because at the beginning
On 9/27/2013 6:04 PM, Alexander Zvegintsev wrote:
Hi Anthony, Artem,
Here is updated webrev:
http://cr.openjdk.java.net/~serb/alexz/8025225/webrev.01/
Looks good (I'm not a native speaker, though).
Thanks,
Artem
Thanks,
Alexander.
On 09/26/2013 05:22 PM, Artem Ananiev wrote:
On 9/24
Changeset: 09fb25645717
Author:ptbrunet
Date: 2013-09-26 10:48 +0200
URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/09fb25645717
8025160: Recent Java Accessibility Bridge push has make failures
Reviewed-by: tbell, erikj
! make/bridge/AccessBridgeJava/Makefile
!
On 9/24/2013 11:58 AM, Anthony Petrov wrote:
Hi Sergey,
I think that throwing an AWTError is too risky for JDK 8. We might want
to implement this early in JDK 9 though.
Both throwing an error and returning null are risky. A good news,
however, is that we don't expect the array to be empty,
Hi, Alexander,
the fix looks fine in general. A few comments:
1. A few comments in gtk2_interface.c about gtk versions would be fine.
2. lock()/unlock() pattern is usually used with try - finally. Could you
modify the example in GThreadHelper, please? We don't expect C code to
use try -
On 9/24/2013 2:06 PM, Anthony Petrov wrote:
Hi Alexander,
I suggest to mention that a call to setAlwaysOnTop(false) may also cause
an unspecified, platform-dependent change in the z-order of top-level
windows (still respecting their always-on-top states, however).
Otherwise this isn't clear
On 9/12/2013 3:45 PM, Sergey Bylokhov wrote:
Hi, Alexander.
The fix looks good.
Can you add additional comments about the new code in the AWTWindow.m.
It should describe that the native system can bring up the NSWindow to
the top even if the window is not main, and we should do some things
Hi, Petr,
the fix looks fine (I see it's been resolved already). However, it would
be fine to document the new behavior somewhere.
BTW, have you verified that this fix doesn't break JCK tests? I haven't
seen anywhere in JavaDoc that getScrollMode() must return the value
previously set with
On 9/2/2013 2:44 PM, Petr Pchelko wrote:
Hello, Artem.
I've created a new bug for this: 8024121
Thanks.
Artem
With best regards. Petr.
On Sep 2, 2013, at 2:30 PM, Artem Ananiev artem.anan...@oracle.com wrote:
Hi, Petr,
the fix looks fine (I see it's been resolved already). However
/6ffa2680e139
Thanks,
Artem
On 8/28/2013 11:00 AM, srikalyan chandrashekar wrote:
On 8/27/13 1:26 AM, Artem Ananiev wrote:
Hi, Kalyan,
On 8/27/2013 11:02 AM, srikalyan chandrashekar wrote:
Artem these explicit casts existed and is now redundant because the
warnings are fixed
For Ex: 1.ClassSomeClass obj
Changeset: 43de418f1345
Author:ptbrunet
Date: 2013-08-28 17:25 +0400
URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/43de418f1345
8011955: Lunar screen reader crashes intermittently in
WindowsAccessBridge-32.DLL
6995891: JAWS will occasionally stop speaking focused objects as
Hi, Vladimir,
I agree that using a class with no equals/hashCode overridden as a key
for HashMap is not the best thing to do. However, in this case the
problem seems to be caused by something else.
I'm not an expert in RepaintManager, but here is what I observe:
1. When graphics environment
--
Thanks
kalyan
On 8/26/13 6:39 AM, Artem Ananiev wrote:
On 8/23/2013 9:24 PM, srikalyan chandrashekar wrote:
Antony, Thanks for the review. Here's the renewed link
https://github.com/srikalyc/JDKfixes/blob/master/java.awt.static_raw_webrev_new.zip
covering the gaps.
Here is the updated link
Vladimir,
OpenJDK mailing lists are supposed to be used for OpenJDK related
discussions only. Emails like this are not acceptable and will result in
your removal from the list of subscribers in the future.
Thanks,
Artem
On 8/27/2013 4:53 PM, Vladimir Kravets wrote:
LinkedIn
don't use
the return value.
Otherwise the fix looks good to me.
--
best regards,
Anthony
On 08/22/2013 08:40 PM, Artem Ananiev wrote:
On 8/22/2013 8:25 PM, srikalyan chandrashekar wrote:
Hi team , could someone review the fix
Bug : https://jbs.oracle.com/bugs/browse/JDK-8022184
1 - 100 of 375 matches
Mail list logo
