The thing about JAR files

Has anyone notices that the JAR files produced, eclipse in my case, in javafx 12+ applications do not run with an error that reads java -jar app.jar Error Javafx runtime components are missing, and are required to run this application. It seems that it is quit common, since there are so many

Re: The thing about JAR files

Check here https://stackoverflow.com/questions/56771832/java-12-and-javafx-12-create-runnable-jar-and-custom-jre On 10/17/2019 6:08 AM, AmnoJeeuw wrote: Has anyone notices that the JAR files produced, eclipse in my case, in javafx 12+ applications do not run with an error that reads java -jar

Re: Change Priority of JDK-8231513

Yes. Please! I was looking at this a while ago but I'm not familiar enough with the source to see where the problem lies. On 10/16/2019 5:52 PM, Sebastian Stenzel wrote: I would like to ask whether it doesn't make sense to give this issue a little more attention than P4: https://bugs.openjdk.

Re: The thing about JAR files

What’s in the jar manifest? How did you create the Java 12 runtime? Scott > On Oct 17, 2019, at 6:09 AM, AmnoJeeuw wrote: > > Has anyone notices that the JAR files produced, eclipse in my case, in > javafx 12+ applications do not run with an error that reads > java -jar app.jar > > Error Ja

Re: Change Priority of JDK-8231513

I just raised the priority to P3. It hits every JavaFX application the first time you move the mouse into the window. It's already targeted to openjfx14, but if anyone has time to take a look at this, a contribution would be welcome. -- Kevin On 10/17/2019 3:45 AM, Dan Howard wrote: Yes. Ple

Re: Change Priority of JDK-8231513

I found another software with this problem, claiming that switching from "Event Tapping" to "Global Event Monitoring" helped fixing the issue: https://www.irradiatedsoftware.com/help/cinch/ Quote: "A new "Input Monitoring" permission was added in

Refire event while it is delivered is evil - always?!

While fixing https://bugs.openjdk.java.net/browse/JDK-8207759 it turned out that the underlying reason for the bug was a broken event dispatch sequence introduced by behavior.forwardToParent. Which is a call to parent.fireEvent with the event that was received. This builds a nested chain

Cannot protect copying of synchronizedObservableMap

I've just stumbled upon a devious detail in javafx.collections.FXCollections.SynchronizedObservableMap. Although it almost looks like a twin of Collections.synchronizedMap it does not allow to protect copying or iterating over it the way Collections.synchronizedMap does. Example program: import ja

Re: Building OpenJFX on clean install of CentOS 7

The current toolchain for building JavaFX is gcc 8.2. As long as you don't build WebKit, it will still build with gcc 5.4. I just tried it on an Oracle Linux 7 machine with gcc 4.9.1 (which is what we used to use a couple years ago), and the build fails for me with the same error. Looks like y

Re: Cannot protect copying of synchronizedObservableMap

Hi Robert, 1. Is the behavior of SynchronizedObservableMap a bug, where it uses a new mutex and doesn't synchronize on itself a bug? I'd say yes, this is a bug. Clearly the class is meant to mimic the corresponding Collections class with observability added. The fact that it then doesn't syn

Re: Cannot protect copying of synchronizedObservableMap

> > If we want a map that is both synchronized and observable, then yes. In > any case, I don't see any value in trying to eliminate it from the API > (e.g., through deprecation --> deprecation for removal --> removal). One could do this: protected Map criteriaLock = Collections.synchronizedMap(

Re: Building OpenJFX on clean install of CentOS 7

I heard similar reports from developers trying to build with gcc 4.x. We might benefit from an assert early in the build. On Thu, Oct 17, 2019 at 3:16 PM Kevin Rushforth wrote: > The current toolchain for building JavaFX is gcc 8.2. As long as you > don't build WebKit, it will still build with g

Re: RFR: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene()

On Thu, 17 Oct 2019 15:28:28 GMT, mruzicka wrote: > Secondary event loop introduced as a means of synchronization with the JavaFX > Application thread in [1] never terminates as the SecondaryLoop.exit() call > is not reached because the thread is blocked in the SecondaryLoop.enter() > call. >

Re: RFR: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene()

On Thu, 17 Oct 2019 15:28:30 GMT, mruzicka wrote: > On Thu, 17 Oct 2019 15:28:28 GMT, mruzicka > wrote: > >> Secondary event loop introduced as a means of synchronization with the >> JavaFX Application thread in [1] never terminates as the >> SecondaryLoop.exit() call is not reached because

RFR: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene()

