Re: RFR: JDK-8289541 : Update ICU4C to 71.1 [v4]
> Updated icu to v71.1. > Verified build and sanity testing on windows,Mac and Linux. > Removed icu directory from Source/WTF, as the functionality is already > provided by Source/ThirdParty/icu Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Space Corrections - Changes: - all: https://git.openjdk.org/jfx/pull/893/files - new: https://git.openjdk.org/jfx/pull/893/files/84ef0a31..c9678a25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=893&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=893&range=02-03 Stats: 71 lines in 5 files changed: 0 ins; 0 del; 71 mod Patch: https://git.openjdk.org/jfx/pull/893.diff Fetch: git fetch https://git.openjdk.org/jfx pull/893/head:pull/893 PR: https://git.openjdk.org/jfx/pull/893
Re: RFR: JDK-8289541 : Update ICU4C to 71.1 [v3]
On Thu, 8 Sep 2022 17:00:56 GMT, Kevin Rushforth wrote:
>> Hima Bindu Meda has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert CMakelists.txt to be same as master
>
> modules/javafx.web/src/main/native/Source/WTF/CMakeLists.txt line 6:
>
>> 4:
>> 5: add_subdirectory(wtf)
>> 6: # Apple builds have the ICU headers checked into ${WTF_DIR}/icu
>
> It looks like when you reverted some debugging changes, you removed an extra
> blank line. Since this file is otherwise now unchanged from master, can you
> revert the whole file (e.g., by using `git checkout master -- FILENAME`)?
Reverted the file to be same as master.
-
PR: https://git.openjdk.org/jfx/pull/893
Re: RFR: JDK-8289541 : Update ICU4C to 71.1 [v3]
> Updated icu to v71.1. > Verified build and sanity testing on windows,Mac and Linux. > Removed icu directory from Source/WTF, as the functionality is already > provided by Source/ThirdParty/icu Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Revert CMakelists.txt to be same as master - Changes: - all: https://git.openjdk.org/jfx/pull/893/files - new: https://git.openjdk.org/jfx/pull/893/files/8135a606..84ef0a31 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=893&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=893&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/893.diff Fetch: git fetch https://git.openjdk.org/jfx pull/893/head:pull/893 PR: https://git.openjdk.org/jfx/pull/893
Re: RFR: JDK-8289541 : Update ICU4C to 71.1 [v2]
On Thu, 8 Sep 2022 16:58:32 GMT, Hima Bindu Meda wrote: >> Updated icu to v71.1. >> Verified build and sanity testing on windows,Mac and Linux. >> Removed icu directory from Source/WTF, as the functionality is already >> provided by Source/ThirdParty/icu > > Hima Bindu Meda has updated the pull request incrementally with one > additional commit since the last revision: > > Convert Line Endings to UNIX and update mainifest.txt modules/javafx.web/src/main/native/Source/WTF/CMakeLists.txt line 6: > 4: > 5: add_subdirectory(wtf) > 6: It looks like when you reverted some debugging changes, you removed an extra blank line. Since this file is otherwise now unchanged from master, can you revert the whole file (e.g., by using `git checkout master -- FILENAME`)? - PR: https://git.openjdk.org/jfx/pull/893
Re: RFR: JDK-8289541 : Update ICU4C to 71.1
On Thu, 8 Sep 2022 15:34:32 GMT, Kevin Rushforth wrote: > One quick comment. I noticed that several files have changed from Unix-style > line endings to DOS-style (CRLF) line endings. These are all extensions that > aren't in our list of ones to check for whitespace (so jcheck won't catch > them), but they should be converted back to Unix-style line endings to > minimize diffs and avoid churn. Here is the list: > > ``` > Source/ThirdParty/icu/source/common/common.rc > Source/ThirdParty/icu/source/common/common.vcxproj > Source/ThirdParty/icu/source/common/common.vcxproj.filters > Source/ThirdParty/icu/source/common/common_uwp.vcxproj > Source/ThirdParty/icu/source/common/rbbicst.pl > Source/ThirdParty/icu/source/common/rbbirpt.txt > Source/ThirdParty/icu/source/common/sources.txt > Source/ThirdParty/icu/source/i18n/i18n.rc > Source/ThirdParty/icu/source/i18n/i18n.vcxproj > Source/ThirdParty/icu/source/i18n/i18n.vcxproj.filters > Source/ThirdParty/icu/source/i18n/i18n_uwp.vcxproj > Source/ThirdParty/icu/source/i18n/regexcst.pl > Source/ThirdParty/icu/source/i18n/regexcst.txt > Source/ThirdParty/icu/source/i18n/sources.txt > Source/ThirdParty/icu/source/stubdata/sources.txt > Source/ThirdParty/icu/source/stubdata/stubdata.vcxproj > Source/ThirdParty/icu/source/stubdata/stubdata.vcxproj.filters > Source/ThirdParty/icu/source/tools/toolutil/sources.txt > Source/ThirdParty/icu/source/tools/toolutil/toolutil.vcxproj > ``` Changed Line Endings to Unix-style - PR: https://git.openjdk.org/jfx/pull/893
Re: RFR: JDK-8289541 : Update ICU4C to 71.1 [v2]
> Updated icu to v71.1. > Verified build and sanity testing on windows,Mac and Linux. > Removed icu directory from Source/WTF, as the functionality is already > provided by Source/ThirdParty/icu Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Convert Line Endings to UNIX and update mainifest.txt - Changes: - all: https://git.openjdk.org/jfx/pull/893/files - new: https://git.openjdk.org/jfx/pull/893/files/cc800aba..8135a606 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=893&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=893&range=00-01 Stats: 7472 lines in 21 files changed: 3 ins; 0 del; 7469 mod Patch: https://git.openjdk.org/jfx/pull/893.diff Fetch: git fetch https://git.openjdk.org/jfx pull/893/head:pull/893 PR: https://git.openjdk.org/jfx/pull/893
Re: RFR: JDK-8289541 : Update ICU4C to 71.1
On Wed, 7 Sep 2022 18:13:43 GMT, Hima Bindu Meda wrote: > Updated icu to v71.1. > Verified build and sanity testing on windows,Mac and Linux. > Removed icu directory from Source/WTF, as the functionality is already > provided by Source/ThirdParty/icu One quick comment. I noticed that several files have changed from Unix-style line endings to DOS-style (CRLF) line endings. These are all extensions that aren't in our list of ones to check for whitespace (so jcheck won't catch them), but they should be converted back to Unix-style line endings to minimize diffs and avoid churn. Here is the list: Source/ThirdParty/icu/source/common/common.rc Source/ThirdParty/icu/source/common/common.vcxproj Source/ThirdParty/icu/source/common/common.vcxproj.filters Source/ThirdParty/icu/source/common/common_uwp.vcxproj Source/ThirdParty/icu/source/common/rbbicst.pl Source/ThirdParty/icu/source/common/rbbirpt.txt Source/ThirdParty/icu/source/common/sources.txt Source/ThirdParty/icu/source/i18n/i18n.rc Source/ThirdParty/icu/source/i18n/i18n.vcxproj Source/ThirdParty/icu/source/i18n/i18n.vcxproj.filters Source/ThirdParty/icu/source/i18n/i18n_uwp.vcxproj Source/ThirdParty/icu/source/i18n/regexcst.pl Source/ThirdParty/icu/source/i18n/regexcst.txt Source/ThirdParty/icu/source/i18n/sources.txt Source/ThirdParty/icu/source/stubdata/sources.txt Source/ThirdParty/icu/source/stubdata/stubdata.vcxproj Source/ThirdParty/icu/source/stubdata/stubdata.vcxproj.filters Source/ThirdParty/icu/source/tools/toolutil/sources.txt Source/ThirdParty/icu/source/tools/toolutil/toolutil.vcxproj - PR: https://git.openjdk.org/jfx/pull/893
RFR: JDK-8289541 : Update ICU4C to 71.1
Updated icu to v71.1. Verified build and sanity testing on windows,Mac and Linux. Removed icu directory from Source/WTF, as the functionality is already provided by Source/ThirdParty/icu - Commit messages: - Update file permission for rbbicst.pl - update file permission - Remove tabs - whitespace corrections - Remove white spaces - Update icu version and checksum - Update icu to v71-1 Changes: https://git.openjdk.org/jfx/pull/893/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=893&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289541 Stats: 152378 lines in 757 files changed: 11009 ins; 123550 del; 17819 mod Patch: https://git.openjdk.org/jfx/pull/893.diff Fetch: git fetch https://git.openjdk.org/jfx pull/893/head:pull/893 PR: https://git.openjdk.org/jfx/pull/893
Re: [External] : Re: ConcurrentModificationException when calling stage.show()
Presuming that you aren't calling initialize directly from some other
thread, and aren't concurrently accessing the menu from some other
thread, I agree that adding a runLater shouldn't be needed. So yes, this
does seem like our bug. Can you file a bug report at
https://bugreport.java.com/ with a complete standalone test case?
-- Kevin
On 9/7/2022 11:57 PM, Daniel Peintner wrote:
Hi Kevin, all,
I investigated further and I think I found the problem (or at least a
solution).
In my application I use FXML+Controller approach.
The issue I described arises if in controller.initialize(...).
I update the menu-items of a menu. In my case, the menu list is empty
in FXML and while initializing I update the menu with the "recently"
opened files so that people can restart their work with files they
opened before.
The solution that works in my case is to wrap these menu updates in
Platform.runLater() even though I think this should not be needed. Am
I right?
public class MyLayoutController extends BorderPane implements
Initializable {
@Override
public void initialize(URL location, ResourceBundle resources) {
// updating the menu updates within runLater() does not cause
ConcurrentModificationException
Platform.runLater(() -> {
// anyhow, I think this should not be needed
this.menu.getItems().add(new MenuItem("A"));
this.menu.getItems().add(new MenuItem("B"));
this.menu.getItems().add(new MenuItem("C"));
});
}
}
Is this sufficient to create a bug report?
Thanks,
-- Daniel
On Mon, Sep 5, 2022 at 7:47 PM Kevin Rushforth
wrote:
I suspect a JavaFX bug, unless there some other thread not shown
in your
stack trace that is modifying any object in the now-live scene graph.
-- Kevin
On 9/5/2022 6:34 AM, Daniel Peintner wrote:
> All,
>
> I have a strange issue popping up once in a while.
> I have an application (FXML+ Controller) that has a "new" button
> opening a new window. In 99% percent of the cases this works
just fine.
>
> In some rare cases though, stage.show() fails due to a
> ConcurrentModificationException. Since this issue does not
happen in
> my code but rather in JavaFX code I wanted to ask whether there
is a
> specific prerequisite I am not aware of or whether this is a bug in
> JavaFX.
>
> Attached the stack trace. Unfortunately I am not able to create a
> reproducible example that fails always.
>
> I am grateful for any tip.
>
> Thanks,
>
> -- Daniel
>
>
> Exception in thread "JavaFX Application Thread"
> java.lang.RuntimeException:
java.lang.reflect.InvocationTargetException
> at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1857)
> at
>
javafx.fxml.FXMLLoader$ControllerMethodEventHandler.handle(FXMLLoader.java:1724)
> at
>
com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
> at
>
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
> at
>
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
> at
>
com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
> at
>
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
> at
>
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at
>
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> at
>
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at
>
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> at
>
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at
>
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> at
>
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
> at javafx.event.Event.fireEvent(Event.java:198)
> at javafx.scene.Node.fireEvent(Node.java:8797)
> at javafx.scene.control.Button.fire(Button.java:203)
> at
>
com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:208)
> at
>
com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274)
> at
>
com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247)
> at
>
com.sun.javafx.event.CompositeEventHandler.dispatchBub
Integrated: 8293375: add_definitions USE_SYSTEM_MALLOC when USE_SYSTEM_MALLOC is ON
On Tue, 6 Sep 2022 01:19:07 GMT, Leslie Zhai wrote: > Hi, > > jfx web failed to build when `USE_SYSTEM_MALLOC` is `ON`: > > > jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Platform.h:58, > jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Assertions.h:28, > jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.h:31, > jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.cpp:28, > jfx/modules/javafx.web/build/linux/Release/WebCore/DerivedSources/unified-sources/UnifiedSource-3c72abbe-47.cpp:1: > jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/PlatformUse.h:351:10: > fatal error: bmalloc/BPlatform.h: No such file or directory > #include >^ > compilation terminated. > > > After commit `6f28d912024495278c4c35ab054bc2aab480b3e4`: > > > diff --git a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h > b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h > index 70c047813f..d30291697a 100644 > --- a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h > +++ b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h > > ... > > #if PLATFORM(IOS_FAMILY) > #define USE_SANDBOX_EXTENSIONS_FOR_CACHE_AND_TEMP_DIRECTORY_ACCESS 1 > #endif > + > +#if !defined(USE_LIBPAS_JIT_HEAP) && !USE(SYSTEM_MALLOC) > +#include > +#if BENABLE(LIBPAS) > +#if PLATFORM(MAC) && CPU(ARM64) > +#define USE_LIBPAS_JIT_HEAP 1 > +#endif > +#endif > +#endif > + > > > Please review my patch. > > Thanks, > Leslie Zhai This pull request has now been integrated. Changeset: 28f8fa9c Author:Leslie Zhai Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/28f8fa9c20363ced9a94787ecfd45735b3e6b82e Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8293375: add_definitions USE_SYSTEM_MALLOC when USE_SYSTEM_MALLOC is ON Reviewed-by: jbhaskar, kcr - PR: https://git.openjdk.org/jfx/pull/892
Re: RFR: 8293214: Add support for Linux/LoongArch64 [v3]
On Wed, 7 Sep 2022 11:59:42 GMT, Johan Vos wrote:
>> Ao Qi has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> revert
>
> build.gradle line 313:
>
>> 311: } else if (IS_MAC && OS_ARCH != "x86_64" && OS_ARCH != "aarch64") {
>> 312: fail("Unknown and unsupported build architecture: $OS_ARCH")
>> 313: } else if (IS_LINUX && OS_ARCH != "i386" && OS_ARCH != "amd64" &&
>> OS_ARCH != "aarch64" && OS_ARCH != "loongarch64") {
>
> this could be simplified with
> `... && !IS_LOONGARCH64` which avoids the more error-prone duplicate
> "loongarch64" string.
> (the same applies to replacing the aarch64 check with !IS_AARCH64)
Done.
> modules/javafx.media/src/main/native/gstreamer/projects/linux/avplugin/Makefile
> line 36:
>
>> 34: -ffunction-sections -fdata-sections
>> 35:
>> 36: ifeq (,$(findstring $(ARCH), aarch64 loongarch64))
>
> This will work, but I wonder if we should revert the test: we now always
> assume that msse2 is supported, unless we are on an architecture which we
> know doesn't support it. It might be safer to only ask for msse2 support if
> we are really sure it is supported by the architecture (which currently means
> a check on x32 and x64)
Done.
-
PR: https://git.openjdk.org/jfx/pull/888
Re: RFR: 8293214: Add support for Linux/LoongArch64 [v4]
> LoongArch is a new RISC ISA. This issue proposes adding support for
> Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but
> the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit
> is updated to OpenJFX, it is supposed to work.
>
> Testing:
> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with
> WebKit,without Webkit} on Linux/x64
> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with
> WebKit,without Webkit} on Linux/aarch64
> - [x] base, controls, fxml and graphics tests, {Release,Debug}, without
> WebKit on Linux/loongarch64
Ao Qi has updated the pull request incrementally with one additional commit
since the last revision:
disable msse2 by default, use IS_LOONGARCH64 and IS_AARCH64
-
Changes:
- all: https://git.openjdk.org/jfx/pull/888/files
- new: https://git.openjdk.org/jfx/pull/888/files/b225c59a..29e4b883
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jfx&pr=888&range=03
- incr: https://webrevs.openjdk.org/?repo=jfx&pr=888&range=02-03
Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
Patch: https://git.openjdk.org/jfx/pull/888.diff
Fetch: git fetch https://git.openjdk.org/jfx pull/888/head:pull/888
PR: https://git.openjdk.org/jfx/pull/888
