Attempting to Build [ was Source code for JavaFX UI controls now available on openjfx]

Jonathan Giles jonathan.giles at
Tue Dec 6 16:33:12 PST 2011

I don't believe this variable is fully implemented. I actually define 
the same property up in the rt/build-defs.xml file, but there needs to 
be some more work in the javafx-ui-controls folder to only use this 
reference. I've made some half-attempts at getting this all hooked up in 
the past, but haven't yet completed it. There are a number of paths that 
need testing:

  * compile from rt-closed,
  * compile from 'jfx'/root directory with 'ant clean dev-build',
  * compile from within javafx-ui-controls folder,
  * compilation from within NetBeans.

Also, it's worth noting that in the same part of build-defs.xml I pull 
in all environment variables, so if the developer simply sets JFXRT_HOME 
to a path on their file system in the environment settings, this should 
be picked up (although with the caveat that ant doesn't apparently 
support environment variables in all operating systems).

Once I'm back from vacation, if nobody else has taken a look at 
JFXRT_HOME improvements (and indeed whether we should be pointing at 
JFXRT_HOME, or more simply JFX_HOME (which may be a directory or two 
higher up the path)), I'll take another stab at it.

-- Jonathan

On Wednesday, 7 December 2011 10:20:28 a.m., Richard Bair wrote:
> Ya the property is in javafx-ui-common/ called 
> JFXRT_HOME. If you just set this property then you don't have to 
> manually move the jfxrt.jar into artifacts/sdk/rt/lib.
> Thanks for filing the issue!
> Richard
> On Dec 6, 2011, at 4:16 PM, Kevin Rushforth wrote:
>> Regarding #4 I think Jonathan added a property (or was going to add 
>> one) so you don't have to copy it in, although copying it may be the 
>> easiest way to do it anyway.
>> Regarding having to comment out the propertycopy ant task, I filed 
>> to track this.
>> -- Kevin
>> Richard Bair wrote:
>>> The missing scripts have been pushed, so I think I can now give 
>>> reproducible instructions for building and testing. Download the 2.1 
>>> binary for Mac from 
>>> 1) hg clone
>>> 2) cd master
>>> 3) mkdir -p artifacts/sdk/rt/lib
>>> 4) cp ~/Downloads/javafx-sdk2.1.0-beta/rt/lib/jfxrt.jar 
>>> artifacts/sdk/rt/lib
>>> - Or from wherever you have downloaded this file
>>> 5) hg clone
>>> 6) vi build-defs.xml
>>> - There is some library being used but not registered properly, 
>>> there is probably another way to do this.
>>> Anyway, just edit the master/rt/build-defs.xml and comment out the line:
>>> <propertycopy name="javac.debuglevel" 
>>> from="${}.javac.debuglevel" silent="true" 
>>> override="true"/>
>>> 7) cd javafx-ui-controls
>>> 8) ant
>>> That should be enough to actually have built the project. The built 
>>> class files should be sitting in 
>>> master/rt/javafx-ui-common/dist/javafx-ui-controls.jar. You can then 
>>> run by placing the newly created javafx-ui-controls.jar before 
>>> jfxrt.jar on your classpath.
>>> Let me know if you have any success!
>>> Thanks
>>> Richard
>>> On Dec 6, 2011, at 9:46 AM, Richard Bair wrote:
>>>> If you got to and download JavaFX and find the tiny link 
>>>> that switches to the Mac Developer Preview download and grab it, 
>>>> you will get a very recent 2.1 build. This can be used as the 
>>>> binary plug for building. Unfortunately, some build files are 
>>>> missing in the master/ repo. I tried to push these files in, but 
>>>> the server is not happy with my ssl configuration. I'm trying to 
>>>> track that down. With those build files put in, there is one other 
>>>> slight modification to master/rt/build-defs.xml, but this will then 
>>>> allow you to actually build the controls repo and, if you are on 
>>>> Mac, run it.
>>>> I'll keep you all abreast of the work, hopefully we'll have 
>>>> something fully buildable a little later today.
>>>> Richard
>>>> On Dec 2, 2011, at 5:43 PM, Richard Bair wrote:
>>>>>> Sorry I misunderstood, I was expecting something similar to the 
>>>>>> binary plugs we had in OpenJDK, not a full version of the current 
>>>>>> release, hence the question.
>>>>>> I was able to import the project successfully into eclipse (and 
>>>>>> netbeans) with the FX runtime and it seems to compile fine.
>>>>> Oh, that's interesting. I grabbed the latest 2.0.2 code for Mac 
>>>>> that I had available but it was failing on:
>>>>> [javac] 
>>>>> /Developer/Projects/openjfx/workspace-2.1/master/rt/javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ 
>>>>> cannot find symbol
>>>>> [javac] symbol : class PlatformUtil
>>>>> [javac] location: package com.sun.javafx
>>>>> [javac] import com.sun.javafx.PlatformUtil;
>>>>> [javac] ^
>>>>> And a bunch of other such failures. So I thought PlatformUtil had 
>>>>> been removed between the 2.0.2 code I had (from early November) 
>>>>> and the newer code in the 2.1 tree. If you got it to build in 
>>>>> Eclipse on an older release -- well that is interesting! What 
>>>>> version of JavaFX are you using for the binary plug?
>>>>> Do you want to post some basic instructions so other folks can do 
>>>>> likewise?
>>>>>> I'll play with this code a bit and see how we can help out until 
>>>>>> everything else is sorted out.
>>>>>> I think that while this is a suboptimal situation (but hey, we 
>>>>>> Free Software freaks are never happy, right? :) is still a great 
>>>>>> step forward, and we have a chance to study the code and the 
>>>>>> internals before everything gets released.
>>>>>> Speaking about this, do you think we can have some "specs" about 
>>>>>> the internal interfaces?
>>>>> Probably in the short term asking me questions is the fastest way 
>>>>> to get answers, unfortunately. I do need to be badgered to write 
>>>>> up some documents though and put them up on our pages. Please do 
>>>>> feel free to badger me: squeaky wheel and all that :-)
>>>>>> I know from JavaOne that the internal code is pretty abstracted 
>>>>>> and modular, and can actually be "easily" replaced (not sure the 
>>>>>> exact definition of easily though, but what you have shown at J1 
>>>>>> was very impressive).
>>>>>> We can probably help speeding up things if we know what things 
>>>>>> should be replaced and implement some clear room version of what 
>>>>>> will come later in the game, in a similar way we did with the 
>>>>>> Pisces renderer in Java2D, what do you think?
>>>>>> I'm specifically thinking about the Linux port here, since to be 
>>>>>> honest "late 2012" is eons away.
>>>>> What we have released so far is the controls portion, which all 
>>>>> sits above the "toolkit implementation" line. Basically on the 
>>>>> "top" we've got controls, scene graph, css, properties, binding, 
>>>>> collections, services, and that sort of thing. There is a Toolkit 
>>>>> interface ( which defines the 
>>>>> abstraction between the public API portions of the platform and 
>>>>> the underlying toolkit implementation (threading, windowing, 
>>>>> opengl, d3d, fonts, etc).
>>>>> Likely it will be a couple months before we start putting out the 
>>>>> lower-level bits en masse, due to having to be careful there over 
>>>>> 3rd party code etc (there isn't much, mostly fonts and some SVG, 
>>>>> but we have to do all the due diligence). The other problem is the 
>>>>> same guys who have to do that, have to get the Mac port finished 
>>>>> (both for Java 7 and for Java FX). However I will follow up with 
>>>>> the guys doing linux and see if we can get that out sooner 
>>>>> (they're busy working away on it and it would be cool to get it 
>>>>> open faster, but at the very least get it included in the bits so 
>>>>> you can run on linux).
>>>>> Cheers
>>>>> Richard

More information about the openjfx-dev mailing list