Re: [12] RFR: JDK-8209966: Update minimum boot JDK to 11

Historically, there was a no-go for default interface methods in the 8-tree a long time ago, as those would break the android port (thanks Stephen Northover for imposing that). Hence, I was happy with the restrictions not to use new language features. Android is a special case though, as that is

Re: Filling the Packager gap

On Thu, Sep 27, 2018 at 4:14 AM Ty Young wrote: > > On 9/19/18 3:55 AM, Johan Vos wrote: > > Hi, > > > > As promised, we looked into an interim solution for the packager-gap. > Work > > for the new Java Packager (12?) is being done in the OpenJDK sandbox >

Re: [12] RFR: JDK-8209966: Update minimum boot JDK to 11

> > > > And it's only going to get worse as time goes on. Would it not be > > possible to support up until the last JDK LTS(Starting at 11) release > > for building JavaFX? I feel like maybe that would be more reasonable. > > This is a good question, and maybe in the future we might not be so >

Re: "javapackager" in no-mans-land?

Auto-update and a packager are different things. Both are needed, but at this moment, there is only a JEP for the packager. I think it would be wise to have a standard (hence a JEP) for auto-update as well, as the use case you describe is not unique... - Johan On Sun, Sep 23, 2018 at 8:40 AM

Re: Talk about OPENJFX's future

on video where > the results would be the complete opposite. > >> Yeah, good programmers can write slow code (especially if you have a > motive)... > >> On 21 Sep 2018, at 19:29, Johan Vos wrote: > >> > >>>> We can't defeat QT in performance, but

Re: Talk about OPENJFX's future

> > We can't defeat QT in performance, but we can defeat it at applicability > and just don't get too far behind QT in performance. (bad example > https://www.youtube.com/watch?v=Kh6K-yEp_JY) > That video demonstrates the creator has absolutely no development skills in Java, or he intentionally

Filling the Packager gap

Hi, As promised, we looked into an interim solution for the packager-gap. Work for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. We backported the required changes to an OpenJDK 11 mirror: https://github.com/johanvos/openjdk-mobile11/tree/packager With this, we created

Re: JavaFX 11 is released

te now and will be shipped as a > GA version next week, or on JDK 10 (OpenJDK build only). > > A big thank you to all who have contributed to OpenJFX make this release > possible! I especially thank Johan Vos, both for taking on the role as > Co-Lead of the OpenJFX Project and for the wor

Review request for 8210359

Please review webrev http://cr.openjdk.java.net/~jvos/8210359/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8210359 (this allows to build OpenJFX SDK on platforms that don't include Swing, e.g. armv6hf)

webkit feedback calls on failure

The WebEngine already allows to get information about the progress of the underlying webkit via the onError() handler and the getLoadWorker() status updates. However, there are a number of cases where things go wrong in webkit, yet the status of the loadWorker is SUCCEEDED and no WebErrorEvent is

JavaFX website

It has been mentioned a number of times that JavaFX would benefit from a JavaFX website. I see a number of options that fall in the category website: 1. A set of pages with details on what OpenJFX is, how to build, where to download and get release notes, how to contribute, roadmap,... That is

Review request for 8209969

Please review the trivial fix for https://bugs.openjdk.java.net/browse/JDK-8209969 at http://cr.openjdk.java.net/~jvos/8209969/webrev.00/ (approved and merged in github via https://github.com/javafxports/openjdk-jfx/commit/3fbd1165a31cf07a4dcb6c854597adeccc4af7c7 ) Thanks, - Johan

Re: JavaFX 11 maven snapshots - empty jars

mples/pull/1) for > your javafx11samples with a build.gradle work-around to filter out the > empty javafx-jars. > > This makes your samples run with Java 11, gradle 4.9 and openjdx 11-ea+19. > > /Lennart > > > 22 aug. 2018 kl. 14:11 skrev Johan Vos : > > I spent s

Re: JavaFX 11 maven snapshots - empty jars

OM-only artifacts for maven builds can be >> defined (javafx-controls, javafx-graphics). >> These POM's can still use the Javafx.pom as a parent and Joeri's case 2 >> should work for maven. >> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 >> >

Re: Why are there only platform-specific Maven artifacts?

