JavaFX2.0 Layout: A Class Tour

JavaFX2.0 Beta is out.    We’ve taken advantage of the language shift to extensively remodel the layout APIs based on a year’s worth of tire-kicking.   This article (the first in a series) will introduce you to the basics.

In marrying the GUI to a scene-graph, each graphical element is represented by a stateful object rather than drawn inside a clipped rectangle, and this makes layout more complicated.   Hence, many of the JavaFX1.3 concepts still apply, however we’ve worked hard to simplify and eliminate the seams.

An interface is created by assembling scene-graph nodes into a hierarchy within a Scene.  The three Parent types have different layout characteristics:

  • Group:  doesn’t perform any positioning of children and is not directly resizable (see next section) and just takes on the collective bounds of it’s visible children.  Groups are most suited when you need to statically assemble a collection of nodes in fixed positions and/or need to apply an effect or transform to that collection.
  • Region: base class for all general purpose layout panes;  is both resizable and stylable via CSS.   Supports dynamic layout by sizing and positioning children during a layout pass (if needed).  If a Region subclass (layout pane) supports the layout paradigm you need, then use it instead of hand-positioning with a Group.
  • Control: the base class for all skinnable controls.   Is resizable and subclasses are all stylable via CSS.   Controls delegate layout to their skins (which are Regions). Each layout Control subclass provides a unique API for adding content in the appropriate place within its skinyou do not add children to a control directly.

A silly example to give you the flavor if you’ve never programmed FX:

        // silly example
        Text text = new Text("JavaFX 2.0!");
        text.setFont(new Font(24));
        Line line = new Line(2, 8, 104, 8);
        Group group = new Group();
        group.setEffect(new DropShadow());
        group.getChildren().addAll(text, line);

        BorderPane root = new BorderPane();
        root.setTop(new Label("Introducing..."));

        Scene scene = new Scene(root);

To explore some core scene-graph layout concepts, let’s zoom in on the key classes:


Each Node in the scene-graph has the potential to be “resizable”, which means it expresses it’s minimum, preferred, and maximum size constraints and allows its parent to resize it during layout (hopefully within that range, if the parent is honorable).

Each layout pane implements its own policy on how it resizes a resizable child, given the child’s size range.  For example, a StackPane will attempt to resize all children to fill its width/height (honoring their max limits) while a FlowPane always resizes children to their preferred sizes, which is what we mean by the term “autosize” (resize-to-preferred).

But here’s what surprises (and annoys) people: not all scene-graph node classes are resizable:

  • Resizable:  Region, Control, WebView
  • NOT Resizable: Group, Text, Shape, MediaView*, ImageView*

*will be made resizable in future release

If a Node class is not resizable, then isResizable() returns false, minWidth()/minHeight(), prefWidth()/prefHeight(), and maxWidth()/maxHeight() all return its current size, and resize() is a no-op.  The size of a non-resizable node is affected by its various properties (width/height for Rectangle, radius for Circle, etc) and it’s the application’s responsibility to set these properties (and remember that scaling is NOT the same as resizing, as a scale will also transform the stroke, which is not usually what you want for layout).   When non-resizable nodes are thrown into layout panes, they will be positioned, but not resized.

You inevitably want to ask why not make shapes resizable?  While it’s straight-forward to do the math on basic shapes (Rectangle, Circle, etc), it gets a bit muddier with Paths, Polygons, and 3D.  Also, keeping the core graphics shapes non-resizable allows us to make certain efficiencies, like ensuring a Group with non-resizable descendents pays no penalty for layout.  So for now anyway, that’s the way it is.

Tip: if you need a resizable rectangle, use a Region and style it with CSS.

Content Bias

For most node classes, width and height are independent of each other, however, there are a handful where height-depends-on-width or visa-versa.   In order to deal with these guys properly, the layout system needs a way to decipher it, hence Node’s getContentBias() method.  This returns null by default, which means there is no width/height dependency and layout code can pass -1 as the alternate dimension to the minWidth(h)/minHeight(w), prefWidth(h)/prefHeight(w), and maxWidth(h)/maxHeight(w) methods.

Labeled controls have a HORIZONTAL content-bias when wrapping is on.   FlowPane and TilePane support a content-bias that matches their orientation.  Note: turns out that HBox, VBox, and StackPane return a null content-bias, however they should really report a content-bias based on their childrens’ content-biases; this is a bug that will be fixed before the final release.

