Bug 1145303 - RFE: JavaFX
RFE: JavaFX
Status: NEW
Product: Fedora
Classification: Fedora
Component: java-1.8.0-openjdk (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Mario Torre
Fedora Extras Quality Assurance
: FutureFeature
: 1234168 (view as bug list)
Depends On:
Blocks: MSearch MediathekView
  Show dependency treegraph
 
Reported: 2014-09-22 15:15 EDT by Ali Akcaagac
Modified: 2017-02-23 09:00 EST (History)
49 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tos-issue.png (382.53 KB, image/png)
2014-09-22 16:06 EDT, Ali Akcaagac
no flags Details

  None (edit)
Description Ali Akcaagac 2014-09-22 15:15:31 EDT
Please find my problem description for thinkorswim, which I sent to them a couple of days ago:

;-----------------------------------------------------------------------------
Hello,

I would like to address an issue with your tos platform and hope for a quick solution.

Yesterday I downloaded tos from this page:

https://mediaserver.thinkorswim.com/installer/install.html

https://mediaserver.thinkorswim.com/installer/InstFiles/thinkorswim_installer.sh

and installed it under Linux Fedora 20 to be specific. The installation went smoothly so far.

I have chosen to install the software "for this user" and have "ameritrade" chosen from the offered brokers. I also allowed the installer to create a desktop icon. Start "tos" after installation complete. Installation path is the homedir.

Now a small splash-screen popped up because tos got started. this thing informed me that it's "Installing updates...".

From what I was able to see within the ~/thinkorswim directory it was downloading the update for the suit (from 1858.9 to 1864.42) and usergui (1864.54).

After the downloadprocess has been completed (all files from usergui have been catched) the splash-screen keeps saying "Installing updates...".

Regardless what you do, this thing is the first that shows up. Always "Installing updates...".

I removed the tos directories and tried to re-install everything from scratch (all java processes including tos has been killed). Same issues.

I believed that this might be an issue from the java version provided by Fedora 20 which is:

java-1.7.0-openjdk-1.7.0.65-2.5.2.5.fc20.i686

So I tried installing

java-1.8.0-openjdk-1.8.0.11-9.b12.fc20

Same issues. I went to the Oracle site and downloaded the JDK package from their site and installed that one. Same issues.

Rebooting the machine a couple of times and re-tried above steps under different scenarios. Same issue.

The popup still says "Installing updates..." and seem to be stuck with it.

Therefore I believe that this might be a software related issue. I know that tos works on this machien because I have successfully been testing it a couple of months before with a demo-account.

I like to make sure that I even tried to install tos on a brand new and fresh installation of Fedora. Same issues.

The logs for "suit" and "usergui" don't contain anything strange. No issues with NULL Pointer or similar breakage. To be specific: No known errors. No firewall running. No ports blocked.

Please find attached a screenshot of the issue.

Greets

Ali Akcaagac
;-----------------------------------------------------------------------------

No screenshot here.

The problem is that I had issues with OpenJDK 1.7 and 1.8, then tried JDK from Oracle. Sadly it was interfering with my OpenJDK installation (which I use for development). After a while I retried JDK (better JRE) from Oracle and this thing worked. After some deeper investigation I figured out that thinkorswim requires JavaFX, which the Java Oracle Version provides.

I am not sure how the license situation for JavaFX is but this is really a messy situation as it is now.
Comment 1 Deepak Bhole 2014-09-22 15:40:54 EDT
I don't think JavaFX is fully open-source yet, and there are additional issues such as the complex build system, that hinder addition to Fedora.

I am adding Mario Torre to cc: as he has tried building JavaFX for Fedora before.

Mario, what is the current status of OpenJFX, and what stands in the way of introducing it into Fedora?
Comment 2 Ali Akcaagac 2014-09-22 16:06:37 EDT
Created attachment 940157 [details]
tos-issue.png

I just received a mail from tech support of the TOS platform. They suggested me to try Oracle JRE / JDK once again -> which I already figured out myself. Sadly their platform gave me issues for the entire weekend because no proper output of missing JavaFX. Also included the "screenshot". Not that it helps much.
Comment 3 Ali Akcaagac 2014-09-22 19:35:38 EDT
After some digging I found this here:

http://pkgs.org/fedora-centos-rhel-opensuse-mandriva/olea/java-1.7.0-oracle-javafx-1.7.0.21-1.0.cf.i586.rpm.html

Which directs me to this here:

http://olea.org/paquetes-rpm/repoview/letter_j.group.html

http://olea.org/paquetes-rpm/repoview/java-1.7.0-oracle-javafx.html

Looks like someone made *.rpm packages for exactly the missing files. Nonetheless they are somehow outdated and needs some love.

What would be nice is to have something similar:

java-1.7.0.xx-openjdk.rpm
java-1.7.0.xx-openjdk-headless.rpm
java-1.7.0.xx-openjdk-devel.rpm
java-1.7.0.xx-openjdk-javafx.rpm

Same for 1.8.x
Comment 4 jiri vanek 2014-09-23 04:29:12 EDT
It cant be done. As Deepak wrote, the javfx is not yet fully opensourced. So the FX  binaries, which are in oracle java can not magically appear in openjdk packages. Once they are, I will follow the same file sorting as I'm using for Oracle java for Rhel.  And so there will be java-1.8.0-javafx
Comment 5 Mario Torre 2014-09-23 05:59:37 EDT
RE JavaFX:

We can't officially support the closed JavaFX binary, the same way as we don't offer closed JDK binary RPM in Fedora.

I didn't look at the Mandriva package, but by the naming convention I think is exactly the pre-packaged version of the *closed* JavaFX that *only* works with the *closed* JDK (which is quite likely a dependency).

OpenJFX is now fully open sourced, it can be compiled by yourself and should work well with the OpenJDK 8 that we ship in Fedora. However, packaging it is a different story, because it depends on Gradle that is not available in Fedora and is also specific to OpenJDK 8, although this has now been officially released so is less of a blocker.

Note that the closed JavaFX '7' is not compatible with OpenJDK (so even if you just download the jar from somewhere it won't work), it does certain assumptions on the host platform and there's no easy way to make it run. Some people have done an unofficial OpenJFX fork that works with OpenJDK 7, but I don't know what the state of that.

Re thinkorswim:

Are you sure it needs JavaFX? By the look of it it seems like it's only using Swing (and the release notes say it requires Java 6, if this is correct it's surely not a JavaFX application). We would need a log of what's going on, but the closed nature of the application will make it quite hard to figure out what's the issue.
Comment 6 Severin Gehwolf 2014-09-23 06:16:40 EDT
(In reply to Mario Torre from comment #5)
> OpenJFX is now fully open sourced, it can be compiled by yourself and should
> work well with the OpenJDK 8 that we ship in Fedora. However, packaging it
> is a different story, because it depends on Gradle that is not available in
> Fedora and is also specific to OpenJDK 8, although this has now been
> officially released so is less of a blocker.

Right. According to [1] Gradle has been retired in F20 and up. So it would mean to a) port OpenJFX's build to some other build system such as maven or b) unretire Gradle and maintain it. Note that Gradle has been notorious to do strange things which makes it hard to maintain[2]. Not sure how hard option b) would be.

[1] https://admin.fedoraproject.org/pkgdb/package/gradle/
[2] https://lists.fedoraproject.org/pipermail/java-devel/2013-October/004979.html
Comment 7 Mario Torre 2014-09-23 06:27:41 EDT
(In reply to Severin Gehwolf from comment #6)
> (In reply to Mario Torre from comment #5)
> > OpenJFX is now fully open sourced, it can be compiled by yourself and should
> > work well with the OpenJDK 8 that we ship in Fedora. However, packaging it
> > is a different story, because it depends on Gradle that is not available in
> > Fedora and is also specific to OpenJDK 8, although this has now been
> > officially released so is less of a blocker.
> 
> Right. According to [1] Gradle has been retired in F20 and up. So it would
> mean to a) port OpenJFX's build to some other build system such as maven or
> b) unretire Gradle and maintain it. Note that Gradle has been notorious to
> do strange things which makes it hard to maintain[2]. Not sure how hard
> option b) would be.
> 
> [1] https://admin.fedoraproject.org/pkgdb/package/gradle/
> [2]
> https://lists.fedoraproject.org/pipermail/java-devel/2013-October/004979.html

