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
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 year
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 a
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
PrivilegedAction, not
2. For consistency with Boolean.toBoolean(), which is private, I would
suggest to change "true".equals() to "true".equalsIgnoreCase(), b
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
I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) to
Membership in the AWT Group.
Alexander is a member of AWT/Swing group at Oracle. He has contributed
20+ fixes to JDK9 so far, and JDK8/8u contribution is significant as well.
Votes are due by Sep 17, 2014.
Only current
and
was originally proposed for jdk9 as is.
Webrev: http://cr.openjdk.java.net/%7Eanashaty/8046495/8/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8046495
Thank you!
Anton.
On 24.07.2014 18:10, Artem Ananiev wrote:
On 7/18/2014 2:28 PM, anton nashatyrev wrote:
Hello,
in
On 7/18/2014 2:28 PM, anton nashatyrev wrote:
Hello,
in offline discussion with Artem and Petr we decided to further
clean up the code and completely remove TimeHelper functions from
awt_Component.cpp in JDK9.
Could you please review the updated fix:
http://cr.openjdk.java.net/~anash
Hi, Petr,
the fix looks fine to me.
I would also suggest you to find the initial fix, when
EventQueueDelegate was introduced (in 6u10?), to check if anything else
can be wiped out.
Thanks,
Artem
On 6/23/2014 6:13 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the issu
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=0&tstart=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
partic
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 y
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, which
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 r
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, S
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}
r this fix?
--
best regards,
Anthony
On 2/7/2014 4:31 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 for
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 f
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 ev
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 L&F does not work.
My assumption was that the Direction should be properly set to the
paint
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:
- Encapsulatio
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 setMaximumSize()
On 12/17/2013 10:42 PM, Pete Brunet wrote:
Hi Anthony, Thanks again for the assistance!
On 12/17/13 7:29 AM, Anthony Petrov wrote:
Immediate load in JAWT*, delay load in Java*
Why is that? Can you try re-linking the JAWTAccessBridge.DLL so that
it uses delayed libs loading (which is always a
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
! s
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 the
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
uot;XlibWrapper.c" the comment was changed from
1270 // Pass the event to a native 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,
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
use
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 port
Hi, Sergey,
the fix looks fine in general. I would just propose an alternative
naming: instead of "mouseDTEnterExit" use "dropTargetEnterExit".
Thanks,
Artem
On 11/14/2013 7:31 PM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 8.
The problem was in the missing notification abo
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
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, Mand
K.
Thanks,
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 i
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 addin
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 wrote:
Hi, Petr.
As f
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-
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 f
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 wrote
JDK-7196567
<https://bugs.openjdk.java.net/browse/JDK-7196567> which entails this
bug 8026071 .
---
Thanks
kalyan
On 10/17/2013 8:04 AM, Artem Ananiev wrote:
Hi, Kalyan,
it seems that the webrev doesn't correspond to 8026071, but to another
bug about javac warnings.
Thanks,
Art
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 & s
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 isAqu
On 10/24/2013 6:01 AM, David Holmes wrote:
On 24/10/2013 1:11 AM, Artem Ananiev wrote:
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
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 defaul
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: http://cr.openjdk
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,
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, 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:
http://cr.openjdk.java.net/~ddehaven
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:
http://cr.openjdk.java.net/~ddehav
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, 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
Webr
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
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: http://cr.openjdk.java.net/~serb/
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 KeyEventPostProcessor
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 code
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 EDT
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, 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:1
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 w
Changeset: 2e04843f1c1d
Author:art
Date: 2013-10-11 16:44 +0400
URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2e04843f1c1d
8022185: Fix Raw and unchecked warnings in classes belonging to
java.awt.datatransfer
Reviewed-by: art, pchelko
Contributed-by: Srikalyan Chandrashekar
!
hortly.
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 statemen
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 in
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 te
keep testing.
Thanks,
Artem
On Oct 8, 2013, at 7:43 PM, Artem Ananiev 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
AppContetx.getAppContext() and
l looks fine.
Thanks,
Artem
The updated 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 wrote:
Hi, Petr,
a few comments:
1. Can InvocationEvent.notifier be final instead of volatile?
2. InvocationEv
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 the
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 pri
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: https://bugs.ope
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 #334.
penjdk.java.net/~bagiras/8016356.3/
Thanks,
Oleg
On 07.10.2013 16:02, Artem Ananiev wrote:
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,
ur fix. It will still be useful to prevent regression in the
future.
Thanks,
Artem
On Oct 4, 2013, at 1:06 PM, Artem Ananiev 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 and call AC.get
f it
doesn't.
That was indeed an issue. I've got used to Mac behaviour and did not notice the
problem.
The new version of the fix is available here:
http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/
Now we redispatch the wheel event only if the window is in the same process.
Artem
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
+1.
Thanks,
Artem
On 10/8/2013 12:38 PM, Anthony Petrov wrote:
Looks fine.
--
best regards,
Anthony
On 10/07/2013 09:39 PM, sergey malenkov wrote:
Hello,
Could you please review the following fix:
fix:http://cr.openjdk.java.net/~malenkov/7172597.8.0/
bug:https://bugs.openjdk.java.net/bro
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 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
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: https:/
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, Christine,
trademark changes look fine.
What's wrong with the table in BoxLayout.java? Were there any warnings
reported about it?
Thanks,
Artem
On 10/5/2013 4:08 AM, christine...@oracle.com wrote:
Hi,
Please review a fix for
https://bugs.openjdk.java.net/browse/JDK-8025840
Fix all th
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 quo
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
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 it
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,
Anthon
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 ma
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 coul
process.
With best regards. Petr.
On Oct 1, 2013, at 9:54 PM, Artem Ananiev 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 a
/8013563/webrev.01
Thanks,
Alexander.
On 10/02/2013 02:12 PM, Artem Ananiev wrote:
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'
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.
Tha
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 too
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 hav
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 w
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,
Arte
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 th
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 6:57
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,
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 even
, 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 begi
1 - 100 of 505 matches
Mail list logo
