Why isn't JavaFX on the jdk1.7.0_u10build12 class path?

[Randahl Fink Isaksen]

I can confirm that simply dragging jfxrt.jar to the ext package works like a charm.
I am fully aware that this would not be sufficient for a production release distributed to end users, but since we are not about to release this seems to be the fastest way forward.

Sure hope there is a focus on fixing this – for newcomers, I would want JavaFX to be plug and play, and currently it does not seem to be.

Randahl



On Oct 24, 2012, at 9:33 , Daniel Zwolenski <zonski at gmail.com> wrote:

> The problem with any discussion on this is there is no good answer. JavaFX has five ways of deploying (regular jar, executable jar, applet, jnlp, native installer) all of them broken or as good as (whether you use Maven, Ant or anything). 
> 
> The way I proposed is definitely not perfect but moves some pain from one spot to the next. Choose your fetish. 
> 
>> I'm no Maven expert (in fact I hate it with a passion - it's fragile half-baked plugins broke the build on me just today)
> 
> I'd hazard a guess you're trying to do something non-standard with it?
> 
> Generally if you follow Maven's conventions it all just works. If you don't follow them it will slap you round every which way. If you can't follow the conventions (why not?) then I'd suggest Gradle or if you really have to then Ant + Ivy. 
> 
> JavaFX goes out of its way to make you break Maven conventions so generally you will suffer here - there have been a hundred emails on how JavaFX could easily play nice with Maven so I won't bother repeating them here. 
> 
>> but what I suggested would continue to work without modifications after the proper co-bundling would it not?
> 
> You have introduced extra and unusual config to your POM. After co-bundling it should all be unnecessary and should be removed. In the alternative approach, the Pom is the same before and after. Choose your poison. 
> 
>> The issue with including jfxrt.jar yourself is the fragile nature of the native code loading.  You must ensure the native libraries are at exactly the right relative path to jfxrt.jar.  
>> If they aren't you might accidentally pick up the native libraries in the JRE folder and be fooled into thinking things are working.  Then when the JRE is updated the native libraries don't match your bundled jfxrt.jar and it breaks.  It happened to me :-) 
> 
> Yes. But this is a problem in every single scenario, maven or otherwise. You can either use the jre bundled fx or bundle your own in your distro. Both options are fraught with problems. 
> 
> This is all a flaw in the current half-hearted co-bundling. Jfx is tied to a jre version, is deployed within a jre install, but isn't available meaning you have to do something awful to make it work at all. Can't understand the logic behind this partial cobundle - better not to have done it at all until it could be done properly. But again that's been raised many times before. 
> 
>> If you are't going to require 7u7 or later, it is probably best to use the javafxpackager tools somehow.
> 
> I'd suggest (having been burnt by this heavily and continually for the last 12 months) that you ONLY use the jfx packaging tools and ONLY use the native installer approach. Everything else is guaranteed to kick you in the face and laugh at your futile attempts to do something as simple as build and deploy. 
> 
> Native installers are pretty terrible to work with in their current form though (huge downloads, complicated setup of build, no auto updating) but in terms of things that will come back to kick you in the nuts in 3 months time this is the only one that might not. 
> 
> 
>> 
>> Scott
>> 
>> On 2012-10-23, at 10:55 PM, Daniel Zwolenski <zonski at gmail.com> wrote:
>> 
>>> Given that the bootclasspath issue will (one day) be fixed so that JFX is actually co-bundled, I'd personally just go with manually 'fixing' your installed JDK by moving JFX inside the JDK extension package after the install:
>>>     http://www.zenjava.com/firstcontact/architecture/setup/install-javafx/
>>> 
>>> Then when the classpath issue finally gets resolved, no changes will be needed to your Maven POM etc. 
>>> 
>>> If you use the assembly tools (or https://github.com/zonski/javafx-maven-plugin) then JFX gets bundled into the disputables so no need to do any hackery on that side of things (i.e. you only have to do the above cludge on your own dev machine where you do your compiling/building). 
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Oct 24, 2012 at 1:00 PM, Scott Palmer <swpalmer at gmail.com> wrote:
>>> JavaFX has been bundled since 7u7 anyway… but it is not on the classpath by default.  Presumably someone was scared of breaking stuff.  The JavaFX app packager does some magic to get it on the classpath for runtime.
>>> 
>>> For Maven there are a couple of options.  One is to use the dreaded "system" scope:
>>> 
>>>         <dependency>
>>>                 <groupId>javafx</groupId>
>>>                 <artifactId>jfxrt</artifactId>
>>>                 <scope>system</scope>
>>>                 <systemPath>${java.home}/lib/jfxrt.jar</systemPath>
>>>                 <version>2.2.4</version>
>>>         </dependency>
>>> 
>>> Use the "enforcer" plugin to require at lest 7u7.
>>> 
>>>   <build>
>>>           <plugins>
>>>                   <plugin>
>>>                           <groupId>org.apache.maven.plugins</groupId>
>>>                           <artifactId>maven-enforcer-plugin</artifactId>
>>>                           <executions>
>>>                                   <execution>
>>>                                           <id>enforce-java</id>
>>>                                           <goals>
>>>                                                   <goal>enforce</goal>
>>>                                           </goals>
>>>                                           <configuration>
>>>                                                   <rules>
>>>                                                           <requireJavaVersion>
>>>                                                                   <version>1.7.0-7</version>
>>>                                                           </requireJavaVersion>
>>>                                                   </rules>
>>>                                           </configuration>
>>>                                   </execution>
>>>                           </executions>
>>>                   </plugin>
>>>           </plugins>
>>>   </build>
>>> 
>>> (see http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireJavaVersion.html)
>>> 
>>> And then do the same sort of classpath hackery that the app packager stubs do for runtime.  Or just use -Xbootclasspath/a:
>>> 
>>> Scott
>>> 
>>> On 2012-10-23, at 9:37 PM, Randahl Fink Isaksen <randahl at rockit.dk> wrote:
>>> 
>>> > I upgraded to jdk 7u10 build 12 and I can see it comes with a JavaFX 2.2.4 inside it. So I thought I would go ahead and remove my maven dependency on the trusty old JavaFX 2.2.0-b19.
>>> >
>>> > However when I try to build my application with NetBeans it does not find the JavaFX classes. If I open the Java platform manager in NetBeans it also shows that jfxrt.jar is not on the class path of the JDK 1.7 (default) platform.
>>> >
>>> > Am I supposed to still extract the jfxrt.jar and the dylibs and manually create a maven dependency, or have I overlooked something here?
>>> >
>>> > Thanks
>>> >
>>> > Randahl
>>> 
>>> 
>>