The platform-specific code is a general Java issue that needs to be solved one day. Your suggestion basically comes down to moving the classfiles from the platform-specific jars into the empty jars, right? A problem with this is that currently, the jars are platform-dependent as well (e.g. no

Re: building webkit

jfxwebkit and media natives from > >> that build. So if we had a nightly build available, most developers > >> could use that (it wouldn't help anyone making native changes to WebKit, > >> but would be fine for most developers who don't). > >> > >> -- Kevin >

Re: building webkit

; > that build. So if we had a nightly build available, most developers > > could use that (it wouldn't help anyone making native changes to WebKit, > > but would be fine for most developers who don't). > > > > -- Kevin > > > > [1] https://github.com/j

building webkit

We currently don't build WebKit with Appveyor/Travis, as the combined build time would be too long. I'm wondering though if it would be possible to have separate build jobs for webkit? Typically, when building a JavaFX SDK, the webkit part is where things go wrong (if they go wrong), and have

Travis failures in jfx-11 branch

I noticed Travis fails a number of times on branches. For example: https://travis-ci.org/javafxports/openjdk-jfx/builds/419599353 This is the exact commit that worked fine in the development branch. >From the logs, it seems that the failures occur when all the packages have to be installed:

Re: JavaFX 11 maven snapshots - empty jars

I spent some more time on this. Adding the Automatic-Module-Name seems the easiest fix to me. I created a PR at https://github.com/javafxports/openjdk-jfx/pull/162 for this. Having the platform-name hardcoded in the artifact Id would require upfront magic in build.gradle or pom.xml to prevent the

Re: JavaFX Deployment

Hi Petr, Your questions are actually related. The recommended way for distributing JavaFX apps is by bundling them with the required libraries, modules and VM into an executable. That way, you determine whether your application works with Java 8, 9, 10, 11 or beyond. You simply bundle the

Re: JavaFX 11 maven snapshots - empty jars

afx-controls, javafx-graphics). >> These POM's can still use the Javafx.pom as a parent and Joeri's case 2 >> should work for maven. >> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 >> >> Regarding the current solution: >> Does the

Re: Fate of jdk.packager and jdk.packager.services?

We (Gluon) are looking into creating a JavaFX 11 version of the packager. - Johan On Thu, Aug 9, 2018 at 1:42 PM Cyril F wrote: > I am sure the new jpackager tool will be a good substitute. But won't come > before jdk12... > > In fact we are in the current situation : > We have a

Re: NativeLibLoader - installLibraryFromResource - RuntimeImage

to fix, but I'm curious about how >> you created your custom image. The jmods are more suitable for that >> approach, since their purpose is to be used with jlink to create a >> custom image, in which case the native libraries will be linked into the >> image. Maybe I'm

Re: NativeLibLoader - installLibraryFromResource - RuntimeImage

tracked in https://github.com/javafxports/openjdk-jfx/issues/142. Tested on linux, not yet on mac/windows On Thu, Jul 26, 2018 at 11:46 AM Johan Vos wrote: > Hi Steve, > > That looks like a bug. The libPrefix and libSuffix are indeed not set in > cases where usingModules is true, w

Re: NativeLibLoader - installLibraryFromResource - RuntimeImage

Hi Steve, That looks like a bug. The libPrefix and libSuffix are indeed not set in cases where usingModules is true, which is only the case when the jrt protocol is used. It seems to me the prefix/suffix should always be computed. It doesn't look right that they are computed inside the

Re: Review-Request for JDK-8207370

Hi Michael, Excuse me for the simple question, but how to you enable those tests (as in: what options do you provide to gradle)? Fix looks trivial to me, but want to double check. - Johan On Mon, Jul 23, 2018 at 11:36 PM Michael Ennen wrote: > Hi, > > I'd like to request a review for

Re: Simple Maven example fails with unusual error

Hi Mark, Paul, I can't reproduce the issue, as I'm running into these warnings that are turned into errors, apparantly: [WARNING] Rule 4: org.apache.maven.plugins.enforcer.RequireProperty failed with message: Property "io7m.api.previousVersion" evaluates to "". This does not match the regular

Re: JavaFX 11 maven snapshots - empty jars

es the module name > > javafx.controls and the platform dependent uses e.g. > javafx.controls.windows > > > > Regards, > > Steve > > > > > > Am Fr., 13. Juli 2018 um 17:00 Uhr schrieb Kevin Rushforth < > > kevin.rushfo...@oracle.com>: > > >

