On Thu, 12 May 2022 00:26:41 GMT, Yasumasa Suenaga wrote:
>> I don't understand what the actual warning is getting at .. can anyone
>> explain it ?
>>
>> FWIW the code is still the same in upstream harfbuzz
>> https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc
>
> I've pasted a part
On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga wrote:
>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1
>> on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should
>> separate them by area.
>>
>> * -Wstringop-overflow
>>
On Thu, 12 May 2022 01:27:30 GMT, Yasumasa Suenaga wrote:
>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1
>> on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should
>> separate them by area.
>>
>> * -Wstringop-overflow
>>
On Wed, 11 May 2022 13:35:00 GMT, Kim Barrett wrote:
>> Yasumasa Suenaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Avoid pragma error in before GCC 12
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462:
>
>> 460:
On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote:
>> Currently we set _WIN32_WINNT at various places in the codebase; this is
>> used to target a minimum Windows version we want to support. See also for
>> more detailled information :
>>
On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote:
> Please review this patch adding new lint option, **lossy-conversions**, to
> javac to warn about type casts in compound assignments with possible lossy
> conversions.
>
> The new lint warning is shown if the type of the right-hand operand
On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken wrote:
> Currently we set _WIN32_WINNT at various places in the codebase; this is used
> to target a minimum Windows version we want to support. See also for more
> detailled information :
>
On Wed, 23 Mar 2022 23:38:52 GMT, Sergey Bylokhov wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update comment to show we don't care about these files.
>
> Do we really want to change the product
On Wed, 23 Mar 2022 23:13:04 GMT, Magnus Ihse Bursie wrote:
>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 487:
>>
>>> 485: LIBFONTMANAGER_OPTIMIZATION := HIGHEST
>>> 486:
>>> 487: ifneq ($(filter $(TOOLCHAIN_TYPE), gcc clang), )
>>
>> Can we have a note here that the de-opt is
On Wed, 23 Mar 2022 23:17:38 GMT, Magnus Ihse Bursie wrote:
>> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade
>> HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my
>> reference linux machine. This was one of the four culprits that caused a
>> 25-30%
On Wed, 23 Mar 2022 21:13:30 GMT, Magnus Ihse Bursie wrote:
>> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade
>> HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my
>> reference linux machine. This was one of the four culprits that caused a
>> 25-30%
On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie wrote:
> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade
> HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference
> linux machine. This was one of the four culprits that caused a 25-30% build
On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie wrote:
> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade
> HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference
> linux machine. This was one of the four culprits that caused a 25-30% build
On Tue, 22 Mar 2022 18:53:20 GMT, Phil Race wrote:
> Disable a warning from the Xcode 13.3 clang compiler when compiling libpng,
> which is used by libsplashscreen.
>
> Policy is not to change the upstream code locally unless it is also changed
> in the same way upstream.
>
Disable a warning from the Xcode 13.3 clang compiler when compiling libpng,
which is used by libsplashscreen.
Policy is not to change the upstream code locally unless it is also changed in
the same way upstream.
We could consider reporting it upstream but libpng releases are very infrequent.
On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typos
>
> This doesn't seem right to me to put x11wrappergen into share.
>
On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
Marked as reviewed by prr (Reviewer).
Looks like there's only one client source code file touched
Most of the client changes
On Fri, 3 Dec 2021 20:55:23 GMT, Sergey Bylokhov wrote:
> The "missing-explicit-ctor" check was disabled by the
> [JDK-8071961](https://bugs.openjdk.java.net/browse/JDK-8071961) and later was
> fixed by the [JDK-8250853](https://bugs.openjdk.java.net/browse/JDK-8250853).
> So we can re-enable
On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy wrote:
> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings.
> Therefore, it is now possible to enable the full doclint checks for the
> java.desktop module if the instances of warnings are suppressed. This patch
> does this; it
On Mon, 15 Nov 2021 14:00:59 GMT, Jayathirth D V wrote:
>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in
>> macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set
>> any deployment target when when we use xcrun to create .air file and this
>>
On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V wrote:
>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in
>> macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set
>> any deployment target when when we use xcrun to create .air file and this
>>
On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V wrote:
>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in
>> macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set
>> any deployment target when when we use xcrun to create .air file and this
>>
On Fri, 12 Nov 2021 03:56:57 GMT, Phil Race wrote:
>> Jayathirth D V has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use Macro for version
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line
On Thu, 11 Nov 2021 15:32:01 GMT, Jayathirth D V wrote:
>> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in
>> macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set
>> any deployment target when when we use xcrun to create .air file and this
>>
On Wed, 11 Aug 2021 17:58:04 GMT, Severin Gehwolf wrote:
> Please review this simple build fix to correct the type done in JDK-8255790.
> After the patch correct external library is added to the `libfontmanager.so`
> link command when building with `--with-harfbuzz=system`.
>
> Thoughts?
On Mon, 24 May 2021 13:53:34 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman wrote:
>> The JEP isn't PTT for 17 so there's plenty of time isn't there ?
>
> There are 827 files in this patch. Phil is right that adding SW at the class
> level is introducing technical debt but if addressing that requires
> refactoring and
On Tue, 18 May 2021 15:55:09 GMT, Phil Race wrote:
> See the bug report for lots of explanation.
> The short version (not that short) is that Swing adds a new line char to
> editable TextComponents
> It used to work because harfbuzz asked CoreText which mapped it to an
> invisi
On Tue, 18 May 2021 19:53:36 GMT, Sergey Bylokhov wrote:
>> See the bug report for lots of explanation.
>> The short version (not that short) is that Swing adds a new line char to
>> editable TextComponents
>> It used to work because harfbuzz asked CoreText which mapped it to an
>> invisible
On Thu, 20 May 2021 04:05:23 GMT, Phil Race wrote:
>> By converting JDK-8267432 to a bug, there is an extra benefit that we can
>> fix it after RDP. So I'll convert it now.
>
> That is unfortunate, but nonetheless I think required to be done.
> We have acknowledeged
On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang wrote:
>> I can make it a bug.
>>
>> I don't want to do it here is because it involves indefinite amount of
>> manual work and we will see everyone having their preferences. The more time
>> we spend on this PR the more likely there will be merge
On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang wrote:
>> I don't think it is a separate P4 enhancement (?) that someone will (maybe)
>> do next release.
>> I think it should all be taken care of as part of this proposed change.
>
> I just made it P3 (P4 was the default value), and I will target
On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang wrote:
>> That's a sad limitation of the annotation stuff then, but I don't think that
>> it is insurmountable.
>> You can define a static private method to contain this and call it from the
>> static initializer block.
>> Much better than applying
On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang wrote:
>> src/java.desktop/share/classes/java/awt/Component.java line 217:
>>
>>> 215: * @author Sami Shaio
>>> 216: */
>>> 217: @SuppressWarnings("removal")
>>
>> Why is this placed on the *entire class* ??
>> This class is 10535 lines long
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
See the bug report for lots of explanation.
The short version (not that short) is that Swing adds a new line char to
editable TextComponents
It used to work because harfbuzz asked CoreText which mapped it to an invisible
glyph
Now harfbuzz does its own processing of AAT fonts it is different.
On Thu, 6 May 2021 06:58:16 GMT, Thomas Stuefe wrote:
>> Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS
>> issue.
>>
>> I fixed the issue in the harfbuzz sources, but I am not sure of the policy
>> here. Do we modify the harfbuzz sources or leave them untouched?
On Fri, 30 Apr 2021 20:07:53 GMT, Phil Race wrote:
> Upgrade to harfbuzz 2.8
This pull request has now been integrated.
Changeset: 80323b7f
Author: Phil Race
URL:
https://git.openjdk.java.net/jdk/commit/80323b7f66541e24177d02cc668a2eb9267962b9
Stats: 13120 lines in 123 fi
On Sat, 1 May 2021 01:42:04 GMT, Sergey Bylokhov wrote:
> I assume the build using bundled lib is fine on all our platforms.
Yes.
-
PR: https://git.openjdk.java.net/jdk/pull/3826
Upgrade to harfbuzz 2.8
-
Commit messages:
- 8261169: Upgrade HarfBuzz to the latest 2.8.0
Changes: https://git.openjdk.java.net/jdk/pull/3826/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3826=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8261169
Stats: 13120
On Thu, 29 Apr 2021 19:15:52 GMT, Mikael Vidstedt wrote:
> Apple rebranded the operating system as "macOS" back in 2016. The JDK bundles
> files are still use the legacy "osx" string. They should be modernized to use
> "macos" instead.
Marked as reviewed by prr (Reviewer).
-
PR:
On Thu, 18 Mar 2021 20:54:27 GMT, Phil Race wrote:
> As per the bug report the code that was the reason for disabling warnings on
> this file was removed in November 2019
> as part of https://bugs.openjdk.java.net/browse/JDK-8220231 so we can get rid
> of the need to disa
As per the bug report the code that was the reason for disabling warnings on
this file was removed in November 2019
as part of https://bugs.openjdk.java.net/browse/JDK-8220231 so we can get rid
of the need to disable warnings.
Longer history in the bug report.
-
Commit messages:
On Sat, 13 Mar 2021 00:15:16 GMT, Phil Race wrote:
> From a build perspective this partially reverts
> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
> the harfbuzz sources separate and still supports building and running against
> a system harfbuzz w
On Tue, 16 Mar 2021 10:38:19 GMT, Alexander Zvegintsev
wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8255790: GTKL: Java 16 crashes on initialising GTKL on Manjaro Linux
>
>
- harfbuzz/hb-ucdn is gone and should not be listed as a header directory
> needed to build the bundled copy
> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502
Phil Race has updated the pull request incrementally with one additional commit
since the last revision:
On Mon, 15 Mar 2021 18:52:38 GMT, Magnus Ihse Bursie wrote:
> I was actually thinking that such a change would be simpler; more or less
> amounting to changing from LIBRARY to STATIC_LIBRARY. But if you feel that it
> is too much work, fine...
If you say so .. I have no idea what build
- harfbuzz/hb-ucdn is gone and should not be listed as a header directory
> needed to build the bundled copy
> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502
Phil Race has updated the pull request incrementally with one additional commit
since the last revision:
On Sat, 13 Mar 2021 00:15:16 GMT, Phil Race wrote:
> From a build perspective this partially reverts
> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
> the harfbuzz sources separate and still supports building and running against
> a system harfbuzz w
On Mon, 15 Mar 2021 10:46:45 GMT, Alexander Zvegintsev
wrote:
>> From a build perspective this partially reverts
>> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
>> the harfbuzz sources separate and still supports building and running
>> against a system harfbuzz
>From a build perspective this partially reverts
>https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
the harfbuzz sources separate and still supports building and running against a
system harfbuzz which is only of interest or relevance on Linux.
I ended up having to go this
On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal
On Mon, 15 Feb 2021 20:55:13 GMT, Phil Race wrote:
>> Marked as reviewed by gziemski (Committer).
>
>> > > Thanks @gerard-ziemski for taking a detailed look at this.
>> > > We do have an open bug to address this. Please refer
>> > > [JDK-8259825](htt
On Mon, 8 Mar 2021 08:06:03 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal
On Sun, 7 Mar 2021 03:18:53 GMT, Yasumasa Suenaga wrote:
> I saw C4530 with VS 2019 (16.9.0) as following (on Japanese locale):
>
> AccessBridgeDebug.cpp
> メモ: インクルード ファイル:
> d:\github-forked\jdk\src\jdk.accessibility\windows\native\common\AccessBridgeDebug.h
>
> :
>
>
On Wed, 17 Feb 2021 12:36:10 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Mon, 15 Feb 2021 20:52:09 GMT, Gerard Ziemski wrote:
>> Ajit Ghaisas has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 20 additional
>>
On Mon, 15 Feb 2021 18:30:51 GMT, Gerard Ziemski wrote:
>> Changes requested by gziemski (Committer).
>
> I took a look at https://bugs.openjdk.java.net/browse/JDK-8261408 and noticed
> a startup time regression with the Metal rendering pipeline, so I dug a bit
> and here is what I found using
On Thu, 11 Feb 2021 21:04:16 GMT, Gerard Ziemski wrote:
>> I guess you will only see this if `Metal API Validation Enabled`
>
> Which actually begs a question of whether we tested with `Metal API
> Validation Enabled` ?
I submitted https://bugs.openjdk.java.net/browse/JDK-8261620 for this bug.
On Thu, 4 Feb 2021 02:32:31 GMT, Phil Race wrote:
> remove un-needed disabling now JNF has gone ..
This pull request has now been integrated.
Changeset: 3bb6a3d2
Author: Phil Race
URL: https://git.openjdk.java.net/jdk/commit/3bb6a3d2
Stats: 8 lines in 2 files changed: 0 ins
> remove un-needed disabling now JNF has gone ..
Phil Race has updated the pull request incrementally with one additional commit
since the last revision:
Remove condition that should have been fixed as part of 8257858
-
Changes:
- all: https://git.openjdk.java.net/jdk/p
On Thu, 4 Feb 2021 11:42:48 GMT, Magnus Ihse Bursie wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove condition that should have been fixed as part of 8257858
>
> Marked as review
remove un-needed disabling now JNF has gone ..
-
Commit messages:
- 8261109: [macOS] Remove disabled warning for JNF in
make/autoconf/flags-cflags.m4
Changes: https://git.openjdk.java.net/jdk/pull/2396/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2396=00
Issue:
On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race wrote:
> This completes the desktop module JNF removal
>
> * remove -framework JavaNativeFoundation from make files
>
> * remove #import from all
> source files. If needed add import of JNIUtilities.h to get jni.h definitions
l replacement
>
> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with
> local replacement
>
> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
>
> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)
Phil Race h
On Thu, 28 Jan 2021 22:40:57 GMT, Phil Race wrote:
> This removes the JNF dependency from the jdk.hotspot.agent module.
> The macro expansions are the same as already used in the Java desktop module
> - which actually uses a macro
> still but there there are hundreds of uses.
&g
On Tue, 2 Feb 2021 20:27:17 GMT, Chris Plummer wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m
>
> src/jdk.hotspot
ptions escaping to Java
> and also to drain the auto-release pool.
> What test group would be good for verifying this change ?
Phil Race has updated the pull request incrementally with one additional commit
since the last revision:
8257988: Remove JNF dependency from libsaproc/
On Tue, 2 Feb 2021 21:26:28 GMT, Kevin Rushforth wrote:
>> The changes look good to me, but please see my comment from my review about
>> documenting `NormalizedPathNSStringFromJavaString()` API.
>
> The following commit was integrated to jdk master since you created this
> branch:
>
>
l replacement
>
> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with
> local replacement
>
> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
>
> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)
Phil Race h
On Tue, 2 Feb 2021 22:33:09 GMT, Phil Race wrote:
>> I read it and not sure that it is fine to ignore this error, why not throw
>> an exception and signal the CTextPipe_doDrawString that an error occurred
>> like InvalidPipeException or something(Sometimes we wrap other exce
On Tue, 2 Feb 2021 21:48:36 GMT, Sergey Bylokhov wrote:
>> Look a few lines further up at my reply 3 days ago Gerard about this.
>
> I read it and not sure that it is fine to ignore this error, why not throw an
> exception and signal the CTextPipe_doDrawString that an error occurred like
>
On Tue, 2 Feb 2021 22:02:14 GMT, Sergey Bylokhov wrote:
>> I ran some tests embedding JavaFX into Swing and vice versa both with and
>> without `-Djavafx.embed.singleThread=true` and I don't see any regression in
>> behavior.
>
> I am mostly worried about the usage of JNF by someone else's
On Mon, 1 Feb 2021 22:17:38 GMT, Sergey Bylokhov wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8260616: Removing remaining JNF dependencies in the java.desktop module
>
> src/java.desk
l replacement
>
> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with
> local replacement
>
> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
>
> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)
Phil Race has u
On Mon, 1 Feb 2021 11:35:22 GMT, Magnus Ihse Bursie wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8260616: Removing remaining JNF dependencies in the java.desktop modul
>
> Build
On Fri, 29 Jan 2021 17:22:49 GMT, Phil Race wrote:
>> Build changes look good.
>
>> Is it because they are not in a place that can be accessed from this file?
> Right 99% of JNF usage was the desktop module many, many files, 1300
> references .. the entire rest of the JDK
On Fri, 29 Jan 2021 22:47:52 GMT, Weijun Wang wrote:
>> This fix covers both
>>
>> - [[macOS]: Remove JNF dependency from
>> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
>> - [[macOS]: Remove JNF dependency from
>>
On Fri, 29 Jan 2021 21:47:32 GMT, Weijun Wang wrote:
>> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 619:
>>
>>> 617: (*env)->ReleaseCharArrayElements(env, passwordObj,
>>> passwordChars,
>>> 618: JNI_ABORT);
>>> 619: }
>>
>> Although you
On Fri, 29 Jan 2021 21:33:40 GMT, Alexey Semenyuk wrote:
> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>
> The fix splits Linux app launcher in app launcher and launcher shared lib.
> App launcher is pure C and doesn't have C++ code. App launcher lib
> incorporates bulk of C++
On Fri, 29 Jan 2021 14:57:56 GMT, Weijun Wang wrote:
>> This fix covers both
>>
>> - [[macOS]: Remove JNF dependency from
>> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
>> - [[macOS]: Remove JNF dependency from
>>
On Fri, 29 Jan 2021 16:23:20 GMT, Gerard Ziemski wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8260616: Removing remaining JNF dependencies in the java.desktop modul
>
> src/java.desk
On Fri, 29 Jan 2021 10:01:42 GMT, Magnus Ihse Bursie wrote:
>> This removes the JNF dependency from the jdk.hotspot.agent module.
>> The macro expansions are the same as already used in the Java desktop module
>> - which actually uses a macro
>> still but there there are hundreds of uses.
>>
On Fri, 29 Jan 2021 17:02:30 GMT, Gerard Ziemski wrote:
>> Changes requested by gziemski (Committer).
>
> Lots of small changes you had to handle here. Thank you for doing it!
I pushed a commit with the remaining -lframework ... removals in the desktop
makefiles that I had somehow missed ...
l replacement
>
> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with
> local replacement
>
> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
>
> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)
Phil Race has u
On Fri, 29 Jan 2021 10:53:42 GMT, Magnus Ihse Bursie wrote:
>> This completes the desktop module JNF removal
>>
>> * remove -framework JavaNativeFoundation from make files
>>
>> * remove #import from all
>> source files. If needed add import of JNIUtilities.h to get jni.h
>> definitions -
This completes the desktop module JNF removal
* remove -framework JavaNativeFoundation from make files
* remove #import from all source
files. If needed add import of JNIUtilities.h to get jni.h definitions - better
anyway since then it gets the current JDK ones not the ones from the O/S
*
This removes the JNF dependency from the jdk.hotspot.agent module.
The macro expansions are the same as already used in the Java desktop module -
which actually uses a macro
still but there there are hundreds of uses.
The function of this macro code is to prevent NSExceptions escaping to Java and
On Wed, 27 Jan 2021 19:23:48 GMT, Erik Joelsson wrote:
> To guarantee backwards compatible binaries on Macos, we use the option
> -mmacosx-version-min. This is currently set to 10.9, which is a really
> ancient version. I propose we bump this to 10.12, which is still a rather
> conservative
On Mon, 25 Jan 2021 23:34:04 GMT, Phil Race wrote:
>> that sounds good to me, I am just afraid to break intel mac on older macos
>> versions with this change.
>
> That may actually be a valid concern. Both say macOS 10.12+ ... which might
> conflict with the 10.9 targ
On Mon, 25 Jan 2021 22:47:33 GMT, Vladimir Kempik wrote:
>> 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask
>> 2) So maybe rather than the deprecation suppression you could change both
>> constants to the new ones.
>> Ordinarily I'd say let someone else do that but
On Mon, 25 Jan 2021 22:25:48 GMT, Vladimir Kempik wrote:
>> Are you doing something somewhere to change the target version of macOS or
>> SDK ? I had no such problem.
>> I think we currently target a macOS 10.9 and if you are changing that it
>> would need discussion.
>> If you are changing it
On Mon, 25 Jan 2021 21:18:59 GMT, Vladimir Kempik wrote:
>> Hello
>> I believe it was a workaround for issues with xcode 12.2 in early beta days.
>> Those issues were fixed later in upstream jdk, so most likely we need to
>> remove these workarounds.
>
> It seems these workarounds are still
On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
1 - 100 of 388 matches
Mail list logo