Secondary event loop introduced as a means of synchronization with the JavaFX Application thread in [1] never terminates as the SecondaryLoop.exit() call is not reached because the thread is blocked in the SecondaryLoop.enter() call. This patch fixes the problem by submitting the UI work (includi

Re: Building OpenJFX on clean install of CentOS 7

Yeah, this would be helpful. I'm pretty sure we've had requests for checking other dependencies (like missing packages, etc). Failing fast with an explicit error message is almost always better than wasting time tracking down strange build failures. -- Kevin On 10/17/2019 7:23 AM, Johan Vos

Re: JDK-8130738 TextFlow's tab width is static

Hi, Some more points which I thought about but for whatever reason did not pen .. First one minor thing: tabWidth is an OK name, but it does not conjure up that the value you specify isn't a width in pixels but the number of discrete space characters to use. FWIW CSS calls it tab-size. But CSS

Re: JDK-8130738 TextFlow's tab width is static

Hi Phil, Thanks for taking a look. I was going to get back to this soon to attempt adding the CSS property as you mention in your previous email. I considered tabSize as a name as well. I don’t have a preference if we leave things as representing tabs as a number of spaces. But it wouldn’t

Re: JDK-8130738 TextFlow's tab width is static

It might make sense to just add the tabSize property now, and later consider adding a tabUnits property in the future if needed. By default, having the units be "number of spaces in the current font" is what makes the most sense, so before we could add tabUnits we would need to extend it as you

Re: JDK-8130738 TextFlow's tab width is static

So do we go ahead and implement tabSize without the CSS support? I’m not sure the CSS property should be added before unit issues are worked out, as I think the units would be expected in the CSS context. E.g. CSS implicitly adds ‘px’ if no unit is specified. If our tabSize units are spaces,

Re: JDK-8130738 TextFlow's tab width is static

That's a good question. It feels a bit incomplete without CSS support, but might be good enough for most uses. I'd be interested in what other developers think. -- Kevin On 10/17/2019 11:22 AM, Scott Palmer wrote: So do we go ahead and implement tabSize without the CSS support? I’m not sur

Re: JDK-8130738 TextFlow's tab width is static

Hi, As I wrote, adding units complicates things. We would have two linked properties in what you have below and one modifies the interpretation of the other. If we expose the number of spaces integer property today, I think we'd have to add the units as a separate property, but it might be th

Re: JDK-8130738 TextFlow's tab width is static

On 10/17/19 11:16 AM, Kevin Rushforth wrote: It might make sense to just add the tabSize property now, and later consider adding a tabUnits property in the future if needed. By default, having the units be "number of spaces in the current font" is what makes the most sense, so before we coul

Re: JDK-8130738 TextFlow's tab width is static

Really ? It defaults to pixels ? Is that just inherited as being the default CSS unit ? Is that FX's implementation Hmm. A bit of reading about web CSS says that strictly anything without an explicit unit should be ignored. The only exception is zero, where it doesn't matter. Eg see : https:

Re: JDK-8130738 TextFlow's tab width is static

Hi, Thanks for that. It also neatly solves the units problem. I think it means we can just support the same and not go out of our way to make provision for pixels. -phil. On 10/17/19 11:46 AM, David Grieve wrote: FWIW, w3c spec for tab-size is https://drafts.csswg.org/css-text-3/#propdef-ta

Re: JDK-8130738 TextFlow's tab width is static

You’re right. Something I was reading indicated that while there was no default unit, ‘px’ was implicitly appended. I can’t find that now. Go figure. Everything I find now about CSS tab-size is in agreement with what David wrote. It’s a number of spaces. With units it would be a ‘length’ but

Re: JDK-8130738 TextFlow's tab width is static

It seems that you have a path forward then. So, there are a couple questions to answer: 1. Should the type of the property be int or double? If it really is only ever going to be a number of spaces, then int seems fine. That, along with the name of the property, would underscore the fact that

Re: JDK-8130738 TextFlow's tab width is static

On 10/17/19 12:32 PM, Kevin Rushforth wrote: It seems that you have a path forward then. So, there are a couple questions to answer: 1. Should the type of the property be int or double? If it really is only ever going to be a number of spaces, then int seems fine. That, along with the name

Re: JDK-8130738 TextFlow's tab width is static

Hi, Kevin asked for developers opinions on this issue, just thought I'd leave my own. Didn't have time to read the thread thoroughly enough, don't have much time at the moment to do it. Apologies for that. Just wanted to make a comment about the CSS support for this feature. I think if you add i

Re: JDK-8130738 TextFlow's tab width is static

I think what we’ve settled on fits CSS for the web. I agree we shouldn’t deviate from that if possible. Scott > On Oct 17, 2019, at 5:30 PM, Pedro Duque Vieira > wrote: > > Hi, > > Kevin asked for developers opinions on this issue, just thought I'd leave > my own. > > Didn't have time to

Re: Building OpenJFX on clean install of CentOS 7

Kevin, I updated my gcc to 8.2.0 using the steps here https://medium.com/@bipul.k.kuri/install-latest-gcc-on-centos-linux-release-7-6-a704a11d943d and was able to successfully build and run all the tests. thank you for the specific version, I will probably do the same exercise on CentOS 8 Michae

Using gradle mit JDK-13

In trying to provide a fix for JDK-8232524 I have begun to setup a build for JavaFX. According to [1] using JDK-13 is recommended. However, gradle is not yet ready to run on JDK-13 ([2]): [rli@rlinux jfx]$ ./gradlew clean FAILURE: Build failed with an exception. * Where: Build file '/home/rli/