Re: JavaFX 11 maven snapshots - empty jars

Hi Steve, Yes, that has been considered, but I'm more than happy to re-open the discussion. The problem with javafx-controls-${javafx.platform} as the artifactId is that in that case, the gradle developer is in all cases required to add the platform suffix to the dependency, which makes it very

review request for 8205919: artifacts for maven central

PR 83 (https://github.com/javafxports/openjdk-jfx/pull/83) is ready to be merged. The JBS issue is at https://bugs.openjdk.java.net/browse/JDK-8205919 webrev: http://cr.openjdk.java.net/~jvos/8205919/webrev.00/rt.patch The GitHub PR is approved by Kevin, if I get a +1 on the webrev I can do that

Re: CFV: New OpenJFX Committer: Prem Balakrishnan

Vote: Yes On Wed, Jul 11, 2018 at 1:52 AM Kevin Rushforth wrote: > I hereby nominate Prem Balakrishnan [1] to OpenJFX Committer. > > Prem is a member of JavaFX team at Oracle, who has contributed 10 > changesets [2] to OpenJFX. > > Votes are due by July 24, 2018. > > Only current OpenJFX

Re: JavaFX 11 snapshots in maven sonatype

i 2018, 19:04: > >> If separate Gradle processes produce the artifacts, there is probably a >> way to bring them together and (re-)publish them together in yet another >> project. >> >> Scott >> >> > On Jul 8, 2018, at 8:38 AM, Johan Vos wrote: &

Re: JavaFX 11 snapshots in maven sonatype

r each target where the artifacts are > generated, which is the only place it's used anyways: > > compileTargets { t -> > artifact project.tasks."moduleEmptyPublicationJar$t.capital" > artifact project.tasks."modularPublicationJar$t.capital" { > class

Re: JavaFX 11 snapshots in maven sonatype

ul 6, 2018 at 2:33 PM Johan Vos wrote: > That is a known issue indeed, but I think it should be fixed in Gradle. We > can't easily upload all platforms using the same snapshot version, unless > I'm missing something? > > We ran into this before, when working with nd4j SNAPSHOT

Re: JavaFX 11 snapshots in maven sonatype

components are missing, and are required to > run this application > You can launch it via maven but I normally prefer to do it directly > which is no problem with a normal maven project. > > Michael > > Am 05.07.18 um 11:03 schrieb Johan Vos: > > A first batch of snap

Re: JavaFX 11 snapshots in maven sonatype

9 341 92 60 30 47 <+49%20341%2092603047> > E: gerd.mueller-schr...@hexagon.com > > Hexagon Geospatial > Wittenberger Straße 15B > 04129 Leipzig, Germany > hexagongeospatial.com > > -Original Message- > From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.ja

Re: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2

inor visual differences along > the stroked curve. > > Finally MarlinFX 0.9.2 is giving same clipping accuracy than Marlin 0.9.1 > integrated in jdk11. > Performance is mainly improved for huge dashed paths. > > Kevin & Johan, do you consider the last webrev is approved by

JavaFX 11 snapshots in maven sonatype

A first batch of snapshots for the JavaFX 11 modules is now in the maven sonatype snapshot repository (see https://oss.sonatype.org/content/repositories/snapshots/org/openjfx/ although you probably don't want to work with these artifacts directly but use build tools like maven or gradle to do

Re: [11] JDK-8204621: Upgrade MarlinFX to 0.9.2

I looked at it, mainly at the differences between the Java2D patch and the JavaFX patch, and it looks ok to me. I'll try to test it on linux and/or mac later today and have a deeper look. - Johan On Tue, Jul 3, 2018 at 6:14 PM Kevin Rushforth wrote: > Looks good. > > +1 -- note that needs a

maven artifacts

As discussed before, there will be at least 2 ways developers can work with JavaFX 11 and beyond: 1. use the standalone SDK, with platform-specifc distributions 2. use artifacts on (remote) repositories For the second option, we have to distinguish between build systems (e.g. maven/gradle) and

Re: Chance of Backporting Gtk3 Support to JavaFX 8

That sounds very reasonable to me. [disclaimer: I had to build JavaFX with GTK3 already as I ran into issues on a new system ;) ] - Johan On Wed, Jun 6, 2018 at 10:31 AM Tom Schindl wrote: > Hi, > > Eclipse SWT developers are about to remove Gtk2-SWT port once they start > developing towards

Re: launching JavaFX in 11

ons. I think effort would be better spent getting everything > to work with javafx.* modules as proper named modules. > > -- Kevin > > > On 6/5/2018 6:40 AM, Johan Vos wrote: > > Hi, > > > > I'm a bit confused on the different options for launching JavaFX > >

launching JavaFX in 11

Hi, I'm a bit confused on the different options for launching JavaFX applications with the latest Java 11 code. When running an app from maven, it worked fine. Maven uses the classpath and not the module path, so I assumed that running the same app using java -cp all-javafx-jars Main would work

Re: Removal of apps/scenebuilder from OpenJFX repo

, Jun 5, 2018 at 9:56 AM Johan Vos wrote: > Sorry, I missed this question. > We incorporated the changes that were in OpenJFX 9 into the butbucket repo > and they are part of the Gluon Scene Builder 9 release. > > - Johan > > On Tue, Mar 13, 2018 at 10:17 PM Michael

Re: Removal of apps/scenebuilder from OpenJFX repo

Hi Sverre, That is true, we are moving Scene Builder to GitHub. It was a labour intensive process as we looked into PR's and issues and history etc, but it's almost done now. While the process doesn't change, we understood most developers prefer to work with github for these kinds of open-source

Re: Removal of apps/scenebuilder from OpenJFX repo

Sorry, I missed this question. We incorporated the changes that were in OpenJFX 9 into the butbucket repo and they are part of the Gluon Scene Builder 9 release. - Johan On Tue, Mar 13, 2018 at 10:17 PM Michael Paus wrote: > How will these changes then be synchronized with the work Gluon is

Re: OpenGL deprecated in OS-X

Ever since Apple deprecated the developer-oriented Apple ][ , I failed to appreciate their decisions. But so be it. The good thing is that the structure of the OpenJFX project allows for different rendering pipelines without much impact on other code. Therefore, I think it would be a nice sandbox

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

olkit is up replace that image with a window > (SWT > >>> calls it Shell) so that you can go interactive showing videos, > >>> a progressbar, ... > >>> > >>> Tom > >>> > >>>> On 03.06.18 10:11, Mario Ivankovits wrote

Re: JavaFX app for non-techie users

Hi Jan, The goal is indeed to provide the JavaFX components as maven artifacts (e.g. see https://github.com/javafxports/openjdk-jfx/issues/52). Would that fix your issue? - Johan On Fri, Jun 1, 2018 at 8:02 PM Jan Tosovsky wrote: > Dear All, > > I made a small JavaFX app for small non-techie

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

I'm not saying a preloader is really a requirement, but I know of a few applications that are using it and benefiting from it. The preloader functionality is more than just a splash screen, and I see this valuable for instance when static initializers of classes that are used in the main class

Re: OpenJFX code review policies, etc.

On Thu, May 31, 2018 at 11:25 PM Kevin Rushforth wrote: > > > On 5/24/2018 9:31 AM, Nir Lisker wrote: > > Thanks for the detailed plan Kevin, > > > > ... > > > > Can you give the guidelines by which a lead reviews / approves one of > > the above? > > Ultimately it will be a judgment call. I

webrev for JDK-8202396

The webrev for the memory leak in the iOS imageloader, which is fixed by https://github.com/javafxports/openjdk-jfx/pull/73/commits/7f264eda17fc91aedfa47e60ffa4a096a4904350 is available at http://cr.openjdk.java.net/~jvos/8202396/webrev.00/ Is is a simple 2-line fix that is reviewed in the github

Re: OpenJFX code review policies, etc.

00-2515-37330ee0c...@oracle.com> > > Content-Type: text/plain; charset=utf-8; format=flowed > > > > To: OpenJFX Developers > > > > As I mentioned in a message last week [1] I would like to restart the > > discussion we started a few months ago [2] around making

modules for repositories

When we create modules that are expected to be uploaded to e.g. maven central or bintray, we have to create jar's with native libs. That is technically possible (see http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021887.html) but before I can finalise PR #83 (

Re: OpenJFX status update

Hi Kevin, Related to point 3: what exactly do you mean with "Java FX has been removed from JDK 11"? It isn't part of the OpenJDK 11-ea13 either so I don't see the difference? I thought references to JavaFX would be removed from sun.launcher.LauncherHelper, but they are still there. Do you know

Re: bundling native libs in jars or modules

05.2018 um 21:50 schrieb Tom Schindl <tom.schi...@bestsolution.at>: >> >> Did you check how SWT does addresses the problem? If you run it outside >> of OSGi it needs to deal with this problem as well. >> >> Tom >> >> Von meinem iPhone gesendet >>

bundling native libs in jars or modules

Note: This is different from what is discussed in http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021762.html The following text is about bundling native code within a jar, and doesn't talk about how to deal with platform-specific libraries in generic jar files. At this moment, the

Re: Announcing EA builds of standalone JavaFX SDK

Hi Kevin, Excellent work. I confirm this is working for me. Java: openjdk 11-ea+12 for Linux App from https://github.com/gluonhq/projavafx9/tree/master/chapter1/HelloEarthRise/src/main/java/projavafx/helloearthrise/ui (on classpath) - Johan On Tue, May 8, 2018 at 1:11 AM Kevin Rushforth

clinit and threads

Hi, For a number of reasons, I'm looking into using SubstrateVM to bundle a JavaFX application into a native executable. The SubstrateVM relies on an AOT that's more aggressive than Gluon VM and it will precompile class initializers. I clearly see the (performance) benefits of this, but it has

Re: native libs in modules

FYI, the native-libs-in-mods issue is being discussed on the panama-dev list as well: http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001543.html - Johan On Tue, May 1, 2018 at 6:01 PM Kevin Rushforth wrote: > > > On 4/30/2018 8:58 AM, Michael Paus

Re: Bug in SceneBuilder 9

Hi Sverre, I think the best place to submit this issue is here: https://bitbucket.org/gluon-oss/scenebuilder/issues?status=new=open - Johan On Wed, May 2, 2018 at 10:15 AM Sverre Moe wrote: > I think I have found a bug in SceneBuilder 9. > > I cannot find an existing bug

Re: Paint Phase Debugging / Performance

Hi Matthew, I agree this is a very important question. I don't like it when people say that "JavaFX is slow" because if everything is done right, JavaFX can be extremely fast. But I also realise that it is very easy to make things very slow in JavaFX, and in case "performance" is slow, it is

Re: native libs in modules

I'd love to hear a general recommendation from the jigsaw team as well. Clearly, there are a number of solutions, and as a developer, I easily get confused if some frameworks do it with option A and others with option B. So what is the preferred approach in general? It seems (given the large size

Re: native libs in modules

subject or body 'help' to > >> openjfx-dev-requ...@openjdk.java.net > >> > >> You can reach the person managing the list at > >> openjfx-dev-ow...@openjdk.java.net > >> > >> When replyin

native libs in modules

Now that the OpenJFX SDK that works with Java 11 is about to be released in EA, we should think about releasing the modules. In case you download the OpenJFX SDK, running an app goes like java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app If you use gradle or maven, the

COMPILE_SWING defaults to false

Before pushing http://cr.openjdk.java.net/~jvos/8195669/webrev.00/rt.patch as a fix for JDK-8195669 (see https://github.com/javafxports/openjdk-jfx/pull/58) I want to double check that it is fine that COMPILE_SWING defaults to false ? - Johan

fix for https://bugs.openjdk.java.net/browse/JDK-8199765

Can someone review/ack the simple PR for https://bugs.openjdk.java.net/browse/JDK-8199765 ? Thanks, - Johan

Re: OpenJFX GitHub mirror

com> > >> > >>> a écrit : > >>> > >>> > >>>> I think this would be fine. We would want something that didn't > conflict > >>>> with anything else and wasn't confusing. Possible choices: > >>>> > >>>> github-lin

Add missing styleable properties to ImageView?

There is a discussion on an issue at github whether some properties on ImageView need to be css-styleable: https://github.com/javafxports/openjdk-jfx/issues/29 As not everybody is checking those issues, I want to bring this under the attention of the list, as it has important consequences (once

Review request: 8200300: better gradle error message

Please review the webrev http://cr.openjdk.java.net/~jvos/8200300/webrev.00/ which fixes https://bugs.openjdk.java.net/browse/JDK-8200300

Re: [11] Review request: 8199841: Add gradle wrapper files to build

Looks good. - Johan On Thu, Mar 29, 2018 at 6:40 PM Kevin Rushforth wrote: > Hi Johan, > > Please review the following to add gradle wrapper: > > https://bugs.openjdk.java.net/browse/JDK-8199841 > http://cr.openjdk.java.net/~kcr/8199841/webrev.00/ > > This is the

Re: OpenJFX GitHub mirror

Hi Nir, About 4. (jfx-dev): you're right, I just removed that repository. That was just some testing before we did the real thing. As for the other points: I agree - Johan On Mon, Mar 26, 2018 at 12:03 PM Nir Lisker wrote: > Hi All, > > A few comments about the mirror and

modules versus SDK's

Hi, I want to start a discussion on distributing JavaFX as an SDK versus distributing its modules via the traditional build and distribution mechanisms. Personally, I think relying on an SDK is too much a barrier. It requires users to manually download software from the exact right place, and

Re: [11] Review request: JDK-8196617: FX print tests fail with NPE in some environments

I checked this as well, and even without checking you can see why this fixes the tests (on Windows, with the PseudoPrinter). This is a very important commit, as it fixes the automated build on Windows, which makes it much easier to make progress without regression. - Johan On Wed, Mar 21, 2018

Gradle wrappers

Hi, Using Gradle wrappers has been discussed a number of times, but there was never a clear resolution afaik. Andres opened an issue for using gradle wrappers: https://github.com/javafxports/openjdk-jfx/issues/23 I personally like gradle wrappers myself, it makes it easier to automate builds

webrev for locale javadoc

The very simple webrev for https://bugs.openjdk.java.net/browse/JDK-8199675 is here: http://cr.openjdk.java.net/~jvos/8199675/webrev.00/ I'll commit once approved (adding the contributed-by smanux (Emmanuel Bourg) )

Re: Repositories, AdoptOpenJDK and github

wse/JDK-8198795 >> >> I pointed out some prerequisites for doing this in JBS (and Nir expressed >> concern as well), but yes, this might be a good one to start with. >> >> -- Kevin >> >> >> Johan Vos wrote: >> >> I agree with this approach. >

Re: Repositories, AdoptOpenJDK and github

e the risk of conflicts (code merge) > > My 2 cents... > > Let's go on, > "We are the champions..." > > Laurent > > > Le 28 févr. 2018 9:15 AM, "Johan Vos" <johan@gluonhq.com> a écrit : > > That is the difficult point indeed. > Bu

github contributor guidelines

We now have a Github mirror, and good github projects require clear guidelines. Eugene created the following proposal for guidelines, based on standard guidelines from other projects, but including the link to JBS: https://github.com/johanvos/openjfxorg/blob/master/CONTRIBUTING.md Comments

Re: Repositories, AdoptOpenJDK and github

tch had been reviewed, it is committed to the Oracle >> repo. Since GitHub mirrors Oracle I don't think it matters if the patch is >> merged into GitHub. >> >> This ensures that: >> * It's easier to start working because the GiutHub repo is more >> convenient th

Re: Repositories, AdoptOpenJDK and github

On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth wrote: > > As I said before, we need to be careful where the discussion is made. PRs > on GitHub have their own thread and there's also the mailing list. Maybe > someone from Oracle already has done work related to the

Re: Repositories, AdoptOpenJDK and github

ndboxers to test their code on all 3 major supported > platforms: Linux, macOS, and Windows. > > Regards, > Michael > > On Wed, Feb 14, 2018 at 8:14 AM, Johan Vos <johan@gluonhq.com> wrote: > >> Hi, >> >> I did 2 things: >> * I tal

Repositories, AdoptOpenJDK and github

Hi, I did 2 things: * I talked to the fine and great people at AdoptOpenJDK ( https://adoptopenjdk.net/) and they are happy to have their build farm being used to create OpenJFX modules (including the native libraries). We are currently looking at the scripts that are being used for syncing and

Re: The "javafx might not be present" problem

Hi Mark, Is using jlink (https://docs.oracle.com/javase/9/tools/jlink.htm) packaging your app with the exact set of modules you need an option for you? That would eliminate the need for your users to have Java installed. Not only there is a (small) hurdle to install Java, but it needs to be the

Re: future content of OpenJFX

> Steve > > > > Sent from my iPhone > > On Feb 7, 2018, at 2:47 AM, Johan Vos <johan@gluonhq.com> wrote: > > While it's good to know who is interested in what areas, I think it's hard > to create a list of interested or capable people as that depends on >

Re: future content of OpenJFX

e money to fund the development of their > wishlist, fine, that's the easy part, but asking people to contribute time > is a bit more complicated. For example, I may want "more alignment with > mobile", but I may be better qualified to contribute "extensions for the > Chart

future content of OpenJFX

In order to separate the "What" from the "How" (discussed in another thread), I would like to start a discussion about what people think should be considered for future JavaFX work. I'd like to start with what I think is an important note on the context. If I want feature X in JavaFX, I ask

Re: More community participation in JavaFX

Hi Michael, This proposal is very much in line with my thinking as well. The problem is not that we don't have a github clone of OpenJFX. We have a number of them (e.g. I created https://github.com/javafxports/jfx-dev some months ago). We just need a single one that is updated constantly from

Re: lipjpeg7 in static library

> > > > > Not a complete answer but maybe somewhere to start. > > > > -phil. > > > > On 01/24/2018 02:42 AM, Johan Vos wrote: > >> Hi, > >> > >> We are currently building a native library for javafx_iio which includes > >&

lipjpeg7 in static library

Hi, We are currently building a native library for javafx_iio which includes libjpeg7. As a consequence, those symbols are included in the static libjavafx_iio.a on iOS. If we add other libraries (e.g. OpenCV) this can result in duplicate symbols, as the libjpeg7 library might be included in

Re: CSS reference URL?

Thanks David and Kevin, your work is very much appreciated. - Johan On Fri, Dec 8, 2017 at 3:24 PM David Grieve <david.gri...@oracle.com> wrote: > > https://docs.oracle.com/javase/9/docs/api/javafx/scene/doc-files/cssref.html > > > On 12/8/17 8:46 AM, Johan Vos wrote: &g

CSS reference URL?

Hi, Our Pro JavaFX 9 book is about to be published, and it will contain links to online resources. One very useful resource is the CSS reference. For JavaFX 8, this was at https://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html but I can't find it for JavaFX 9 so far? -

Re: [10] Review request: 8185923: Bump minimum gradle version to 4.3 for JDK10

FWIW, I'm +1 on this. We're using 4.3.1 for building JavaFX on mobile. - Johan On Thu, Nov 30, 2017 at 6:36 PM Kevin Rushforth wrote: > Hi Phil, > > Please review the following fix to make gradle 4.3 the minimum version: > >

Re: javah deprecated?

Hi Johan, > > Thanks for filing the bug. > > If we really do need Character and IDN, then the cleanest approach might > be to define new fields in a suitable JavaFX class and assign the > appropriate values to them. > > > -- Kevin > > > > Johan Vos wrote: > &g

Re: javah deprecated?

The headers are required indeed. modules/javafx.web/src/main/native/Source/WTF/wtf/unicode/java/UnicodeJava.h includes java_lang_Character.h in order to access the static final fields in Character.java - Johan On Thu, Nov 30, 2017 at 12:07 PM Johan Vos <johan@gluonhq.com>

Re: javah deprecated?

I'll find out if they are needed on linux. - Johan On Thu, Nov 30, 2017 at 11:42 AM Johan Vos <johan@gluonhq.com> wrote: > I filed a bug (https://bugs.openjdk.java.net/browse/JDK-8192806) and I am > looking into it. > > It seems a bit weird to me that the java.lang.Characte

Re: javah deprecated?

lock us from moving to JDK 10 as a boot > JDK, so if we end up doing that for JDK 10 then this would need to be > done soon. > > Let me know if you would like to work on this. > > Thanks. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8161704 > &g

javah deprecated?

Hi, I learned javah might be removed in Java 10 ( http://openjdk.java.net/jeps/313) but as far as I know, it is still used in OpenJFX: defineProperty("JAVAH", cygpath("$JDK_HOME/bin/javah${IS_WINDOWS ? '.exe' : ''}")) Are there already plans to move to javac -h instead? It seems a relative easy

Re: [PATCH] 8182572 Numpad keys not working with JavaFX Monocle

That patch looks ok for me, and it doesn't break anything in the Android build (the other consumer of Monocle). - Johan On Wed, Sep 20, 2017 at 6:45 PM Milan Fabian wrote: > Hello, > > I have prepared patch (attached) for bug JDK-8182572 ( > http://bugs.java.com/ >

<    4   5   6   7   8   9   10   >