Hi Alok,
This change should be discussed on swing-dev mailing list because you
modify behavior of javax.swing.JFileChooser, and on core-libs-dev
because you also modify java.io.File.
I agree with Alan, using the new API appears to be a better alternative
than changing java.io.File.
Any volunteers from core-libs and/or hotspot?
Thank you,
Alexey
On 02/05/2018 13:02, Magnus Ihse Bursie wrote:
Looks good to me, FWIW.
/Magnus
2 maj 2018 kl. 13:52 skrev Alexey Ivanov <alexey.iva...@oracle.com>:
Hi,
Could you please review the following fix for jdk11?
bug:
regards
Christoph
-Original Message-
From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf Of
Alexey Ivanov
Sent: Mittwoch, 9. Mai 2018 16:35
To: core-libs <core-libs-dev@openjdk.java.net>; hotspot-dev
Cc: build-dev <build-...@openjdk.java.net>
Subject:
Hi,
Could you please review the following fix for jdk11?
bug: https://bugs.openjdk.java.net/browse/JDK-8202544
webrev: http://cr.openjdk.java.net/~aivanov/8202544/jdk11/webrev.0/
The following exported functions in libzip are not used:
ZIP_GetEntry, ZIP_FreeEntry, ZIP_Lock, ZIP_Unlock,
I guess we also need to get an approval from core-libs (cc'd) as libzip
and libjimage are modified.
Regards,
Alexey
On 11/04/2018 10:56, Alexey Ivanov wrote:
The change looks good to me.
On 11/04/2018 10:20, Baesken, Matthias wrote:
Was main() exported via map files?
Seems main
Hi Matthias,
On 12/04/2018 11:12, Alexey Ivanov wrote:
Hi Matthias,
On 12/04/2018 08:49, Baesken, Matthias wrote:
Hi, could someone please sponsor the change now ?
According to OpenJDK Census page [1], you have committer rights to JDK
project.
And could someone please check what
Hi Alan , this is the up to date webrev .
However we want to add Alexey Ivanov as additional author .
As I read it, this changes the calling convention of these functions on
32-bit Windows but it will have no impact on 64-bit Windows (as
__stdcall is ignored) or other platforms, is that cor
, Matthias
-Original Message-
From: Alexey Ivanov [mailto:alexey.iva...@oracle.com]
Sent: Donnerstag, 12. April 2018 23:53
To: Phil Race <philip.r...@oracle.com>; Baesken, Matthias
<matthias.baes...@sap.com>; Alan Bateman <alan.bate...@oracle.com>;
Magnus Ihse Bursi
://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017#FormatC
[2] https://docs.microsoft.com/en-ie/cpp/cpp/stdcall?view=vs-2017
On 12/12/2018 11:19, Magnus Ihse Bursie wrote:
On 2018-12-11 18:16, Alexey Ivanov wrote:
Hi Simon,
Thank you for your comments.
The updated
Forgot to add the link:
On 12/12/2018 16:10, Alexey Ivanov wrote:
Ali has scanned the code base, he says, “couldn’t find (hopefully tbh)
other occurrences of such mismatches.”
http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024358.html
On 10/12/2018 10:45, Magnus Ihse Bursie
On 12/12/2018 16:52, Magnus Ihse Bursie wrote:
On 2018-12-12 16:34, Alexey Ivanov wrote:
On 12/12/2018 12:58, Magnus Ihse Bursie wrote:
On 2018-12-12 12:35, Alan Bateman wrote:
On 12/12/2018 11:14, Magnus Ihse Bursie wrote:
:
I searched the code for "jdwpTransport_On&qu
On 12/12/2018 12:58, Magnus Ihse Bursie wrote:
On 2018-12-12 12:35, Alan Bateman wrote:
On 12/12/2018 11:14, Magnus Ihse Bursie wrote:
:
I searched the code for "jdwpTransport_On" to see of there was any
corresponding OnUnload function (or other), but could not find any.
That's right,
Ali has scanned the code base, he says, “couldn’t find (hopefully tbh)
other occurrences of such mismatches.”
On 10/12/2018 10:45, Magnus Ihse Bursie wrote:
It might be worthwhile to scan the entire code base for JNICALL and
verify that we have no more mismatches. In general, JNICALL should be
Hi Simon,
I'd like to clarify some points…
Please see my comments inline:
On 11/12/2018 17:16, Alexey Ivanov wrote:
Hi Simon,
Thank you for your comments.
The updated webrev:
http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/
Indeed, it looks much cleaner.
Regards,
Alexey
On 11/12
Thank you, Ali, for doing this!
On 10/12/2018 21:13, Ali İnce wrote:
Hi Alexey,
I’ve searched for |GetProcAddress| usages across source code and
couldn’t find (hopefully tbh) other occurrences of such mismatches.
Regards,
Ali
d"}
#define AGENT_ONATTACH_SYMBOLS {"_Agent_OnAttach@12", “Agent_OnAttach”}
Bob.
On Dec 11, 2018, at 11:43 AM, Simon Tooke wrote:
On 2018-12-11 10:05 a.m., Alexey Ivanov wrote:
Hi everyone,
I came up with the following patch:
http://cr.openjdk.java.net/~aivanov/8214122/web
Hi everyone,
I came up with the following patch:
http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/
It specifically addresses the problem in JDK-8214122 where on 32 bit
Windows jdwpTransport_OnLoad can exported with its plain and
__stdcall-mangled name. I used conditional compilation so
Hi Simon,
Thank you for your comments.
The updated webrev:
http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/
Indeed, it looks much cleaner.
Regards,
Alexey
On 11/12/2018 16:43, Simon Tooke wrote:
On 2018-12-11 10:05 a.m., Alexey Ivanov wrote:
Hi everyone,
I came up with the following
, at 12:12, Alexey Ivanov wrote:
Hi Ali,
The fix looks good to me provided it resolves your problem.
I am not a reviewer so you'll have to get OK from reviewers, likely from
build-dev and from core-libs.
Have you submitted the issue in JBS?
You have to sign OCA to be able to contribute
nion from serviceability-dev if there is any problem with changing
the signature. I'd preferably have that.
If no one knows, I'd say, change it, and see if we still pass the
relevant tests, and if so, ship it.
/Magnus
22 nov. 2018 kl. 18:04 skrev Alexey Ivanov <mailto:alexey.iva...@oracle.com>
Hi,
Could you please review the following fix for jdk12?
bug: https://bugs.openjdk.java.net/browse/JDK-8215123
webrev: http://cr.openjdk.java.net/~aivanov/8215123/webrev.00/
The problem is that calling convention was changed on ZIP_InflateFully
function in zip.dll. Yet it hasn't been updated
e size
of function parameters. Could it be the reason why most DLLs export
__stdcall functions undecorated?
Regards,
Alexey
/Magnus
-Simon Tooke
On 12/7/2018 2:09 PM, Alexey Ivanov wrote:
Hi Andrew,
Sorry for my belated reply.
Yes, it's also an option… however, this solution seems to be
, jdwpTransportCallback* cbTablePtr,
jint version, jdwpTransportEnv** env)
{
On 16 Nov 2018, at 23:03, Alexey Ivanov wrote:
Hi Ali,
It's exactly what I referred to.
Yes, it does change the calling convention.
Yet it's not a (big) problem because both parties will use
Any volunteers from core-libs and serviceability to review?
Regards,
Alexey
On 12/12/2018 16:43, Magnus Ihse Bursie wrote:
On 2018-12-12 17:38, Alexey Ivanov wrote:
Hi all,
I have updated the summary of JDK-8214122 and the subject accordingly.
Could you please review the following fix
Thank you, Daniel, for your quick review.
On 19/12/2018 15:05, Daniel D. Daugherty wrote:
On 12/19/18 9:23 AM, Alexey Ivanov wrote:
Any volunteers from core-libs and serviceability to review?
How about former Serviceability Team members? :-) Alan B. and I
both used
-
From: David Holmes
Sent: Mittwoch, 30. Oktober 2019 05:29
To: Alexey Ivanov ; core-libs ; hotspot-runtime ; Langer, Christoph
Cc: Claes Redestad
Subject: Re: RFR JDK-8232724: Remove indirection with calling
JNU_NewStringPlatform
LGTM.
Thanks,
David
On 30/10/2019 1:04 am, Alexey Ivanov wrote
Hello,
Please review the following fix which it brings back NewStringPlatform
alias for JNU_NewStringPlatform. Without it, 32 bit Windows build of
Java does not work.
bug: https://bugs.openjdk.java.net/browse/JDK-8232624
webrev: http://cr.openjdk.java.net/~aivanov/8232624/webrev.00/
--
Hi David,
On 20/10/2019 23:59, David Holmes wrote:
Hi Alexey,
On 21/10/2019 2:20 am, Alexey Ivanov wrote:
Hello,
Please review the following fix which it brings back
NewStringPlatform alias for JNU_NewStringPlatform. Without it, 32 bit
Windows build of Java does not work.
bug: https
Hi David,
On 21/10/2019 02:19, David Holmes wrote:
Hi Alexey,
On 21/10/2019 9:37 am, Alexey Ivanov wrote:
Hi David,
On 20/10/2019 23:59, David Holmes wrote:
Hi Alexey,
On 21/10/2019 2:20 am, Alexey Ivanov wrote:
Hello,
Please review the following fix which it brings back
I have filed
https://bugs.openjdk.java.net/browse/JDK-8232724
"Remove indirection with calling JNU_NewStringPlatform"
On 21/10/2019 13:49, Claes Redestad wrote:
On 2019-10-21 14:14, Alexey Ivanov wrote:
Probably, Claes thought "NewStringPlatform" wasn't
Hi David,
On 21/10/2019 14:00, David Holmes wrote:
On 21/10/2019 10:14 pm, Alexey Ivanov wrote:
Hi David,
On 21/10/2019 02:19, David Holmes wrote:
So what would happen if we drop the JNICALL from JNU_NewStringPLatform?
Yes, it will be found by its undecorated name too.
But I'd rather
Hi David, Claes, Alan,
Thank you for your reviews!
Just to confirm: Is the patch
http://cr.openjdk.java.net/~aivanov/8232624/webrev.00/
approved?
The cleanup to avoid indirection for calling JNU_NewStringPLatform will
be addressed in the follow-up issue
Hi David, Christoph,
Thank you for your reviews.
On 29/10/2019 07:49, David Holmes wrote:
Shall I remove one of them? The one in jvm.h because it's unused?
Yes please remove the unused one in jvm.h.
The updated webrev:
http://cr.openjdk.java.net/~aivanov/8232724/webrev.01/
--
Regards,
Hello,
Please review the following fix which removes indirection in calling
JNU_NewStringPlatform via NewStringPlatform.
bug: https://bugs.openjdk.java.net/browse/JDK-8232724
webrev: http://cr.openjdk.java.net/~aivanov/8232724/webrev.00/
It is a follow-up fix to JDK-8232624 and JDK-8231355.
On Tue, 7 Dec 2021 08:16:08 GMT, Сергей Цыпанов wrote:
>> src/java.desktop/share/classes/java/awt/geom/Line2D.java line 115:
>>
>>> 113: */
>>> 114: public double getX1() {
>>> 115: return x1;
>>
>> What do these changes have to do with the subject of the PR ?
>
>
On Tue, 7 Dec 2021 08:28:47 GMT, Сергей Цыпанов wrote:
>> Instead of something like
>>
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>>
>> we can use `return Long.compare(x, y);`
>>
>> All replacements are done with IDE.
>
> Сергей Цыпанов has updated the pull request
On Tue, 8 Mar 2022 15:54:45 GMT, Zhengyu Gu wrote:
>> Please review this small patch that fixes a potential memory leak that
>> exception return fails to release allocated `cacheDirs`
>>
>> Test:
>>
>> - [x] jdk_desktop on Linux x86_64
>
> Zhengyu Gu has updated the pull request incrementally
On Tue, 8 Mar 2022 12:20:38 GMT, David Holmes wrote:
>> src/java.desktop/unix/native/common/awt/fontpath.c line 940:
>>
>>> 938: JNU_CHECK_EXCEPTION_AND_CLEANUP(env,
>>> (*FcStrListDone)(cacheDirs));
>>> 939:
>>> 940: (*env)->SetObjectArrayElement(env,
On Tue, 8 Mar 2022 20:12:29 GMT, Sergey Bylokhov wrote:
>> Can `SetObjectElementArray` raise an exception?
>> The index is within the array length and we store a string. I assume
>> `cacheDirArray` is a string array.
>
>> ??? You want to check and cleanup if NewStringUTF fails. You only want
On Tue, 8 Mar 2022 21:02:04 GMT, Zhengyu Gu wrote:
> I think `NewStringUTF()` can throw OOM and also return `NULL`, just which one
> you pick.
Yes.
But we're discussing whether a check for exception is necessary after
`(*env)->SetObjectArrayElement`.
-
PR:
On Tue, 8 Mar 2022 15:54:45 GMT, Zhengyu Gu wrote:
>> Please review this small patch that fixes a potential memory leak that
>> exception return fails to release allocated `cacheDirs`
>>
>> Test:
>>
>> - [x] jdk_desktop on Linux x86_64
>
> Zhengyu Gu has updated the pull request incrementally
On Tue, 8 Mar 2022 21:12:33 GMT, Zhengyu Gu wrote:
>>> I think `NewStringUTF()` can throw OOM and also return `NULL`, just which
>>> one you pick.
>>
>> Yes.
>>
>> But we're discussing whether a check for exception is necessary after
>> `(*env)->SetObjectArrayElement`.
>
>
On Tue, 8 Mar 2022 15:54:45 GMT, Zhengyu Gu wrote:
>> Please review this small patch that fixes a potential memory leak that
>> exception return fails to release allocated `cacheDirs`
>>
>> Test:
>>
>> - [x] jdk_desktop on Linux x86_64
>
> Zhengyu Gu has updated the pull request incrementally
On Tue, 8 Mar 2022 20:47:45 GMT, Alexey Ivanov wrote:
> You're right. The old icon handles in `hOldIcon` and `hOldIconSm` will be
> leaked here if `CreateIconFromRaster` throws an exception.
I've submitted [JDK-8282862](https://bugs.openjdk.java.net/browse/JDK-8282862):
AwtWindow::SetIc
estion
>
> Co-authored-by: Alexey Ivanov
> <70774172+aivanov-...@users.noreply.github.com>
Marked as reviewed by aivanov (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7879
On Wed, 23 Mar 2022 07:31:23 GMT, Andrey Turbanov wrote:
>> Fix repeated typo `exeption`
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8283426: Fix 'exeption' typo
> fix more typos, found by Sean Coffey
Marked as
On Wed, 23 Mar 2022 19:41:58 GMT, Andrey Turbanov wrote:
>> Fix repeated typo `exeption`
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8283426: Fix 'exeption' typo
>
> Co-authored-by:
On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote:
> Fix repeated typo `exeption`
Marked as reviewed by aivanov (Reviewer).
src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java
line 201:
> 199: /*
> 200: * The method could not be implemented due to
On Wed, 19 Jan 2022 09:19:00 GMT, Matthias Baesken wrote:
> Very small change fixing wrong strings "Falied" in a couple of tests.
Marked as reviewed by aivanov (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7142
On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote:
> Use presumed syntax that will be introduced by JDK-8280488.
Marked as reviewed by aivanov (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7189
On Wed, 6 Apr 2022 12:07:30 GMT, Daniel Jeliński wrote:
> This patch adds missing `r` in `string`s
src/java.desktop/share/native/liblcms/cmstypes.c line 3668:
> 3666: // Auxiliary, read an string specified as count + string
> 3667: static
> 3668: cmsBool ReadCountAndString(struct
On Wed, 6 Apr 2022 16:47:17 GMT, Daniel Jeliński wrote:
>> This patch adds missing `r` in `string`s
>
> Daniel Jeliński has updated the pull request incrementally with two
> additional commits since the last revision:
>
> - revert xalan changes
> - revert icu changes
The changes look fine
Replaces usages of articles that follow each other in all combinations: a/the,
an?/an?, the/the…
Also, I fixed a couple of spelling mistakes.
-
Commit messages:
- 8284191: Replace usages of 'the an' in hotspot and java.base
- 8284191: Replace usages of 'the an' in hotspot and
Replaces usages of articles that follow each other in all combinations: a/the,
an?/an?, the/the…
I tried to avoid changing external libraries, there are quite a few such typos.
Let me know if I should revert any files.
-
Commit messages:
- 8284213: Replace usages of 'the a' in xml
Replaces usages of articles that follow each other in all combinations: a/the,
an?/an?, the/the…
It's the last issue in the series, and it still touches different areas of the
code.
-
Commit messages:
- 8284209: Replace remaining usages of 'the a' in source code
- 8284209:
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> Also, I fixed a couple of spelling mistakes.
Alexey Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
Update copyr
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> It's the last issue in the series, and it still touches different areas of
> the code.
Alexey Ivanov has updated the pull request with a new target base due to a
me
On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote:
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> It's the last issue in the series, and it still touches different areas of
> the code.
This pull request has now
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> It's the last issue in the series, and it still touches different areas of
> the code.
Alexey Ivanov has updated the pull request incrementally with one additional
commit
On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote:
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> Also, I fixed a couple of spelling mistakes.
This pull request has now been integrated.
Changeset: e0d361ce
Author:A
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> Also, I fixed a couple of spelling mistakes.
Alexey Ivanov has updated the pull request incrementally with seven additional
commits since the last revision:
- ...set t
On Thu, 19 May 2022 09:38:40 GMT, Kevin Walls wrote:
>> Alexey Ivanov has updated the pull request incrementally with seven
>> additional commits since the last revision:
>>
>> - ...set to the values...
>> - ...will result in a Zip64 Extra (EXT) header
&g
On Thu, 19 May 2022 08:47:47 GMT, Kevin Walls wrote:
>> Alexey Ivanov has updated the pull request incrementally with seven
>> additional commits since the last revision:
>>
>> - ...set to the values...
>> - ...will result in a Zip64 Extra (EXT) header
&g
On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov wrote:
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> I tried to avoid changing external libraries, there are quite a few such
> typos.
> Let me know if I shoul
64 matches
Mail list logo
