Re: RFR: 8319197: Exclude hb-subset and hb-style from compilation

2023-11-01 Thread Alexey Ivanov
On Tue, 31 Oct 2023 21:32:26 GMT, Daniel Jeliński wrote: > hb-subset and hb-style APIs are not used and not exported by libfontmanger. > We can cut the compilation time by not compiling the unused files. > > The added exclusions reduce the build time by ~1 minute (~8%) on my machine. > This is

Re: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v3]

2023-11-07 Thread Alexey Ivanov
On Thu, 2 Nov 2023 14:01:20 GMT, xpbob wrote: >> Build failure with GCC8.3.1 >> >> === Output from failing command(s) repeated here === >> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o: >> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: >>

Re: RFR: 8324347: Enable "maybe-uninitialized" warning for FreeType 2.13.1

2024-01-25 Thread Alexey Ivanov
On Tue, 23 Jan 2024 00:58:27 GMT, Sergey Bylokhov wrote: > The next bug in freetype was fixed upstream and fix already merged to OpenJDK: > https://gitlab.freedesktop.org/freetype/freetype/-/issues/1245 > So now we can revert the workaround in the JDK: > https://bugs.openjdk.org/browse/JDK-831357

Re: RFR: 8295554: Move the "sizecalc.h" to the correct location

2022-10-24 Thread Alexey Ivanov
On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov wrote: > The "sizecalc.h" file is moved out from java.desktop/share/native/include, > the files in that folder appear in the jdk bundle after installation like the > "jawt.h". Marked as reviewed by aivanov (Reviewer). - PR: https:

Re: RFR: 8295554: Move the "sizecalc.h" to the correct location

2022-10-25 Thread Alexey Ivanov
On Mon, 24 Oct 2022 20:50:19 GMT, Magnus Ihse Bursie wrote: >> The "sizecalc.h" file is moved out from java.desktop/share/native/include, >> the files in that folder appear in the jdk bundle after installation like >> the "jawt.h". > > Thank you for waiting while we sorted out the details. This

Re: RFR: 8295729: Add jcheck whitespace checking for properties files [v3]

2022-10-29 Thread Alexey Ivanov
On Mon, 24 Oct 2022 19:29:41 GMT, Andy Goryachev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Revert "Remove check for .properties from jcheck" >> >>This reverts commit c91fdaa19dc06351598bd1c061

Re: RFR: 8295729: Add jcheck whitespace checking for properties files [v3]

2022-10-29 Thread Alexey Ivanov
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same >> whitespace checks as all other source code, so we don't get spurious >> trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increas

Re: RFR: 8200192: Verify exported symbols in java.desktop