The problem is also that JavaFX have been updating their gradle version a few times over their development lifetime, which makes it harder for downstream. I've been thinking to port the build infrastructure like we did for OpenJDK at the beginning.

I'll meet the JavaFX people at JavaOne and see what they think about that. Moving away from Gradle would help downstream which ultimately means broather adoption of JavaFX, but I don't know if they want to go that way, given the considerable amount of effort they've been putting into the build machinery already.
Comment 8 Ali Akcaagac 2014-09-23 06:32:16 EDT
(In reply to Mario Torre from comment #5)
> RE JavaFX:

Thanks for your feedback and the indepth explaination.

> Re thinkorswim:
> 
> Are you sure it needs JavaFX? By the look of it it seems like it's only
> using Swing (and the release notes say it requires Java 6, if this is
> correct it's surely not a JavaFX application). We would need a log of what's
> going on, but the closed nature of the application will make it quite hard
> to figure out what's the issue.

Well I am not 100% sure. What I can tell is, that the thinkorswim platform used to work under Fedora 18 and OpenJDK 1.6. I abandoned the platform for a while and was using something else. Now with Fedora 20 and OpenJDK 1.7 things look different. They have changed a bunch of stuf like GUI appearance and embedded some media stuff inside the code. I spent the entire weekend to get that thing running and it only operates well with Oracles JRE/JDK. After some google I figured out that some forum people mentioned it requires features provided by JavaFX.

What I could have done is this: Check all the classes for traces to JavaFX methods or class calls. I have written some code for it a couple of years ago which dives into all classes and spit out the methods to stdout. Unfortunately - and for personal reasons (also related with my former eployer) I have abandoned all my work as Java developer 2 years ago and now focus on daytrading.

Life changes!
Comment 9 Ali Akcaagac 2014-09-23 07:14:51 EDT
I found someone else reporting same issue:

reference: http://lists.opensuse.org/opensuse/2014-06/msg00667.html

;-----------------------------------------------------
java.lang.RuntimeException: Unexpected error!
at com.devexperts.tos.ui.user.login.LoginDialogFXUtils.runAndWait(LoginDialogFXUtils.java:110)
at 
com.devexperts.tos.ui.user.login.LoginDialogFX.<init>(LoginDialogFX.java:107)
at com.devexperts.tos.ui.user.login.StartupUtils$3.run(StartupUtils.java:247)
;-----------------------------------------------------

Looks like their login dialog depends on FX. Either this was a practical decision to style their GUI or a tactical decision to remove complexity from their technical support. Tactical decision could be to enforce Oracle Java to make sure everyone is using the same stuff, same compatibility, same output, avoid lawsuits because of lost money or something similar, avoid guiding and/or struggling through OpenJDK (problems if exist). Sadly I wasn't able to find a trace towards JavaFX within the thinkorswim logs.
Comment 10 Max Rydahl Andersen 2014-10-02 06:22:44 EDT
Being able to use JavaFX from java apps would really be nice. 

netbeans uses it.
jboss tools uses it.

For now we are forced to recommend users to install oracle jdk if they want to benefit from it ;/
Comment 11 Mario Torre 2014-10-06 10:35:06 EDT
I'm taking the bug, I guess it's time to look again at integrating OpenJFX into Fedora.
Comment 12 Andrew John Hughes 2014-10-06 19:33:49 EDT
I've been following this too, and I think we need a sane build for this at the distro-agnostic level. Hopefully, I'll find some time to take a look after the current security update.

A glance over the existing build shows that there is native code in there, plus dependencies, which will need cleaning up.
Comment 13 Jason Tibbitts 2014-10-07 16:04:27 EDT
Just lurking because I'd like to run Geogebra on free Java, but it wants JavaFX:

14:54:37.388 ERROR: geogebra.gui.Q.X[-1]: JavaFX 2.2 not available

It seems to mostly run without it but I'm not familiar enough with Geogebra to know what's missing.
Comment 14 Julien Gouesse 2014-11-03 05:25:19 EST
Hi

I don't want to encourage the end users to install Oracle Java. OpenJFX is already available for Ubuntu and Debian:
https://packages.qa.debian.org/o/openjfx.html

What is missing to do the same for Fedora (and Mageia)? Gradle? Is it possible to build OpenJFX without Gradle? Maybe we can generate Ant or Maven scripts from Gradle scripts. I just ran "gradle init" in the directory containing the main pom file when I wanted to generate the Gradle script for a Maven project.
Comment 15 Julien Gouesse 2014-11-03 05:30:47 EST
Severin Gehwolf's suggestion might be viable, look at the section 47.3.1 about the conversion of an Apache Maven build to a Gradle build:
http://www.gradle.org/docs/current/userguide/build_init_plugin.html
Comment 16 Julien Gouesse 2014-11-03 05:47:01 EST
alien can be used in the meantime to convert the Debian packages into RPM packages:
http://pkgs.org/fedora-20/fedora-i386/alien-8.88-4.fc20.noarch.rpm.html
http://manpages.ubuntu.com/manpages/raring/en/man1/alien.1p.html

Of course, it's not a clean solution.
Comment 17 Ali Akcaagac 2014-11-03 06:21:20 EST
(In reply to Julien Gouesse from comment #14)
> I don't want to encourage the end users to install Oracle Java.

I am the first to encourage end users to install Oracle Java. Simply because it just works and offers rpm Packages that installs clean into my Fedora 20 system.

> alien can be used in the meantime to convert the Debian packages into RPM
> packages:
> 
> Of course, it's not a clean solution.

Your last sentence is the right answer why I would encourage end users to do so. There are people who want to use the system and not waste too much time in administration. Oracle Java offers this out of the box as it is now.
Comment 18 jiri vanek 2014-11-03 06:26:10 EST
I'm wondering how you run the stack of java applications on Oracle JDK?
Comment 19 Julien Gouesse 2014-11-03 06:42:43 EST
(In reply to Ali Akcaagac from comment #17)
> (In reply to Julien Gouesse from comment #14)
> > I don't want to encourage the end users to install Oracle Java.
> 
> I am the first to encourage end users to install Oracle Java. Simply because
> it just works and offers rpm Packages that installs clean into my Fedora 20
> system.
> 
I'm sorry, I don't want to turn this bug report into a OpenJDK vs Oracle Java debate and I have a completely different opinion about the reliability of the packages provided by Oracle/Sun Microsystems for GNU Linux in general.

> > alien can be used in the meantime to convert the Debian packages into RPM
> > packages:
> > 
> > Of course, it's not a clean solution.
> 
> Your last sentence is the right answer why I would encourage end users to do
> so. There are people who want to use the system and not waste too much time
> in administration. Oracle Java offers this out of the box as it is now.

This bug report talks about java-1.7.0-openjdk. My suggestion has a chance to work with java-1.8.0-openjdk. OpenJFX/JavaFX will be fully integrated into Java 1.9 anyway as far as I know and no longer installed as an extension. The current situation is a bit annoying. My workaround is only a pragmatic temporary solution to go on using OpenJDK and to benefit of OpenJFX.
Comment 20 Ali Akcaagac 2014-11-03 07:32:53 EST
(In reply to jiri vanek from comment #18)
> I'm wondering how you run the stack of java applications on Oracle JDK?

I run a stripped down version of Fedora 20 with XFCE4 only (approx 720 packages) and install packages on demand. Rather than uninstalling everything again I usually keep a tar.bz2 of the stripped installation and untar it in a chroot and replace it with root (automated process).

My demand for java is only for thinkorswim and freemind (upstream bin/tar files). No further dependencies of openjdk required. No other programs depending on java. If I'd go back using freemind from Fedora 20 repo then it starts installing the whole rattail of things I don't need.

But sure I agree that a nice openjfx version is required. But for Fedora 20 I need it now with java 1.7 which is a requirement for thinkorswim. You might understand that I need some sort of reliability to run my business. I can't rely on openjdk 1.7 without openjfx support. Nor do I want to install openjdk 1.8 when it's clearly stated that thinkorswim mandatory says 1.7.

So all it does is running X, XFCE, Java, ThinkOrSwim. The rest is &> /dev/null
Comment 21 Fedora End Of Life 2015-05-29 08:56:33 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 22 Severin Gehwolf 2015-06-22 04:33:02 EDT
Resetting component to java-1.8.0-openjdk since there is no java-1.7.0-openjdk in F22.
Comment 23 Severin Gehwolf 2015-06-22 04:34:05 EDT
*** Bug 1234168 has been marked as a duplicate of this bug. ***
Comment 24 Mikolaj Izdebski 2015-06-22 05:47:03 EDT
Gradle 2.2 is now available in Fedora 22, with Gradle 2.4 in rawhide. We (Gradle maintainers) can help porting OpenJFX build scripts from Gradle 1.x to 2.x
Comment 25 Gabriel Féron 2015-06-25 08:52:30 EDT
I just created a COPR repository to host a package for OpenJFX. It's using Gradle 1.8 so this particular version is included in the SRPM.

See here: https://copr.fedoraproject.org/coprs/gferon/openjfx/
Comment 26 Parag Nemade 2015-07-02 04:56:48 EDT
Thank you Gabriel for copr repository. I at least got the jar file running on Fedora 22. But the jar application that I got is having button to add new row in the form for adding additional information. When I click on it, jar file application crashes with error

java: symbol lookup error: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.45-40.b14.fc22.x86_64/jre/lib/amd64/libjfxwebkit.so: undefined symbol: _ZN3JSC8JSObject45putByIndexBeyondVectorLengthWithoutAttributesILh20EEEvPNS_9ExecStateEjNS_7JSValueE
Comment 27 Gabriel Féron 2015-07-04 06:06:07 EDT
Seems to be an issue with GCC 5 / Webkit (see here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292)

I'll try to find a way around this bug in a week or so, either by compiling libjfxwebkit with an earlier GCC version, or by applying the CPP patch to Webkit before compiling the library.
Comment 28 Mikolaj Izdebski 2015-07-07 07:34:44 EDT
I've ported OpenJFX build script to latest Gradle and built it in offline mode.
The results are at https://github.com/mizdebsk/newpkg/tree/openjfx
See also: https://lists.fedoraproject.org/pipermail/java-devel/2015-July/005635.html
Comment 29 Pavel Alexeev 2016-01-25 04:24:17 EST
Mikolaj do you have copr or other repo for such builds?
Comment 30 Mikolaj Izdebski 2016-01-25 06:14:59 EST
(In reply to Pavel Alexeev from comment #29)
> Mikolaj do you have copr or other repo for such builds?

No, because my build was proof of concept only - it was never meant to be used.
Comment 31 Marek Novotny 2016-02-23 04:48:03 EST
Could we get something from https://wiki.openjdk.java.net/display/OpenJFX/Community+Builds into Fedora?

This status quo while Fedora is trying to get developer minds is really bad IMHO.
Comment 32 Jiri Konecny 2016-03-03 07:29:07 EST
Are you going to package OpenJFX to some Fedora release?
Comment 33 Mario Torre 2016-03-14 07:40:20 EDT
(In reply to Jiri Konecny from comment #32)
> Are you going to package OpenJFX to some Fedora release?

We are investigating this possibility.
Comment 34 Christian Stadelmann 2016-08-12 06:04:02 EDT
Missing OpenJFX also prevents MediathekView¹ from running. Any update on this?

¹ http://zdfmediathk.sourceforge.net/
Comment 35 Vitaliy Gribko 2016-08-28 07:10:02 EDT
Needed OpenJFX package for Fedora 24 too.

Please, add it. Ubuntu 16.04 already have OpenJFX packages in repository.
Comment 36 Brallan Jesús Aguilar Rivera 2016-09-06 19:52:54 EDT
(In reply to Marek Novotny from comment #31)
> Could we get something from
> https://wiki.openjdk.java.net/display/OpenJFX/Community+Builds into Fedora?
> 
> This status quo while Fedora is trying to get developer minds is really bad
> IMHO.

I am asking the same T.T
Comment 37 Mario Torre 2016-09-07 10:02:30 EDT
(In reply to Vitaliy Gribko from comment #35)
> Needed OpenJFX package for Fedora 24 too.
> 
> Please, add it. Ubuntu 16.04 already have OpenJFX packages in repository.

You're welcome to contribute :)

Regarding Ubuntu, I didn't try the Ubuntu packages in a while, but last time I checked they were not complete. Unfortunately we need some extra deps to get the full build of OpenJFX, it doesn't make a lot of sense to have a package that is half working.

It also requires a lot of collaboration to ensure that the latest security updates are delivered efficiently, not to speak about the fact that OpenJFX depends on a specific version of OpenJDK, so we need to make this package a subpackage of OpenJDK, which is not really a good idea.

It makes more sense for users to build it themeselves and use whatever bits they need instead. Building JavaFX is very easy.
Comment 38 Andrew John Hughes 2016-09-07 11:31:02 EDT
Looking at the repositories, you'd probably need to branch your own repository before even making a start, as there is no tree matching the current release, or at least be very careful to bundle the right tag. At present, the OpenJFX which matches java-1.8.0-openjdk would be the tag http://hg.openjdk.java.net/openjfx/8u/rt/rev/10037acb5c7a, not the tip of that repository.

We have the same issue with OpenJDK 8u upstream, and aarch64/jdk8u (OpenJDK 8u + AArch64 port) follows release tags rather than pulling the whole of 8u.
Comment 39 Gabriel Féron 2016-09-07 12:23:02 EDT
Thank you for this precision regarding the right tag!

I guess I'll adapt the spec file I wrote nearly a year ago and try publishing a fully working package on COPR again. (this is the spec file I wrote at the time https://raw.githubusercontent.com/gferon/openjfx-fedora/master/openjfx.spec)
Comment 40 Fedora End Of Life 2016-11-24 06:14:02 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 41 Erik Streb del Toro 2016-12-11 09:26:02 EST
Any news on this? Where is the testpackage?
Comment 42 Steevithak 2016-12-22 21:12:13 EST
I'm trying to install TD Ameritrade's Think-or-Swim trading program on my Fedora workstation and ran into the same problem as the OP. After the "installing updates" dialog, the installer dies with this error message:

  Missing JavaFX in Java
  Please set Oracle Java 8 as default java for thinkorswim
  Java must include JavaFX and Oracle Java 8 has it, but OpenJDK 8 has not.

TD's tech support says I should switch to Ubunutu because it "works fine" there (haha, that's not going to happen!) :) Any chance we'll have a fix or work-around for this in the near future? Or has anyone figured out a way to make it work? I'm not a Java person, so I don't quite grok the difference between OpenJDK, JavaFX, and Java. Is there a different Java package I can install via dnf that will fix this?
Comment 43 Christian Stadelmann 2016-12-23 02:11:37 EST
(In reply to Steevithak from comment #42)
> Any chance we'll have a fix or work-around for this in the near future? Or has anyone figured out a way to make it work?

There are experimental builds. Just have a look at the github URLs above.

> I'm not a Java person, so I don't quite grok the difference between OpenJDK, JavaFX, and Java.

OpenJDK is the reference implementation for the Java standard library. JavaFX is an additional library with a referenence implementation (OpenJFX) inside the OpenJDK, but it is 

> Is there a different Java package I can install via dnf that will fix this?

You could download the oracle java bundle from https://www.java.com/en/download/linux_manual.jsp , which has no support from Fedora. This is the implementation of Java from Oracle, the main developer of Java, mostly identical to OpenJDK. It might contain some proprietary code (did so in the past). It misses a few patches OpenJDK has on Fedora: https://src.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/
Comment 44 Stefan Neufeind 2016-12-23 06:30:51 EST
I've manually updated the spec from https://github.com/gferon/openjfx-fedora/ to 8u111_b14. Build itself seems to run fine but then finally fails for me with:

cp -f generated/InspectorJSFrontendDispatchers.h
cp -f generated/InspectorJSBackendDispatchers.h
cp -f generated/InspectorJSTypeBuilders.h
cp: missing destination file operand after 'generated/InspectorJSFrontendDispatchers.h'
Try 'cp --help' for more information.
cp: missing destination file operand after 'generated/InspectorJSBackendDispatchers.h'
Try 'cp --help' for more information.
cp: missing destination file operand after 'generated/InspectorJSTypeBuilders.h'
Try 'cp --help' for more information.

Since the build went fine I expect that's a minor glitch? (which I just didn't yet figure out how to fix)

It would be great to get that build working again. I expect we're 90% there already?
Comment 45 Gabriel Féron 2016-12-23 07:49:15 EST
This is exactly the error that stopped me from updating the SPEC file I wrote a while ago... You can build without Webkit support in the meantime by setting COMPILE_WEBKIT = false. I already disabled media support a few months ago because it requires libraries only available in RPMfusion.
Comment 46 Stefan Neufeind 2016-12-23 08:30:54 EST
I've tried that. But that build again fails for me. Maybe somebody knows more about that building-process.
Comment 47 Steevithak 2016-12-23 14:55:06 EST
This may be a dumb question but if this is already fixed on Ubuntu (according to TD, think-or-swim runs on the current Ubuntu version), wouldn't it be possible for Fedora developers to have a peek at how Ubuntu got JavaFX compiling/working and copy those changes over to Fedora's Java code?

Also, thanks for the suggestions on how I could get this running but I rely on my Fedora box for work, so I'm not thrilled with the idea of replacing the supported version of java with a new one I download and compile myself. I'm afraid that I might break something important. I'm content to wait for the next rev of Fedora if necessary.
Comment 48 Jonny Heggheim 2016-12-30 14:44:29 EST
I need openjfx for bitsquare
Comment 49 Marek Novotny 2017-01-03 04:54:25 EST
(In reply to Steevithak from comment #47)
> This may be a dumb question but if this is already fixed on Ubuntu
> (according to TD, think-or-swim runs on the current Ubuntu version),
> wouldn't it be possible for Fedora developers to have a peek at how Ubuntu
> got JavaFX compiling/working and copy those changes over to Fedora's Java
> code?
> 
> Also, thanks for the suggestions on how I could get this running but I rely
> on my Fedora box for work, so I'm not thrilled with the idea of replacing
> the supported version of java with a new one I download and compile myself.
> I'm afraid that I might break something important. I'm content to wait for
> the next rev of Fedora if necessary.

Debian has got openjfx package with JavaFX build which is their take on this and Ubuntu usually picks over from Debian testing repositories.
Comment 50 jiri vanek 2017-01-04 08:41:22 EST
Gabriel, how far are you with attempt to include this to main repositories?
Comment 51 Gabriel Féron 2017-01-04 09:53:00 EST
I'll try a new build very soon and fix the Webkit compilation but AFAIK, media support will still be lacking because Fedora doesn't include ffmpeg.

It's possible to build a meta-package and only publish this on a 3rd-party repository though, as it simply produces a bunch of additional static libraries.
Comment 52 Jonny Heggheim 2017-01-12 14:36:29 EST
I updated the spec file made by Mikolaj Izdebski to latest version of openjfx: https://jonny.fedorapeople.org/openjfx.spec

One question: Where should the files go? The current .spec puts the files in /usr/lib/jvm/openjfx, but as my understanding it should be inside $JAVA_HOME, but that will cause problems when upgrading the openjdk package.
Comment 53 Mario Torre 2017-01-13 04:26:00 EST
(In reply to Jonny Heggheim from comment #52)
> I updated the spec file made by Mikolaj Izdebski to latest version of
> openjfx: https://jonny.fedorapeople.org/openjfx.spec
> 
> One question: Where should the files go? The current .spec puts the files in
> /usr/lib/jvm/openjfx, but as my understanding it should be inside
> $JAVA_HOME, but that will cause problems when upgrading the openjdk package.

Yes, please don't put things in $JAVA_HOME. The way I suggest to solve the need for the jfxrt.jar to be in the ext directory of $JAVA_HOME is similar to what we do with the accessibility toolkit, that is a package that is part of the openjdk distribution that creates the necessary symlinks at every update.
Comment 54 Jonny Heggheim 2017-01-13 04:41:23 EST
(In reply to Mario Torre from comment #53)
> Yes, please don't put things in $JAVA_HOME. The way I suggest to solve the
> need for the jfxrt.jar to be in the ext directory of $JAVA_HOME is similar
> to what we do with the accessibility toolkit, that is a package that is part
> of the openjdk distribution that creates the necessary symlinks at every
> update.

Sounds like a good solution. What is the package name of the accessibility toolkit?
Comment 55 Severin Gehwolf 2017-01-13 05:10:05 EST
(In reply to Jonny Heggheim from comment #54)
> (In reply to Mario Torre from comment #53)
> > Yes, please don't put things in $JAVA_HOME. The way I suggest to solve the
> > need for the jfxrt.jar to be in the ext directory of $JAVA_HOME is similar
> > to what we do with the accessibility toolkit, that is a package that is part
> > of the openjdk distribution that creates the necessary symlinks at every
> > update.
> 
> Sounds like a good solution. What is the package name of the accessibility
> toolkit?

java-atk-wrapper. Required directly from java-1.8.0-openjdk-accessibility (a sub-package of java-1.8.0-openjdk[1]).

[1] http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec#n1168
Comment 56 Jonny Heggheim 2017-01-13 06:07:06 EST
Thanks
Comment 57 jiri vanek 2017-01-13 07:03:56 EST
Yes. I will be happy to add those links to java8 packages.
Comment 58 Jonny Heggheim 2017-01-13 07:13:22 EST
(In reply to jiri vanek from comment #57)
> Yes. I will be happy to add those links to java8 packages.

Great to hear!
Comment 59 Jonny Heggheim 2017-01-15 17:48:47 EST
Good news, I installed openjfx from the RPM into /usr/lib/jvm/openjfx, made links into the openjdk JRE and JDK and was able to build ReactFX and run the sample application. I will do some more cleanup and include documentation and soon publish the SRPM.


[1] https://github.com/TomasMikula/ReactFX
Comment 60 Steevithak 2017-01-16 13:49:48 EST
Cool, that sounds good! So will this fix be added to Fedora 25 or will we need to wait until F26 to see it?
Comment 61 Jonny Heggheim 2017-01-16 14:23:38 EST
(In reply to Steevithak from comment #60)
> So will this fix be added to Fedora 25 or will we
> need to wait until F26 to see it?

My goal is to get it working on Fedora 25
Comment 62 Jonny Heggheim 2017-01-16 16:21:12 EST
Not ready for review yet, but here is an updated version, it includes a README.fedora for how to create the symlinks for the JDK and JRE.

Spec: https://jonny.fedorapeople.org/openjfx.spec
SRPM: https://jonny.fedorapeople.org/openjfx-8.0.152-1.b00.fc25.src.rpm

Please give feedback and patches.
Comment 63 Christian Stadelmann 2017-01-16 18:41:34 EST
How does one build this package?
Comment 64 Jonny Heggheim 2017-01-17 04:32:31 EST
(In reply to Christian Stadelmann from comment #63)
> How does one build this package?

Install mock, download the package and run this command: 
mock --rebuild openjfx-8.0.152-1.b00.fc25.src.rpm

I also uploaded a x86_64 build in case you do not want to build it yourself: https://jonny.fedorapeople.org/openjfx-8.0.152-1.b00.fc25.x86_64.rpm
Comment 65 Jonny Heggheim 2017-01-17 04:33:57 EST
/usr/share/doc/openjfx/README.fedora contains the last steps to get it working, these should be done in a openjdk sub-package
Comment 66 Marek Novotny 2017-01-17 04:43:11 EST
(In reply to Jonny Heggheim from comment #64)
> (In reply to Christian Stadelmann from comment #63)
> > How does one build this package?
> 
> Install mock, download the package and run this command: 
> mock --rebuild openjfx-8.0.152-1.b00.fc25.src.rpm
> 
> I also uploaded a x86_64 build in case you do not want to build it yourself:
> https://jonny.fedorapeople.org/openjfx-8.0.152-1.b00.fc25.x86_64.rpm

Could you create COPR repository with your changes?
Comment 67 Stefan Neufeind 2017-01-17 04:45:04 EST
Great. Installing the binary package and simply running the lines from README.fedora worked out of the box. With this I got a previouly not running tool working fine (MediathekView) which requires openjfx.
Comment 68 Christian Stadelmann 2017-01-17 05:04:12 EST
(In reply to Stefan Neufeind from comment #67)
> Great. Installing the binary package and simply running the lines from
> README.fedora worked out of the box. With this I got a previouly not running
> tool working fine (MediathekView) which requires openjfx.

Confirmed.

@Jonny Heggheim: Thank you. I couldn't spot any issues.
Comment 69 Jonny Heggheim 2017-01-17 06:52:49 EST
Glad to hear that it work with real applications, I will have a look into COPR.
Comment 70 Jonny Heggheim 2017-01-17 16:05:27 EST
(In reply to Marek Novotny from comment #66)
> Could you create COPR repository with your changes?

Hope it work, will build new updates here:
https://copr.fedorainfracloud.org/coprs/jonny/openjfx/
Comment 71 Marek Novotny 2017-01-19 12:55:02 EST
Thanks Jonny for copr.

Package installation from copr repository works like a charm.

One additional comment to manual creation of symlinks in README.fedora.
I am on fedora 25 and there is java installed in /usr/lib/jvm/java-openjdk directory or in java-1.8.0-openjdk* directories instead of /usr/lib/jvm/java and the same apply to jre, where it is in /usr/lib/jvm/jre-openjdk instead of /usr/lib/jvm/jre
Comment 72 Jonny Heggheim 2017-01-19 14:19:36 EST
All these folders on my Fedora 25 installation are symlinks to the same JDE/JRE folders.

$ tree -L 1 /usr/lib/jvm
/usr/lib/jvm
├── java -> /etc/alternatives/java_sdk
├── java-1.8.0 -> /etc/alternatives/java_sdk_1.8.0
├── java-1.8.0-openjdk -> /etc/alternatives/java_sdk_1.8.0_openjdk
├── java-1.8.0-openjdk-1.8.0.111-4.b16.fc25.x86_64
├── java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64
├── java-openjdk -> /etc/alternatives/java_sdk_openjdk
├── jre -> /etc/alternatives/jre
├── jre-1.8.0 -> /etc/alternatives/jre_1.8.0
├── jre-1.8.0-openjdk -> /etc/alternatives/jre_1.8.0_openjdk
├── jre-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64 -> java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64/jre
├── jre-openjdk -> /etc/alternatives/jre_openjdk
└── openjfx

The /etc/alternatives/ symlinks also points to the same JDK/JRE folder.

In the future it will be the openjdk subpackage that will take care of adding the correct symlinks. These manual made links today will be invalid after upgrade/downgrade of JDK/JRE. That will not be the case of a subpackage.
Comment 73 Jonny Heggheim 2017-01-19 19:06:59 EST
I have sent a mail to upstream: http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-January/020195.html
Comment 74 jiri vanek 2017-01-20 04:13:06 EST
Generally speaking you wont me to add those symlinks to java-1.8.0-openjdk-devel

/usr/lib/jvm/openjfx/bin/javafxpackager -> /usr/lib/jvm/java/bin/javafxpackager
/usr/lib/jvm/openjfx/bin/javapackager ->  /usr/lib/jvm/java/bin/javapackager
/usr/lib/jvm/openjfx/lib/javafx-mx.jar -> /usr/lib/jvm/java/lib/javafx-mx.jar
/usr/lib/jvm/openjfx/lib/packager.jar -> /usr/lib/jvm/java/lib/packager.jar
/usr/lib/jvm/openjfx/lib/ant-javafx.jar -> /usr/lib/jvm/java/lib/ant-javafx.jar


and those symlinks to java-1.8.0-openjdk (not headless)

/usr/lib/jvm/openjfx/rt/lib/jfxswt.jar -> /usr/lib/jvm/jre/lib/jfxswt.jar
/usr/lib/jvm/openjfx/rt/lib/ext/jfxrt.jar -> /usr/lib/jvm/jre/lib/ext/jfxrt.jar
/usr/lib/jvm/openjfx/rt/lib/amd64/libprism_es2.so -> /usr/lib/jvm/jre/lib/amd64/libprism_es2.so
/usr/lib/jvm/openjfx/rt/lib/amd64/libprism_common.so -> /usr/lib/jvm/jre/lib/amd64/libprism_common.so
/usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font.so -> /usr/lib/jvm/jre/lib/amd64/libjavafx_font.so
/usr/lib/jvm/openjfx/rt/lib/amd64/libdecora_sse.so -> /usr/lib/jvm/jre/lib/amd64/libdecora_sse.so
/usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_freetype.so -> /usr/lib/jvm/jre/lib/amd64/libjavafx_font_freetype.so
/usr/lib/jvm/openjfx/rt/lib/amd64/libprism_sw.so -> /usr/lib/jvm/jre/lib/amd64/libprism_sw.so
/usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_pango.so -> /usr/lib/jvm/jre/lib/amd64/libjavafx_font_pango.so
/usr/lib/jvm/openjfx/rt/lib/amd64/libglass.so -> /usr/lib/jvm/jre/lib/amd64/libglass.so
/usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_iio.so -> /usr/lib/jvm/jre/lib/amd64/libjavafx_iio.so
/usr/lib/jvm/openjfx/rt/lib/javafx.properties -> /usr/lib/jvm/jre/lib/javafx.properties

where /usr/lib/jvm/openjfx is contract we will have,  /usr/lib/jvm/{jre,java} is my "private path", and the lists are subject of occasional bug/ping/email

right?

I will be happy to include those links to opanjdk packages in rawhide once official review starts. Thoughts?
Comment 75 jiri vanek 2017-01-20 04:14:33 EST
s/->/<-/g
Comment 76 Marek Novotny 2017-01-20 04:39:42 EST
(In reply to Jonny Heggheim from comment #72)
> All these folders on my Fedora 25 installation are symlinks to the same
> JDE/JRE folders.
> 
> $ tree -L 1 /usr/lib/jvm
> /usr/lib/jvm
> ├── java -> /etc/alternatives/java_sdk
> ├── java-1.8.0 -> /etc/alternatives/java_sdk_1.8.0
> ├── java-1.8.0-openjdk -> /etc/alternatives/java_sdk_1.8.0_openjdk
> ├── java-1.8.0-openjdk-1.8.0.111-4.b16.fc25.x86_64
> ├── java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64
> ├── java-openjdk -> /etc/alternatives/java_sdk_openjdk
> ├── jre -> /etc/alternatives/jre
> ├── jre-1.8.0 -> /etc/alternatives/jre_1.8.0
> ├── jre-1.8.0-openjdk -> /etc/alternatives/jre_1.8.0_openjdk
> ├── jre-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64 ->
> java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64/jre
> ├── jre-openjdk -> /etc/alternatives/jre_openjdk
> └── openjfx
> 
> The /etc/alternatives/ symlinks also points to the same JDK/JRE folder.
> 
> In the future it will be the openjdk subpackage that will take care of
> adding the correct symlinks. These manual made links today will be invalid
> after upgrade/downgrade of JDK/JRE. That will not be the case of a
> subpackage.

My point is that I don't have these jre and java in /usr/lib/jvm directory. I installed openjdk 8 with standard way through dnf ;) So even later manual installation of symlinks will be done automatically, now some users need to be notified about this potential issue.

My content is:
tree -L 1 /usr/lib/jvm
/usr/lib/jvm
├── java-1.8.0 -> /etc/alternatives/java_sdk_1.8.0
├── java-1.8.0-openjdk -> /etc/alternatives/java_sdk_1.8.0_openjdk
├── java-1.8.0-openjdk-1.8.0.111-3.b16.fc25.x86_64
├── java-1.8.0-openjdk-1.8.0.111-4.b16.fc25.x86_64
├── java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64
├── java-openjdk -> /etc/alternatives/java_sdk_openjdk
├── jre-1.8.0 -> /etc/alternatives/jre_1.8.0
├── jre-1.8.0-openjdk -> /etc/alternatives/jre_1.8.0_openjdk
├── jre-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64 -> java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64/jre
├── jre-openjdk -> /etc/alternatives/jre_openjdk
└── openjfx
Comment 77 Mario Torre 2017-01-20 05:50:58 EST
(In reply to jiri vanek from comment #74)
> Generally speaking you wont me to add those symlinks to
> java-1.8.0-openjdk-devel
> 
> /usr/lib/jvm/openjfx/bin/javafxpackager ->
> /usr/lib/jvm/java/bin/javafxpackager
> /usr/lib/jvm/openjfx/bin/javapackager ->  /usr/lib/jvm/java/bin/javapackager
> /usr/lib/jvm/openjfx/lib/javafx-mx.jar -> /usr/lib/jvm/java/lib/javafx-mx.jar
> /usr/lib/jvm/openjfx/lib/packager.jar -> /usr/lib/jvm/java/lib/packager.jar
> /usr/lib/jvm/openjfx/lib/ant-javafx.jar ->
> /usr/lib/jvm/java/lib/ant-javafx.jar
> 
> 
> and those symlinks to java-1.8.0-openjdk (not headless)
> 
> /usr/lib/jvm/openjfx/rt/lib/jfxswt.jar -> /usr/lib/jvm/jre/lib/jfxswt.jar
> /usr/lib/jvm/openjfx/rt/lib/ext/jfxrt.jar ->
> /usr/lib/jvm/jre/lib/ext/jfxrt.jar
> /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_es2.so ->
> /usr/lib/jvm/jre/lib/amd64/libprism_es2.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_common.so ->
> /usr/lib/jvm/jre/lib/amd64/libprism_common.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font.so ->
> /usr/lib/jvm/jre/lib/amd64/libjavafx_font.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libdecora_sse.so ->
> /usr/lib/jvm/jre/lib/amd64/libdecora_sse.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_freetype.so ->
> /usr/lib/jvm/jre/lib/amd64/libjavafx_font_freetype.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_sw.so ->
> /usr/lib/jvm/jre/lib/amd64/libprism_sw.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_pango.so ->
> /usr/lib/jvm/jre/lib/amd64/libjavafx_font_pango.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libglass.so ->
> /usr/lib/jvm/jre/lib/amd64/libglass.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_iio.so ->
> /usr/lib/jvm/jre/lib/amd64/libjavafx_iio.so
> /usr/lib/jvm/openjfx/rt/lib/javafx.properties ->
> /usr/lib/jvm/jre/lib/javafx.properties
> 
> where /usr/lib/jvm/openjfx is contract we will have, 
> /usr/lib/jvm/{jre,java} is my "private path", and the lists are subject of
> occasional bug/ping/email
> 
> right?
> 
> I will be happy to include those links to opanjdk packages in rawhide once
> official review starts. Thoughts?

I would advice against doing so, we should have a separate optional package that adds those symlinks. We can't guarantee at this stage that security updates for OpenJFX will be issued timely with the OpenJDK updates, so we can't enable access to OpenJFX by default. User need to specifically install that and should be entirely optional.
Comment 78 Jonny Heggheim 2017-01-20 06:05:23 EST
(In reply to Marek Novotny from comment #76)
> My point is that I don't have these jre and java in /usr/lib/jvm directory.
> I installed openjdk 8 with standard way through dnf ;) So even later manual
> installation of symlinks will be done automatically, now some users need to
> be notified about this potential issue.
> 
> My content is:
> tree -L 1 /usr/lib/jvm
> /usr/lib/jvm
> ├── java-1.8.0 -> /etc/alternatives/java_sdk_1.8.0
> ├── java-1.8.0-openjdk -> /etc/alternatives/java_sdk_1.8.0_openjdk
> ├── java-1.8.0-openjdk-1.8.0.111-3.b16.fc25.x86_64
> ├── java-1.8.0-openjdk-1.8.0.111-4.b16.fc25.x86_64
> ├── java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64
> ├── java-openjdk -> /etc/alternatives/java_sdk_openjdk
> ├── jre-1.8.0 -> /etc/alternatives/jre_1.8.0
> ├── jre-1.8.0-openjdk -> /etc/alternatives/jre_1.8.0_openjdk
> ├── jre-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64 ->
> java-1.8.0-openjdk-1.8.0.111-5.b16.fc25.x86_64/jre
> ├── jre-openjdk -> /etc/alternatives/jre_openjdk
> └── openjfx

Hmm.. strange, I am not sure who created by jre and java symlinks in the /usr/lib/jvm.
Comment 79 Jonny Heggheim 2017-01-20 06:08:15 EST
(In reply to Mario Torre from comment #77)
> I would advice against doing so, we should have a separate optional package
> that adds those symlinks. We can't guarantee at this stage that security
> updates for OpenJFX will be issued timely with the OpenJDK updates, so we
> can't enable access to OpenJFX by default. User need to specifically install
> that and should be entirely optional.

I think that is the plan, a separate optional sub-package that adds the correct requires and includes symlinks for that specific JRE/JDK.
Comment 80 Jonny Heggheim 2017-01-20 06:21:31 EST
(In reply to jiri vanek from comment #74)
> Generally speaking you wont me to add those symlinks to
> java-1.8.0-openjdk-devel.

I assume you mean: want

> /usr/lib/jvm/openjfx/bin/javafxpackager ->
> /usr/lib/jvm/java/bin/javafxpackager
> /usr/lib/jvm/openjfx/bin/javapackager ->  /usr/lib/jvm/java/bin/javapackager
> /usr/lib/jvm/openjfx/lib/javafx-mx.jar -> /usr/lib/jvm/java/lib/javafx-mx.jar
> /usr/lib/jvm/openjfx/lib/packager.jar -> /usr/lib/jvm/java/lib/packager.jar
> /usr/lib/jvm/openjfx/lib/ant-javafx.jar ->
> /usr/lib/jvm/java/lib/ant-javafx.jar

Yes, and destination should be the absolute path of that specific JDK.

 
> and those symlinks to java-1.8.0-openjdk (not headless)
> 
> /usr/lib/jvm/openjfx/rt/lib/jfxswt.jar -> /usr/lib/jvm/jre/lib/jfxswt.jar
> /usr/lib/jvm/openjfx/rt/lib/ext/jfxrt.jar ->
> /usr/lib/jvm/jre/lib/ext/jfxrt.jar
> /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_es2.so ->
> /usr/lib/jvm/jre/lib/amd64/libprism_es2.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_common.so ->
> /usr/lib/jvm/jre/lib/amd64/libprism_common.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font.so ->
> /usr/lib/jvm/jre/lib/amd64/libjavafx_font.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libdecora_sse.so ->
> /usr/lib/jvm/jre/lib/amd64/libdecora_sse.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_freetype.so ->
> /usr/lib/jvm/jre/lib/amd64/libjavafx_font_freetype.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libprism_sw.so ->
> /usr/lib/jvm/jre/lib/amd64/libprism_sw.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_font_pango.so ->
> /usr/lib/jvm/jre/lib/amd64/libjavafx_font_pango.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libglass.so ->
> /usr/lib/jvm/jre/lib/amd64/libglass.so
> /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_iio.so ->
> /usr/lib/jvm/jre/lib/amd64/libjavafx_iio.so
> /usr/lib/jvm/openjfx/rt/lib/javafx.properties ->
> /usr/lib/jvm/jre/lib/javafx.properties

Yes, and destination should be the absolute path of that specific JRE.


> where /usr/lib/jvm/openjfx is contract we will have, 

I continued to use /usr/lib/jvm/openjfx in my SPEC file, but this should be changed if others have better suggestions. It could be that a openjfxdir RPM macro would fit better as a contract.

> /usr/lib/jvm/{jre,java} is my "private path", and the lists are subject of
> occasional bug/ping/email
> 
> right?

Yes, openjfx will not know where or what JRE/JDKs are installed.

> I will be happy to include those links to opanjdk packages in rawhide once
> official review starts. Thoughts?

As Miro Torre pointed out, these links should be owned/made by an optional sub-package.
Comment 81 jiri vanek 2017-01-23 05:42:41 EST
(In reply to Jonny Heggheim from comment #80)
> (In reply to jiri vanek from comment #74)
> > Generally speaking you wont me to add those symlinks to
> > java-1.8.0-openjdk-devel.
> 
> I assume you mean: want

sure
> 
> > /usr/lib/jvm/openjfx/bin/javafxpackager ->
...
> > /usr/lib/jvm/java/lib/ant-javafx.jar
> 
> Yes, and destination should be the absolute path of that specific JDK.

sure
> 
>  
> > and those symlinks to java-1.8.0-openjdk (not headless)
> > 
> > /usr/lib/jvm/openjfx/rt/lib/jfxswt.jar -> /usr/lib/jvm/jre/lib/jfxswt.jar
...
> > /usr/lib/jvm/jre/lib/amd64/libglass.so
> > /usr/lib/jvm/openjfx/rt/lib/amd64/libjavafx_iio.so ->
> > /usr/lib/jvm/jre/lib/amd64/libjavafx_iio.so
> > /usr/lib/jvm/openjfx/rt/lib/javafx.properties ->
> > /usr/lib/jvm/jre/lib/javafx.properties
> 
> Yes, and destination should be the absolute path of that specific JRE.

sure

> 
> 
> > where /usr/lib/jvm/openjfx is contract we will have, 
> 
> I continued to use /usr/lib/jvm/openjfx in my SPEC file, but this should be
> changed if others have better suggestions. It could be that a openjfxdir RPM
> macro would fit better as a contract.

I think it is good decision.

%{_jvmdir} is already existing macro of /usr/lib/jvm.
I would stcik on that.

So the contract really is only openjfx (which I see as good), and be sure I will use the macro.

Or is there any other macro you would like to see?

There is no other java macro for destination then _jvmdir whcih I'm aware about.
The new macro you would like to introduce is competently another story (and chapter)

> 
> > /usr/lib/jvm/{jre,java} is my "private path", and the lists are subject of
> > occasional bug/ping/email
> > 
> > right?
> 
> Yes, openjfx will not know where or what JRE/JDKs are installed.

oook!
> 
> > I will be happy to include those links to opanjdk packages in rawhide once
> > official review starts. Thoughts?
> 
> As Miro Torre pointed out, these links should be owned/made by an optional
> sub-package.


I don't agree 100% with the statements but I will do it in this way. Mario is more aware about javafx internals then me, and you seems to agree so lets it happen.

Note You need to log in before you can comment on or make changes to this bug.