Our layout classes do the heavy-lifting in supporting content-bias in the system, so unless you are writing a custom layout class that handles arbitrary nodes, you needn’t deal directly with this API.  Just know layout supports content-bias automatically when you build your interfaces.

Overriding Min/Pref/Max Sizes

Most Control and layout pane classes are pretty good at computing how big they ought to be based on their content and property settings — we’ll call this their “intrinsic” min, pref, and max sizes.   For example, a Button will compute these sizes based on its text, font, padding, and so on;  additionally a Button’s intrinsic max size defaults to its preferred because you usually don’t want buttons expanding to fill space.  You shouldn’t have to explicitly set the size of controls, layout panes, or even the Scene, because the system will shrink-to-fit around your content.

But that’s a lie.   Or at least counter-intuitive to the nature of designers.   Thus, you can directly influence the size of Controls and Regions by setting their min, pref, and max size ‘override’ properties:

// make my button 100 pixels wide! 

By default these properties have the sentinel value USE_COMPUTED_SIZE, which causes Node’s minWidth(h)/minHeight(w), prefWidth(h)/prefHeight(w), maxWidth(h)/maxHeight(w) methods to return their intrinsic values.   Setting them to a positive double value will override their intrinsic values.

Often you want to ensure that the min or max size tracks the preferred, so the min and max overrides may also be set to USE_PREF_SIZE, which does the obvious:

// clamp my stackpane's size
stackpane.setMaxSize(USE_PREF_SIZE, USE_PREF_SIZE);

Beware of the subtle different between the Node methods and the size override properties:

button.getPrefWidth() returns the size override (might be a magic sentinel value) while button.prefWidth(-1) returns the actual preferred width of the button (returning the override if set).  Layout code should always use Node’s minWidth(h)/minHeight(w), prefWidth(h)/prefHeight(w), maxWidth(h)/maxHeight(w) methods for layout computations.

The Beauty of Beta

There’s more to the story of course, but I think that’s one blogful enough for now.

With the JavaFX2.0 public beta, you have the opportunity to influence the API based on cold, hard use cases, so don’t hold back (as if you would :-)).

This entry was posted in Uncategorized. Bookmark the permalink.