2022-12-21 Thread Alexey Ivanov
On Tue, 20 Dec 2022 18:59:18 GMT, Daniel Jeliński wrote: > Did not verify the other issues reported in the linked JBS ticket. Then I suggest filing a new bug to track additional issues raised in [JDK-8200192](https://bugs.openjdk.org/browse/JDK-8200192) and editing the description and the subj

Re: RFR: 8299260: Libawt should only export explicitly requested symbols

2022-12-22 Thread Alexey Ivanov
On Thu, 22 Dec 2022 09:17:11 GMT, Daniel Jeliński wrote: > Thanks for the suggestion! I'll create a new bug for this fix instead, and > leave a comment on the existing one. Thank you! This way it's clearer. What about libfreetype? You also modify its settings. _libawt and libfreetype should e

Re: RFR: 8299260: libawt and libfreetype should export only explicitly requested symbols

2022-12-22 Thread Alexey Ivanov
On Tue, 20 Dec 2022 18:59:18 GMT, Daniel Jeliński wrote: > Please review this patch that removes unnecessary exports from libawt and > libfreetype. > > Verified that: > - mach5 client libs tests pass > - both release and debug builds finish successfully The number of exported symbols from `lib

Re: RFR: 8303130: Document required Accessibility permissions on macOS

2023-02-27 Thread Alexey Ivanov
On Mon, 27 Feb 2023 15:54:28 GMT, Dmitry Markov wrote: > Added the section devoted to client UI test which use Robot API doc/testing.md line 616: > 614: system key shortcuts for various platforms are provided below. > 615: > 616: # MacOS Suggestion: # macOS Shall we spell _macOS_ wi

Re: RFR: 8303130: Document required Accessibility permissions on macOS

2023-02-27 Thread Alexey Ivanov
On Mon, 27 Feb 2023 20:54:08 GMT, Sergey Bylokhov wrote: >> Added the section devoted to client UI test which use Robot API > > doc/testing.html line 621: > >> 619: the following apps are allowed to control your computer: >> 620: Java and Terminal. If the tests are run from >> 621: an IDE, the I

Re: RFR: 8303130: Document required Accessibility permissions on macOS [v3]

2023-02-28 Thread Alexey Ivanov
On Tue, 28 Feb 2023 14:17:11 GMT, Dmitry Markov wrote: >> Added the section devoted to client UI test which use Robot API > > Dmitry Markov has updated the pull request incrementally with one additional > commit since the last revision: > > Fix typo Changes requested by aivanov (Reviewer).

Re: RFR: 8303130: Document required Accessibility permissions on macOS [v4]

2023-02-28 Thread Alexey Ivanov
On Tue, 28 Feb 2023 17:03:01 GMT, Dmitry Markov wrote: >> Added the section devoted to client UI test which use Robot API > > Dmitry Markov has updated the pull request incrementally with one additional > commit since the last revision: > > Fix link Marked as reviewed by aivanov (Reviewer).

Re: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments

2023-03-03 Thread Alexey Ivanov
On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo wrote: > Please review this superficial documentation cleanup that was triggered by > unrelated analysis of doc comments in JDK API. > > The only effect that this multi-area PR has on the JDK API Documentation > (i.e. the observable effect on the ge

Re: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments

2023-03-03 Thread Alexey Ivanov
On Fri, 3 Mar 2023 10:09:27 GMT, Claes Redestad wrote: > Yes, iff means if-and-only-if and is used for extra precision in formal > logic, mathematics. I've never come across it before. With your explanations, it makes perfect sense. - PR: https://git.openjdk.org/jdk/pull/12826

Re: RFR: 8299592: Fix and reenable warnings in java.desktop native code compilation [v3]

2023-04-12 Thread Alexey Ivanov
On Wed, 12 Apr 2023 17:07:40 GMT, Daniel Jeliński wrote: >> Please review this patch that fixes and re-enables a few warnings in libawt >> compilation. >> >> Verified that debug and release builds finish successfully on Win, Mac and >> Linux. Also verified that client libs tests still pass. >

Re: RFR: 8299592: Fix and reenable warnings in java.desktop native code compilation [v4]

2023-04-13 Thread Alexey Ivanov
On Thu, 13 Apr 2023 07:13:39 GMT, Daniel Jeliński wrote: >> Please review this patch that fixes and re-enables a few warnings in libawt >> compilation. >> >> Verified that debug and release builds finish successfully on Win, Mac and >> Linux. Also verified that client libs tests still pass. >

Re: RFR: 8311247: Some cpp files are compiled with -std:c11 flag

2023-07-03 Thread Alexey Ivanov
On Mon, 3 Jul 2023 17:15:17 GMT, Daniel Jeliński wrote: > Please review this patch that configures C++ arguments on build jobs that > involve compiling CPP files. As a result of this change, CPP files are > compiled with `-std:c++14` command line argument instead of `-std:c11`, which > is used

Re: RFR: 8311247: Some cpp files are compiled with -std:c11 flag

2023-07-04 Thread Alexey Ivanov
On Mon, 3 Jul 2023 17:15:17 GMT, Daniel Jeliński wrote: > Please review this patch that configures C++ arguments on build jobs that > involve compiling CPP files. As a result of this change, CPP files are > compiled with `-std:c++14` command line argument instead of `-std:c11`, which > is used

Re: RFR: 8311247: Some cpp files are compiled with -std:c11 flag

2023-07-04 Thread Alexey Ivanov
On Tue, 4 Jul 2023 04:53:57 GMT, Daniel Jeliński wrote: >> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 135: >> >>> 133: OPTIMIZATION := HIGHEST, \ >>> 134: CFLAGS := $(CFLAGS_JDKLIB) $(LIBAWT_CFLAGS), \ >>> 135: CXXFLAGS := $(CXXFLAGS_JDKLIB) $(LIBAWT_CFLAGS), \ >> >> `LIB

Re: RFR: 8267174: Many test files have the wrong Copyright header

2023-09-06 Thread Alexey Ivanov
On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect > copyright header, which includes the "classpath" exception text. This patch > removes that text from all test files that I could find it in. I did this > using a

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-10-24 Thread Alexey Ivanov
On Thu, 24 Oct 2024 18:09:04 GMT, Harshitha Onkar wrote: >> src/java.desktop/share/classes/java/awt/Desktop.java line 713: >> >>> 711: * {@code Info.plist}. >>> 712: * >>> 713: * @param printFileHandler handler >> >> Suggestion: >> >> * @param printFileHandler handler >>

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-25 Thread Alexey Ivanov
On Wed, 23 Oct 2024 02:56:30 GMT, Prasanta Sadhukhan wrote: >> Agreed. This is not a "clean up / update tests" task. >> If it is a change on some lines of code that are updated by the SM changes, >> then that's fair game, but otherwise only the SM behaviour is part of this >> task. >> Anything

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-10-24 Thread Alexey Ivanov
On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6]

