On 10/12/2016 8:45 PM, Sergey Bylokhov wrote:
What kind of information these new error messages will contain(Will it
contain paths, username, etc)?
It is obvious from the the fix that it will contain the library name
which loading was failed and the OS error message.
On 07.10.16 13:10, Semyon
On 2016-10-14 17:51, Pete Brunet wrote:
Please review the following.
The .h files and .c file provided to allow Assistive Technology to
interface to the Java Access Bridge API are being removed from the built
JRE/JDK images. They are not used much and they can be obtained online
via the OpenJDK
Looks good.
On 10/7/16 4:21 PM, Sergey Bylokhov wrote:
On 07.10.16 10:06, Semyon Sadetsky wrote:
Hi Sergey,
After applying the patch I found 72 usages of the Event class. Why they
are not replaced?
By the same reason why InputEvent.getModifiers() was not replaced by
InputEvent.getModifiers
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8167176/webrev.01
MetalBorders.bumps and MetalScrollBarUI.bumps fields are nor marked
for removal any more.
Thanks,
Alexandr.
On 10/14/2016 3:23 PM, Sergey Bylokhov wrote:
Is it necessary to remove te
On 10/7/2016 4:21 PM, Sergey Bylokhov wrote:
On 07.10.16 10:06, Semyon Sadetsky wrote:
Hi Sergey,
After applying the patch I found 72 usages of the Event class. Why they
are not replaced?
By the same reason why InputEvent.getModifiers() was not replaced by
InputEvent.getModifiersEx():
>>>
--- old/src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.h
2016-10-17 16:31:34.889162611 +0300
+++ new/src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.h
2016-10-17 16:31:34.809162613 +0300
@@ -351,9 +351,6 @@
guint ellipsize : 3;
};
-
-typedef struct _GThreadFunctions
On 17.10.16 15:16, Semyon Sadetsky wrote:
>>> We can replace old constants by the new one in the whole jdk,
but I
>>> updated only the code in InputEvent to make change smaller and
>>> safer. So at least the new code in jdk and the code in
applications
>>> will start to use the ne
On 17.10.2016 17:19, Sergey Bylokhov wrote:
On 17.10.16 15:16, Semyon Sadetsky wrote:
>>> We can replace old constants by the new one in the whole jdk,
but I
>>> updated only the code in InputEvent to make change smaller and
>>> safer. So at least the new code in jdk and the code i
+1 assuming a JPRT build passes. I'll send you the right incantation
off-list
-phil.
On 10/17/16, 6:43 AM, Semyon Sadetsky wrote:
--- old/src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.h
2016-10-17 16:31:34.889162611 +0300
+++ new/src/java.desktop/unix/native/libawt_xawt/awt/gtk2
On 17.10.16 17:39, Semyon Sadetsky wrote:
On 17.10.2016 17:19, Sergey Bylokhov wrote:
On 17.10.16 15:16, Semyon Sadetsky wrote:
>>> We can replace old constants by the new one in the whole jdk,
but I
>>> updated only the code in InputEvent to make change smaller and
>>> safer. So
On 17.10.2016 18:37, Sergey Bylokhov wrote:
On 17.10.16 17:39, Semyon Sadetsky wrote:
On 17.10.2016 17:19, Sergey Bylokhov wrote:
On 17.10.16 15:16, Semyon Sadetsky wrote:
>>> We can replace old constants by the new one in the whole jdk,
but I
>>> updated only the code in InputEven
On 17.10.16 19:01, Semyon Sadetsky wrote:
How it could be safe? both are a different constants which should be
used in pair with different methods?
Then why do you add in java doc for those constants:
@deprecated It is recommended that *_DOWN_MASK be used instead
This recommendation was there
On 10/17/2016 7:35 PM, Sergey Bylokhov wrote:
On 17.10.16 19:01, Semyon Sadetsky wrote:
How it could be safe? both are a different constants which should be
used in pair with different methods?
Then why do you add in java doc for those constants:
@deprecated It is recommended that *_DOWN_MASK
On 17.10.16 21:14, Semyon Sadetsky wrote:
Then this explanation should be added to the javadoc deprecation note
because currently it states that those constants can be replaced with
the new ones. But actually they are related to different APIs and cannot
simply substitute each other.
It can be
On 10/17/2016 9:23 PM, Sergey Bylokhov wrote:
On 17.10.16 21:14, Semyon Sadetsky wrote:
Then this explanation should be added to the javadoc deprecation note
because currently it states that those constants can be replaced with
the new ones. But actually they are related to different APIs and
On 17.10.16 21:47, Semyon Sadetsky wrote:
It can be replaced if it will be used in pair with getModifiersEx().
The old getModifiers() is also deprecated. And javadoc for
getModifiersEx() describes what and how constants should be used.
Can you add link to getModifiersEx() to all those constants'
Hi,
First note that any of the alternatives here require an approved CCC
before pushing.
As I wrote in the bug the fields in JRootPane are not used. Making it a
public supertype
is no more useful than just deleting it. This like hiding the peers
which was a much
bigger change so please just
17 matches
Mail list logo
