javafx module is part of the Java 7 SDK

[gavinking]

Currently, JDKUtils doesn't find javafx, so I had to import the jar into my repo.

[FroMage]

Because it's not part of the JDK, at least not part of its classpath. It will be in Java 8 from what I heard.

[renatoathaydes]

JavaFX 2.x is "partially" part of the Java 7 SDK. They (Oracle) decided to include the Jar (jfxrt.jar) since java 7_update6 or something, but oddly, not add it to the classpath... therefore everyone has to add it to the classpath manually... But in Ceylon, why shouldn't JavaFX be one of the modules in the Herd?

[FroMage]

I guess we could add it to Herd if it doesn't use any native library.

[renatoathaydes]

I've made JavaFX work in an OSGi container by adding all the packages it requires to work to the OSGi extra system packages.. I got that information by using BdlUtils.wrap and you can find the result in this Gist:

https://gist.github.com/renatoathaydes/5021107

I hope this information helps.... but I believe the JavaFX jar itself is platform-independent (you don't need to download a specific Jar for each OS!) and therefore this shouldn't be an issue....

Also, I added the JavaFX jar to my ceylon private repo and it worked just fine (even though it would be much better if it would be possible to add some metadata to hide sun classes (app developers should be able to see javafx.application.Application, but not com.sun.glass.ui.Application for example).

[FroMage]

That doesn't mean it doesn't require native libs provided by the JDK. If you manage to make the jfx jar work in a JDK7 < java 7_update6 (or wherever it got added), then it is a better proof.

[gavinking]

Well look there is an alternative solution to the problem which is to simply add the jar to Herd. I assume that is OK from a license standpoint but how can we verify that?

Sent from my iPhone

On 27 Nov 2013, at 11:49 am, Stéphane Épardaud notifications@github.com wrote:

That doesn't mean it doesn't require native libs provided by the JDK. If you manage to make the jfx jar work in a JDK7 < java 7_update6 (or wherever it got added), then it is a better proof.

— Reply to this email directly or view it on GitHub.

[FroMage]

We can't add it to Herd if it requires native libs to run, otherwise it will not run for everyone. That's what I'm trying to figure out.

[gavinking]

We can't add it to Herd if it requires native libs to run, otherwise it will not run for everyone.

It will run for everyone who has a sufficiently uptodate Java 7 VM. So I don't see this as a real problem.

[ncorai]

My 2¢: It would make sense that users of Java 7 pre u6 be early adopters, and thus be likely to have moved on to a more recent release. Also, security flaws.

[FroMage]

Moving again, unfortunately.