2024-11-01 Thread Alexey Ivanov
On Tue, 29 Oct 2024 12:56:25 GMT, Sean Mullan wrote: >> test/jdk/javax/xml/crypto/dsig/keyinfo/KeyInfo/Marshal.java line 30: >> >>> 28: * @modules java.xml.crypto/org.jcp.xml.dsig.internal.dom >>> 29: * @compile -XDignore.symbol.file Marshal.java >>> 30: * @run main/othervm/java.security.poli

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-11-01 Thread Alexey Ivanov
On Mon, 28 Oct 2024 14:35:57 GMT, Sean Mullan wrote: >> That and possibly rename the test because now it does not have anything to >> do with the SecurityException. Now we only check that providing an empty >> file causes the InvalidMidiDataException so EmptySoundBankTest or something >> to th

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-11-01 Thread Alexey Ivanov
On Thu, 24 Oct 2024 20:57:50 GMT, Sean Mullan wrote: >> @honkar-jdk I'm inclined to leave it as because it's not the only method >> which doesn't have a blank line between `@param` and `@throw` in this file. >> >> If it's worth taking care of, we may submit another bug to address it later. > >

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-11-01 Thread Alexey Ivanov
On Mon, 28 Oct 2024 14:08:46 GMT, Sean Mullan wrote: >> src/java.desktop/share/classes/java/awt/Font.java line 1612: >> >>> 1610: * obtained. The {@code String} value of this property is then >>> 1611: * interpreted as a {@code Font} object according to the >>> 1612: * specificat

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-11-01 Thread Alexey Ivanov
On Mon, 28 Oct 2024 18:07:26 GMT, Harshitha Onkar wrote: >> I'd not looked at this test before but when I do the thing I noticed is that >> createPrivateValue is no longer used. >> But I don't see a problem with keeping the rest of the test. > > Test updated in sandbox - > https://github.com/op

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6]

2024-11-01 Thread Alexey Ivanov
On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6]