70 Responses to JavaFX2.0 Layout: A Class Tour

  1. surikov says:

    What is purpose of JavaFX 2.0?

    Database client? Games? Nice GUI? Easyness of GUI development?

    Why JavaFX 2.0 better then Flex, Swing, C#, Silverlight?

    This are very simple questions. But you can’t gain the world without answers of this questions.

  2. surikov says:

    Let’s look to FAQ at
    I see right question: 2. Why should I choose JavaFX to develop applications?

    Let’s look to answer:

    – Leverage your Java development skills
    Ok, fine. JavaScript is dead. Now i can use JavaFX components from Java. But WHY i should use JavaFX components from Java?

    – Create without boundaries
    Stop lying please. Flex, Swing and C# has more GUI components then JavaFX. Those components fast and robust enough.

    – Preserve investment in Java
    Ok, fine. I can use Java code from JavaFX. But WHY i should use JavaFX?

    – Familiar Java development tools
    Stop lying please. I uses Flex Builder for Flex, I uses Visual Studio for C#, I uses Oracle JDeveloper for Java/Swing. All of them has nice GUI editors. I don’t see such GUI editor for JavaFX.

    – Deploy on the desktop or in the browser
    Hm… I don’t need deploy app to the browser because JavaFX uses old Java plugin. It is very slow and eat many memory because JRE is too big.

    Main question to JavaFX team: you spend 4 years? For what?

  3. Anatol says:

    Some of your questions are good, but others’re so stupid and the whole effect is sour…

    Thanks for pretty good post! Many developers in Russia are very enthusiastic about JavaFX reloading!

  4. Jason Lee says:

    surikov, with regard to your plugin comment, see this review, specifically:

    Great Browser deployment. The new “plugin3” is once again (and as expected/promised) much better than before; another significant step after JDK 6u10’s plugin2. Oracle finally hit the nail on the head, it’s (at long last) in the same league of Flash. Most pending problems discussed here are gone. Only the ultra-cold-start scenario, requiring installation of the JRE and/or JavaFX runtimes, cannot be tested at this time.

  5. Rob Ratcliff says:

    I’d love to see the JavaOne keynotes and presentations published as JavaFX applets rather than Flash this year!

  6. tbeernot says:

    surikov seem to have only one reason to live; bash JavaFX. He is getting tiresome.

    • surikov says:

      Nope. I need brilliant JavaFX. I need exelent tool to develop DB clients, clients for webservices and rich UI.
      I don’t need promises anymore.

      • tbeernot says:

        People are putting energy in JavaFX, Oracle is putting money into it, at least show appriciation for the effort. If you don’t like it, go find happiness somewhere else. Your continous bashing and unfriendly tone is getting on my nerves.

        @admin: I’ll leave it at this.

      • surikov says:


        Read again “I need brilliant JavaFX”. I’m JavaFX guru. I work with JavaFX about 4 years. My words about JavaFX problems very important.

        Sorry for my english.

  7. irond13 says:

    Are there any plans to add support for baseline alignment? I would think that this would be a prerequisite when laying out control-heavy views. Other than this, JavaFX 2.0 is definitely looking promising.

    • Amy Fowler says:

      Irond13 – baseline alignment is already supported in the layout panes where it makes sense
      (supported via Node:getBaselineOffset()):

      HBox hbox = new HBox();
      hbox.getChildren().addAll(new Label(“Name:”), new TextBox());

  8. Dean Iverson says:

    Sergey, you surely understand the difference between an engineer trying to provide valuable information to the development community and a marketer writing JavaFX “FAQs”.

    Your comments are inappropriate in this context.

  9. Mikael Grev says:

    Hello Amy,

    Have you considered sizes other than pixels with ints? Also, a bit on the same subject, is there and thought being given to different gaps on different platforms?


    • Amy Fowler says:

      Mikael – all spacial values are doubles (not ints). Currently the API only deals in pixels, however CSS supports a full range of units that get converted to pixels when applied and so this will work well for specifying things like padding/gaps. However, you cannot currently use CSS to define node sizing, so perhaps we could add something to make it easier to set those using units too.

      Region supports a “snapToPixel” property (true by default) that causes the layout panes to [whenever possible] align spacing/sizing/positions on pixel boundaries to produce crisper visuals. Obviously as soon as you apply transforms, all bets are off, but for basic GUIs it works fairly well.

      • Mikael Grev says:


        I believe that it’s a must to be able to use units other than pixels. At least if you want to be able to work in, say, tablets with higher DPI.

        Snap to pixels is a given, or you would be in deep trouble. 🙂

        Also, you forgot my second question.. 🙂

      • Amy Fowler says:

        We spent a lot of time deliberating whether to support units explicitly in the API and there’s no question it’s a needed feature. There were just many higher priorities for the first release.

        As for your question about supporting different gaps on different platforms, we don’t do anything explicit at this time. Another good RFE.

  10. TJ says:

    Could you please write a nice tutorial on TableView?

  11. javajoe says:

    “Grumble, accept it, and move on.”

    What you really should be saying here is we’ll wait for more community feedback and based on that we’ll see if there is something that needs to be done. You really really can’t afford for people to move on.

  12. Pingback: JavaFX2.0 Layout: A Class Tour, by Amy Fowler // JavaFX News, Demos and Insight // FX Experience

  13. Pingback: JavaFX links of the week, June 6 // JavaFX News, Demos and Insight // FX Experience

  14. Aleix says:

    Thanks Amy !!!

    thanks for your big effort on javaFX ! I was playing with int since it’s initial relase, I liked and enjoy a lot, but with new java API it’s really awesome !!! I love javaFx and every day checked for news on ! Oh your posts are really concise and are helpful than one thousand dollars to understand the technology ! 🙂

    cheers and keep on the good work !
    (For sure I’ll use javafx on my company’s based swing framework ) !

  15. Tom says:

    Has research been done as to whether JavaFX is wanted anywhere? Schools teach Swing and companies use Swing. Big companies with big investment in Swing are going to adopt JavaFX, if at all, 5 years from now, i.e., once it is stable and proven. Not before. How are you going to get JavaFX to be taught at schools while no real companies are actually using it, needing it, or asking for it?

    • Ingo Maas says:

      Good point. I don’t see any official comments saying “If you’re used to Swing then JavaFX is the replacement tool for your future developments on the (fat) client side”. But actually it is. IMHO, the Swing tutorials have to be accompanied by similar JavaFX examples comparing both libraries. Otherwise there would be a gap between those two technologies. And what we need is a bridge, not technically (that is delivered by JavaFX 2.0), but in a sense of trust and GUI-dance.

    • Hans says:

      This argument is absolutely understanding and valid. But, on the other hand, it’s classical. As Windows was introduced, people said the same about DOS: “Why convert to MS-Windows – there is a huge number of DOS-apps out there (and, most of them are working just fine)?”
      [Although, I certainly hope and strongly believe that JavaFX is not going to remind us about the early times of Windows, though … 🙂 ]
      But, seriously, of course, there is a lot of legacy out there still using Swing. But, how old is Swing now? We simply need a more modern and “sexy” platform. It was overdue. We need a platform with which we can write appealing UIs. And, most of the Swing-Apps out there look pretty boring to me. Most of them remind me about the old and typical Visual-Basic app. If your task is to create another accounting-system, ok. But, if you need to create apps which should be appealing and fun, then FX seems to me as the exact right approach. For the coming years we simply need something better and more modern. Swing has been serving ok so far, in the lack of anything better. But, there is now time for a new generation to take over …

      • Tom says:

        “If your task is to create another accounting-system, ok. But, if you need to create apps which should be appealing and fun, then FX seems to me as the exact right approach.”

        Companies creating business applications DO NOT CARE AT ALL ABOUT APPEALING AND FUN. They care about stability. They care about data, They care about performance. I don’t see JavaFX being concerned about displaying date, I see it being all about rotating circles.

        If you’re creating wargame simulators, stock trading applications, air traffic control software, bioinformatics systems… i.e., REAL BUSINESS applications, as opposed to games and toys, why on earth would you move to JavaFX? Other than for the WebView? But that could have been delivered as JWebPane. The corporate deliver doesn’t need all this JavaFX stuff. What a waste of time.

  16. Christos says:

    In my view an important aspect is that currently there are no guidelines available for designing JavaFX based RIA applications, similarly to the guidelines found at for Swing desktop applications. Is there any initial work on such guidelines for JavaFX based RIAs? Any relevant / useful references?

  17. Pingback: Intermediate Java | JavaFX 2.0 Beta

  18. Zammbi says:

    I see that MediaView can’t be resizeable. But I want it to be the same width as my window screen.
    Do I have to wait or is there a way?

  19. Hans says:

    Of course, I am talking about biz-apps – not toys. And, that an app must be responsive, stable and user-friendly goes without saying. The interesting topic, which I have personally discussed in a professional context repeatidly, is, how important is it for the success of an app, that the UI is well designed and attractive? The interesting question is, assuming an app has good functionality, is responsive, stable and has good useability; is this then enough for it to be a winner. Let me answer: for many markets, definitely not.
    I agree with you, Tom. Among a large amount of users it is totally irrelevant whether an app looks boring or not. The world is full of apps, working fine, although they look like the streets of Pyongyang. But, personally, I have been serving the media-industry with apps for many years. I can tell You, in order to compete there, the design of the UI plays a significant role. And, there are many other markets demanding the same. There is a reason why many people don’t dress like the people of North-Korea and why cars don’t all look like a Lada. The more competing products there are in an area, and the easier it becomes to fulfill the basic requirements, the more significant the style of the app becomes. And, l think Apple is the best example of a company, which can thank it’s brilliant designers for it’s last years success. Apple has understood the importance of the fun-factor and beautiful design better than any other company I know of in this industry.
    But, it is wrong to believe, that JavaFX is about beautiful UIs, only. Looking at the history of JavaFX, it is understandable that people might get that impression. But, looking at today’s alternative cross-platform RIA-alternatives, like Air/FLex, Silverlight or GWT, I dont see any of them having such a clean concept and approach as JavaFX has. Let’s just hope, that the original vision of JavaFX – to become a real cross platform – will be implemented and completed. The fact that JavaFX is new, cannot be a valid argument against it. Maybe it will take 5 years for some companies to migrate. Maybe even longer for some of them – there are still a lot of IBM mainframes around. And, maybe the schools need to modernize their education programs. These are no arguments why a newer an better technology than Swing should not be pushed. For some of us creating apps with which we will need to compete for the next 5 years, we are eagerly waiting for JavaFX to reach the required level of completeness, so that we can build really modern and competing products. And, for the groups which I am targeting, those products need to be fast, stable and user-friendly, of course; but, also appealing, sexy and fun to work with.

    • surikov says:

      Why do you talk about design and JavaFX 2.0? I saw many nice attractive Flex applications for example. I don’t see any nice and complex JavaFX 2.0 application. I see promises only.

    • Tom says:

      Hmmm. Swing apps compared to the bleakness of the streets of Pyongyang? Plenty of apps in Swing look great and have all the interesting animations that JavaFX promises (note that “promises”, since Java FX still does not actually exist), though it takes a bit more work but at least it is possible while JavaFX, until further evidence arises, is still ALL HYPE.

      I simply do not see JavaFX being targeted at real business apps, at all. Once there are corporate apps out there, e.g., air traffic control apps or apps in biochemistry or in banks, let me know. Until then, it’s a big empty bag of wind.

  20. Tibor says:

    Regarding to get publicity of JavaFX 2.0, a standardazation process needs to be started. That’s the question which has not been yet answered, or nobody has asked it yet.
    How about to open JSR for JavaFX? I would say that the name “JavaFX” would have to change to some FX under java.fx package because it’s still the same Java having only commercial name.

    The popularity of JavaFX would increase if the Oracle could already issue JSR in JCP and let the big companies in the world participate on open source project with everyting that has to be achieved from compilers design, through API, to the platform specifics and graphics cards.

    When the Oracle would fix the Swing, using generics etc., and move it to standard java package? There are many dreaming javax packages being waiting for their time to be moved to the standard java package.

    Do we need JavaTwo, and any significant changes in JLS and JVMS for this process? I would say the Java needs fixes and there is only way Java 2.

    How about to move the instruction “invokedynamic” to JVMS, which needs to be first accepted by JCP.

    As one can see, there are many things to discuss, but since the Java is open source project, platform and a standard, the JavaFX needs standarization processes kept with the Java.
    As James Gosling said, the Oracle does not know how to make money from this open source; I would say it looks like the Oracle does not much care to the Java as a standard.
    Will this change by the Oracle?

  21. parasharappavan says:

    Hi Amy,
    A huge load of thanks for writing this article. around 10months back i read your javafx 1.3 basics and developed a project. now i am planning to migrate to javafx2.0. and i started learning now. but i am quite confused with binding in javafx2.0 ?? how do you bind in javafx2.0 ? can you please an article on binding. and use of bind keyword in javafx2.0

    Kindest Regards,

  22. Rick says:

    Amy – a terrific introduction. Stylable regions in 2.0 are huge. I just styled a subclassed VBox in css using build 32 and I am in heaven. Thank you for all your hard work.

  23. Jan says:

    Hi and thank’s for the article !
    After spending some time searching the web for information about JavaFX2 and Swing a question popped up in my head – how do JavaFX 2 stands/compares to Java Server Faces ?


  24. rk tumuluri says:

    Amy, Surikov & JavaFX PM’s

    I have also experimented with JavaFX (1.3 timeframe) and found it to be difficult to deal with for a complex graphics rich app that I was working on. It’s integration with Java and Swing were quite weak. Graphics context between swing/awt and javafx were getting horribly “entangled”.

    I hope that the promises made w.r.t Swing integration are demonstrated via “meaty” examples.

    Secondly, I thought that the legacy of “awt” (with native peers) and “swing” was being done away with in JavaFX. That “hardware acceleration” was being enabled more aggressively. In fact I recollect some vary good articles by “opinali” ? on that. If so, some “official benchmarks” would be good.

    I also felt that the “SceneGraph” approach was in general a superior abstraction. It facilitated “transforms”, “decorators”, “background” etc. If this has truly been accomplished then “demos”, “tutorials” should be fleshed out that can showcase this. A “roadmap” towards 3D would also be good.

    I recollect reading good technical articles on the value of “bind”. (Stephen Chin’s I think).

    With apologies for this relatively long writeup, but some of “Surikov’s” frustrations are valid. I have also felt the same.

    A “flagship” app that uses/showcases JavaFX would go a long way in adoption. I have suggested this in the past, and would like to re-iterate. Re-doing the UI for “openoffice” was a great opportunity. Now that Oracle has abandoned OpenOffice, I am not sure on this. Can the guys at “libreoffice” be engaged/persuaded ?. How difficult would that be ?.

    How about an “Outlook killer” ?.

    MS’s “Office365” seems quite “clunky”. A really “cool” alternative would be welcome. A huge opportunity to showoff JavaFX ?.

    Cheers …

  25. jos says:

    I agree with surikov.
    I want to see, multi-users, db applications that works rappid with a nice gui.
    I think that there are a lot of peoples who want to make program’s for bussiness like dbase in the DOS time; easy and effective.
    Now these bussiness are copy/pasting excel sheets …
    Making a simpel agenda for multi-users in FX is not simple.
    Priority of FX is a the moment to build a candle with a nice flikker flame above it ?

  26. Hi Aim

    Just a short question on design of the JavaFX API.

    public double prefWidth(double height)

    Returns the node’s preferred width for use in layout calculations. The parent of this node will use this value when allocating space for the node during layout.

    If the node is resizable, its parent should strive to resize its width to this value during layout. If the node is not resizable, then this value should be interpreted as the rigid size of the node.

    If this node has a vertical content-bias, then callers should pass in a height value that the preferred width should be based on. If the node has either a horizontal or null content-bias, then the caller may pass in -1 for the height.

    Node subclasses with a vertical content-bias should honor the height parameter whether -1 or a positive value. All other subclasses may ignore the height parameter (which will likely be -1).

    height – the height that should be used if preferred width depends on it

    Do you any example of code where the content-bias is not -1 or USE_PREF_SIZE?
    What sort of layout component pane in JavaFX is calling Node#prefWidth(800.0) , Node#prefHeight(600.0) ?

    • Amy Fowler says:

      Node classes where pref width and height depend on each other will return a non-null contentBias. For example, a Label that
      wraps it’s text will have a contentBias = HORIZONTAL, which means that the layout code needs to set it’s width first and then
      call prefHeight(width) to get the appropriate height. FlowPane & TilePane will have a contentBias that matches their orientation
      since they both wrap content.

      But the whole point of the getContentBias()/prefWidth(h)/prefHeight(w) is to allow layout code to generically handle this.
      Node#autosize(), Region#layoutInArea() handle all this under the covers, so if you’re writing layout code that needs to handle
      arbitrary nodes, then I recommend using these methods.

      Hope this helps, Peter!

      • Thanks Amy for answering my question

        In writing a Pane#layoutChildren() method, I came up with the following algorithm.

        CustomPane W
        has a set of children node C[0..N]

        1. Iterate through the children C, compute the pref size dimension, record this info P[] of C
        Effectively, call Node#prefWidth(h), Node#getHeight(h)
        2. Using the pref size P[], compute the appropriate layout the children, in to boundaries of Q[] of C, where Q is at least {x: Float, y: Float, width: Float, height: Float}
        3. Iterate through the children C, call Region#resizeRelocate() for Q[i] of C in order to position and possibly resize each child node C[i]

        I am not sure of above in the above, where would Node#autoSize() come into the equation?

        Autosize in 1 would effectively resize to preferred width on every layoutChildren() invocation

        Is the utility method Region#layoutInArea() actually calling Node#autoSize() behind the scenes?

  27. Marco says:

    Hi Amy,

    I am just starting with JavaFX, so please forgive any mistakes I might say.
    To start with, I would like to know why was the getChildren method of the Parent class, made protected. To have access to that method it is necessary to cast to the correct Parent implementation (Group, Region…), was there any special reason as to why this was implemented this way?



    • Amy Fowler says:

      Hi Marco —

      getChildren() returns a *mutable* list of the children. In many cases Node parent classes do not want to expose a mutable version
      of the child list. Parent#getChildrenUnmodifiable() (a real mouthful, I know) will return a read-only view of the child list. Group and Pane
      override getChildren() to return a modifiable version of the list so that applications can freely add children. Control and Region keep
      this modifiable list protected.

      I agree this is at times annoying and believe me, we spent many hours debating this API and ultimately decided it was important to protect
      the modifiable list of the children.

      • Marco says:

        Well Amy, I don’t want to argue with you, but you know, I really can´t see why you would want to return and immutable list of the children, in this specific case, GUI wise, I can’t see that being very useful.

        It really looks a bit strange not having access to the getChildren method of the Parent class, without having to cast a Parent instance to a concrete type.

        You could declare the getChildren generic, and make it return an immutable list of the children, when using the type Parent, but the otherwise for the Group, Region, etc… types, that´s just my idea, which might be completely out of any sense 😉


  28. Marco says:


    Also, would it be possible to add some method to the Application class, so that, at any point anywhere in the code, it would be possible to get the current stage. I think that this approach would be better then having to store it ourselves.



  29. Marco says:


    Still in relation to the Application class, and since you guys decided to give it such a meaningful name, why not built a wrapper for some of the functions we already now, and add a few more:

    Application.exit() — System.exit(0);
    Application.restart() — …

    I just think that the name you guys gave to this type, was not really appropriate, because Application in a sense, means the whole program, and having one method to start the GUI rendering… doesn’t look very nice.

    Why not call the type just JavaFX, since the only thing is doing is starting the JavaFX “rendering”.

    Maybe you guys will add some more functionality in the future o_O

    Overall I think that you guys are doing a very good job indeed, version 1 was a big mistake, but this version 2 is looking very promising.


  30. Marco says:


    Unless the meaning of what a label has changed, a Label type is not supposed to have any children nodes, so why does it have the getChildrenUnmodifiable method?!

    I understand, based on the class diagram you shown at the beginning of the post, that there were no other option, but was something like this:

    really complicated to implement (not trying to being ironic here 🙂 )


  31. Marco says:

    Sorry gave the wrong link:

    • Amy Fowler says:

      Hey Marco –

      But Label (and all Controls) are not childless – they have a skin child, which is the root of nodes that form the control’s internal structure. the point of getChildrenUnmodifiable() is to be able to traverse the full scene-graph; not something apps typically need to do, but tools and tests often do. Also, Controls that are conceptual parents (TabPane, SplitPane, etc) have class-specific apis (e.g. ScrollPane#setContent) to allow apps to add ‘children’, however such child nodes do not end up as direct children of the control because they get inserted somewhere farther down in the skin’s structure. We have considered adding an interface/api to provide a means for traversing the application’s ‘conceptual’ scene-graph (skipping internal impl-specific nodes) but so far no app has demanded it.

  32. Marco says:


    where can I input any bugs I find?? Just found one, where the Menubar and the Reflection doní go very well.


  33. Great article !!!
    I am playing with beta-b42-23_aug_2011 right now having great time

  34. BTW replace setVisible(true) by by show()
    no more setVisible in latest release

  35. Peter says:

    Hi Amy,

    Very nice article.
    I’m a complete newbie to JavaFX, therefore I do not know what kind of UI’s are being targetted by this technology. The company I work for has decided to rewrite their main apps in Java. The UI’s of these apps are very rich and graphically oriented. You can find some screenshots here:

    I made a small sample with JavaFX to ‘mimic’ the main view of one of those apps.
    Basically I noticed that the sample showed a severy performance problem when rendering
    ‘alot’ of text (i.e. 500 strings of 15 chars).
    Hence my question: Should I use JavaFX to create these kind of apps? If yes, is there relevant any documentation out there?
    Many thanks in advance,

  36. Pingback: Questions at My RMOUG Training Days 2012 Presentation on JavaFX 2 - GRAFIC DESIGN – GRAFIC DESIGN

  37. Hello,
    I have a problem with content bias in ListView cells: WordWrap in a cell is not working correctly. You can find a code-example here:
    Can you give my a tip how to use this? Or is this a bug in JavaFX2?

  38. Pingback: Get ChildNodes from JavaFX 2 Parent element | jacp developer blog

  39. Martin says:

    I tried JFXPanel on 3 Macs and it seems that when it is small everything works fast (>60fps) but as soon as it gets big like 2500×1200 fps drop to 5… i tried running the same scene in a ‘native’ fx window and the problem is gone… maybe you could tell me if this is expected?

    Thanks for FX!

    PS: Native LAF seems very important to me 🙂
    Also i would prefer set/get instead of property style – seems more java to me.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s