2024-11-01 Thread Alexey Ivanov
On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-10-25 Thread Alexey Ivanov
On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-10-25 Thread Alexey Ivanov
On Fri, 25 Oct 2024 15:12:00 GMT, Alexey Ivanov wrote: >> Sean Mullan has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 150 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486&

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-10-25 Thread Alexey Ivanov
On Fri, 25 Oct 2024 15:29:40 GMT, Alexey Ivanov wrote: >> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 1: >> >>> 1: /* >> >> Again, I'm unsure this test has a value after the security manager is >> removed. All it ver

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-11-11 Thread Alexey Ivanov
On Fri, 8 Nov 2024 21:01:57 GMT, Phil Race wrote: >>> I'd not looked at this test before but when I do the thing I noticed is >>> that createPrivateValue is no longer used. But I don't see a problem with >>> keeping the rest of the test. >> >> @prrace Do I understand correctly that _“`createPr

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v9]

2024-11-08 Thread Alexey Ivanov
On Tue, 29 Oct 2024 17:06:08 GMT, Harshitha Onkar wrote: >> src/java.desktop/share/classes/java/awt/MouseInfo.java line 68: >> >>> 66: * @throws SecurityException if a security manager exists and its >>> 67: *{@code checkPermission} method doesn't allow the >>> operation >

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-10-24 Thread Alexey Ivanov
On Thu, 24 Oct 2024 17:58:55 GMT, Harshitha Onkar wrote: > It was missed when `-Djava.security.manager=allow` was removed. It wasn't intentional then, was it? > Out of curiosity: does it have any impact on the performance of CI testing if > tests are run in /othervm mode when it is not needed?

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-10-25 Thread Alexey Ivanov
On Thu, 24 Oct 2024 21:06:23 GMT, Harshitha Onkar wrote: >>> It was missed when `-Djava.security.manager=allow` was removed. >> >> It wasn't intentional then, was it? >> >>> Out of curiosity: does it have any impact on the performance of CI testing >>> if tests are run in /othervm mode when it

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11]

2024-11-12 Thread Alexey Ivanov
On Tue, 12 Nov 2024 15:02:12 GMT, Sean Mullan wrote: >> I can add it back if it is more convenient and readable to have the `@see` >> tag. > > This can be taken care of later after integration. Agreed! - PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838282

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11]

2024-11-12 Thread Alexey Ivanov
On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-10-25 Thread Alexey Ivanov
On Fri, 25 Oct 2024 17:30:56 GMT, Harshitha Onkar wrote: >> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 41: >> >>> 39: * @bug 6694823 >>> 40: * @summary Checks that popup menu cannot be partially hidden >>> 41: * by the task bar. >> >> I believe this test is irrelev

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-10-25 Thread Alexey Ivanov
On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-10-25 Thread Alexey Ivanov
On Fri, 25 Oct 2024 18:30:23 GMT, Harshitha Onkar wrote: >> The updated test `bug6694823.java` works correctly on Windows and displays >> its popup over the Windows taskbar — it is expected. >> >> The popup had to be moved if the security manager didn't allow to call >> `setAlwaysOnTop(true)`.

Re: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9

2025-05-13 Thread Alexey Ivanov
On Tue, 13 May 2025 18:30:01 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring >> return value of function >> declared with 'warn_unused_result' attribute [-W

Re: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9

2025-05-13 Thread Alexey Ivanov
On Tue, 13 May 2025 18:19:37 GMT, Harshitha Onkar wrote: > The following line results in unused-result warning on linux/clang. > > > /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring > return value of function > declared with 'warn_unused_result' attribute [-Werror,

Re: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2]

2025-05-20 Thread Alexey Ivanov
On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring >> return value of function >> declared with 'warn_unused_result' attribute [-W

Re: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2]

2025-05-22 Thread Alexey Ivanov
On Thu, 22 May 2025 06:28:07 GMT, SendaoYan wrote: > Duplicated to https://bugs.openjdk.org/browse/JDK-8346103 So, [JDK-8346103](https://bugs.openjdk.org/browse/JDK-8346103) is closed as duplicate of [JDK-8346436](https://bugs.openjdk.org/browse/JDK-8346436). The latter has a closed code revie

Re: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v3]

2025-05-23 Thread Alexey Ivanov
On Fri, 23 May 2025 16:36:23 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring >> return value of function >> declared with 'warn_unused_result' attribute [-W

Re: RFR: 8364177: JDK fails to build due to undefined symbol in libpng on LoongArch64

2025-07-30 Thread Alexey Ivanov
On Mon, 28 Jul 2025 09:25:34 GMT, Ao Qi wrote: > After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the > following code was added. > > > #ifndef PNG_LOONGARCH_LSX_OPT > # if defined(__loongarch_sx) > # define PNG_LOONGARCH_LSX_OPT 1 > # else > # define PNG_LOONGARCH_LSX_OPT 0 >