Planet JFX
Don't have an account?
Register
Register

Reactions to JavaFX

Sign in to edit

Introduction[]

On 2007-09-13, Robert Field of the Sun OpenJFX team posted the following: 

The OpenJFX development team would like your feedback on the JavaFX
Script language.  Please provide details if you can.

Are there aspects of the language that made it difficult to learn? If
so, what?

Are there aspects that are difficult or awkward to use? If so, what? Why?

Are there aspects which you find confusing? If so, what?

How could JavaFX Script better facilitate development?

Is there any other feedback on the language that you would like to share?

Thank you for your time!

Here are several of the responses

Good things about JavaFX[]

  • Overall, it is much, much, much, much better than coding directly in Swing :-)
  • The bind feature rocks!!
  • I love it.
  • It's fantastic.
  • Good work so far.
  • Once you learn to use bind, you will never want to go back.
  • It is fun
  • It feels easy
  • It feels robust
  • It feels powerful
  • It feels productive
  • limited number of primitive types
  • use of cardinality characters ?, * and + in attribute declarations (defines sequences, implemented like Java ArrayList)
  • object literal syntax
  • range syntax
  • open classes like Ruby (can add attributes, functions and operations)
  • for loop supports SQL-like syntax (where clause)
  • can obtain a sequence of indexes in another sequence whose values meet some criteria
  • SQL-like syntax for obtaining a sequence of values computed from one or more other sequences (similar to XQuery)
  • SQL-like syntax for inserting and deleting sequence elements
  • triggers which define blocks of code to be executed when certain events occur, examples:
    • creating a new instance of a given class
    • changing the value of a given attribute in an instance
    • changing the value of an element in a given sequence
    • inserting a new element into a given sequence
    • deleting an element from a given sequence
  • reflection (can learn about the attributes, functions and operations of a class at run-time)
  • bind operator (can define an instance attribute so its value is computed based on the current values of other attributes)
  • GUI widget set that wraps Swing widgets
  • GUI widget set that wraps the Java 2D API
  • transformations are composable
  • animation with the "dur" operator
  • deployment options (JavaFX Script application, Java application, Java Web Start, Java applet, use JSR 223 "Scripting for the Java Platform")
  • Sequences - The way that sequences can be manipulated with select, delete and insert statements is excellent. Also, ranges in sequences are great. I wish that I had these features in Java.
  • JFX Script is a real paradigm shift and is a great idea and on the whole been done really really well. I'm sure with time and a bit of maturity to nail down the extra features (which it seems you are probably about to tackle hence the question to the list) it will get even better. My only advice is to try and balance new features with ease of use and understanding.
  • I really like the mandatory curly braces around flow control structures like if/else.

Issues and difficulties with JavaFX[]

Syntax and Language[]

  • The difference between operation and function is not clear, at least initially.
  • The mixing of quoted identifiers for Java qualified class names is not intuitive. It should not matter whether it is a Java or a JavaFX class (Groovy, for example, does not need to make this distinction).
  • What is a "private" class? "protected" class? Is the default scope for class package or public?
  • Why do you have to import java.lang classes?? Should there be other automatic imports (javafx.ui?).
  • If I declare 2 or more public classes in the same file, how to import from another file if the class name does not match the file name?
  • Can't extend Java Abstract classes.
  • Why is JavaFX script syntax so different from Java? Is this to help developers to keep them mentally apart? Is it because its target audience is a different one than Java's?
    • Why a new assignment operator for attributes? (':' instead of '=')
    • Why the un-Java-like variable definition syntax? What is the intrinsic value of the 'var' keyword?
  • Method overloading difficulties
  • I am never able to pronounce the name so I have shortened it to just JFX
  • This usage
    • The "var: self" syntax
    • "this" allowed in operations
  • JavaFX is inconsistent in the use of semicolons. This has been a constant learning battle. The IDEs help a little, but overall it's just too confusing about when to use them or when not to. My suggestion is either cut them out completely(ala python) or make them like Java and Javascript. The middle ground is too confusing.
  • Quoted Identifiers - It's not clear to me in all cases when I should use quoted identifiers and why they're required in particular situations.

Sequences and Arrays[]

  • Why a new array syntax? ('[]' instead of '{}') Would curly brackets syntactically interfere with block syntax?
  • Multi-Dimensional Sequences - Based on similarities in syntax between Sequences and Java Arrays I thought there was support for multi-dimensional sequences in the language, but based on a few threads on the user list, I think I misunderstood. It's not clear how multi-dimensional data structures should be handled in Java FX Script.
  • Sequences are confusing, they look like arrays, some parts of the documentation (last time I looked) call them arrays, most of the time they seem to act like arrays until you try inserting another one into them. I can see why you want them and think they are a good idea... but perhaps they need to use a different type of bracket or something to clarify that they aren't arrays? And how do you create an array of arrays? (or sequence of sequences)?
  • Unable to interact with Java APIs that use multi-dimensional arrays. This is especially common in game and algorithm APIs.

Threading[]

  • Do and Do Later, and the whole multi-threaded thing are confusing. Many GUI's utilize call back methods

especially if you are using RMI. There should be a way to indicate that an operation is a call back and should be handled in a thread-safe way.

  • can't explicitly control threads
  • by default everything happens on the AWT event thread

Numerics[]

  • Conversion between Numbers and Strings should be more straight forward. (i.e. var f:Integer = "5" should just work) Currently you have to use DecimalFormat.
  • The lack of usable number support is difficult to work with. I have had to write a few helper classes in Java to handle most of my number operations.

JavaBeans[]

  • Why can't I read a readonly attribute from a JavaBean Java class?
  • Understanding the difference between JavaBean and JavaFX way of accessing/modifying properties.

Binding[]

  • Why can't I just bind to a JavaBean property change for a Java class (internally via a PropertyChangeListener)?
  • Learning the power of bind has been interesting. Not that it is confusing, just need to think of things a little differently.
  • The only hard to learn feature of the language is the behavior of bind when used with a function as opposed to an operation.

Triggers[]

  • Clarification of trigger events would be nice. I'm never sure which trigger will occur on inserts/updates/deletes.
  • One awkward thing has to do with "replace" triggers for a primitive type. When in the trigger, the value has already been changed. If you change the value back, it invokes the trigger again. I've had to use an attribute to flag whether I'm currently in the trigger to avoid this.
  • Another awkward thing about triggers is that the "new" trigger is invoked before the attributes are assigned. To avoid this, I can trigger on an attribute, but am then dependent on the order in which the attributes are assigned in the object literal. I've had to resort to using the new operator with a Java-style constructor method to avoid this.
  • Triggers and attributes are no proper alternative to full properties. Properties are meant to provide a short syntax for accessing class attributes (without method call) while still providing encapsulation (a method is still invoked in the background which sets/gets the property). Simulating this behavior with triggers is not safe. Furthermore a read-only property does not rely on underlying attributes for its implementation, the property's getter method may compute the value dynamically, which is not possible with JavaFX Script attributes.

Strings[]

  • Lack of Support for Unicode characters.

Java Classes[]

  • There should be language support for Maps.
  • How to handle Class.forName("...."), currently you have to: Thread.currentThread().getContextClassLoader().loadClass("...");

IDE Plugins[]

  • Eclipse plugin improvments.
    • Keep it up-to-date
    • open-source the plugin

Wish List[]

  • Since JavaFX is useful outside of the GUI realm (that is, beyond just Swing and Java2D), make it more general-purpose.
  • Create more JavaFX class frameworks (SQL, XML, JSON,...).
  • Easy i18n with locale property files via aforementioned mechanism, and some way to easily load property files would be nice.
  • Easy GUI extensibility via plug-in-mechanism. In Mozilla's XUL, it is very easy to extend, say, a menu with an extra button and provide some functionality for it (at runtime!).
  • XML version of JavaFX Script, converters. This would greatly faciliate the creation of JFX code generators.
  • It would be nice if the JavaFX Script Engine implemented Invocable so you could interact more from the Java side rather than having to reach back to Java from JavaFX.
  • Make bind usable with PropertyChangeEvents from JavaBeans
  • It would be nice to be able to add triggers to the children of variables.
  • A subpart of the JavaFX Script language to be nothing more than a UI description language that could be accessed and used from the Java language.
  • I know that this is a security issue, but it would be nice to have a safe way to evaluate JavaFX Script code (without having to call FXShell.main() or the use the scripting JSR).
  • IDE plugin improvments.
    • Keep them up-to-date
    • open-source the plugins
    • Make the dev tools better. The plug-ins for Eclipse and Net Beans are both of mediocre quality. Make the plug-ins help developers learn how to write the language instead of hamper their development. Some improvements would be:
      • Make the syntax checking flawless and faster.
      • Complete Javadocs on the language integrated into the IDE
      • Make the connection between JavaFX and Java seamless.
  • generic event triggers to listen to user generated events, kind of like what the mouse events triggers (onMouseXXXX: ...) are for mouse events.
  • Document more of the features of the language. This will create a usage -> bug report -> improvement loop.
  • Open up the source sooner than later, even if under a license that's a little bit stricter than the final choice.
  • Communicate to the outside world that Sun still cares about the browser space. There may be billions upon billions of Java enabled cell phones, devices, or what have you, out there, but I don't get the chance to write applications for those cell phones.
  • it would be nice to have a callback from the "dur" operator so we know when the operation is complete.
  • More tutorials and demos! The community is working on this, but it would be nice to see more demos from the project leaders who know the language best. Ideally the demos would be centered around single concepts instead of a huge conglomeration of examples thrown together.
  • Video support. How can we compete with Flash without supporting video playback?
  • Support Binding to Java Objects - The bind operator in Java FX Script absolutely rocks. That having been said, I think that the the lack of support for binding between Java FX Script objects and Java objects will be a significant barrier to the adoption of Java FX Script. The models that I, and I assume many others, interact with daily are made of Java objects. With the wealth of Java libraries out there, I don't expect that will change any time soon. While it may be difficult to implement, we need Java FX to Java binding.
  • Chaining Animations - I would like to be able to have the start of one animation be triggered by the completion of a previous animation. It has not been clear how to do this simply without having to set up triggers that watch for some canvas element to be in a certain position. Some examples of animation events firing off additional animation events would be helpful.
  • Collections - As Java developers we've gotten used to a rich set of Collection APIs. Will we be seeing those in Java FX Script as well? I know that it's possible to import them and use them, but at that point they're Java objects and can't be bound to. It would be great to see basic HashMap/TreeMap, HashSet/TreeSet support in Java FX Script.
  • Animation Types - Is there a way to define animations as types so that they can be reused? For instance, a FadeOut animation type could be defined and then could be applied to any object instead of manipulating the opacity directly. In the opacity case, it's no big deal, but in more complex animations it might be non-trivial.
  • Change the Name - I know it's a marketing thing, but change the name of Java FX Script back to F3. Keep Java FX for the name of the product suite or the combined push for richer Java apps, but change the language name back to F3. It's not Java. It does include FX, but it does a lot more than that. It's only sort of a scripting language as it's compiled. F3 is a better name.
  • A web site with a rich collection of components. It isn't hard to define a shiny glossy button with JFX, but once you've done it a couple of times, you start wishing there were a library of shiny glossy buttons you could just pick and configure from. Ideally, the community would develop this, but I suspect Sun will have to seed it for it to take off. (Ed: small plug: Try Custom Widgets and Nodes for a poor man's version)
    • maybe a way of sharing your UI components and voting on the cool ones? comunity style... people could then look for ones they like- customize them as they want, could be nice.
  • 3D support via Java3D or JOGL. Let us create objects, animate them, define Cg/GLSL shaders inline. In fact, a Cg/GLSL-like language for defining 2D painters would probably be quite welcome.
  • Better, clearer and more comprehensive documentation... last time I looked the language had many new (and more importantly changed) features that aren't properly documented. I know it's dull, I know it's nicer to be coding but it makes it very hard to learn the language (and hence slows down adoption) if you can't work out how to do something.
  • Native support for html style colours (#FFAABB), if you are doing large amount of custom gui work (or better still passing it onto a gui designer to do the work) then the syntax for defining them needs to be concise and with the minimum learning curve. As a coder I understand floating point colours, a gui designer probably won't they understand html style colour definitions.
  • Better threading support... I think it's a large barrier to being a general purpose language that JFX is effectively single threaded, from my understanding the only code which is allowed to run in another thread (do/do later) is code which doesn't change the model and so basically just calls java code. I imagine it's not an easy problem to solve and would need to be designed properly so that concurrent variable updating doesn't cause unwanted side effects but it is probably possible.
  • A clear timetable of what is happening and when we can actually adopt JFX for commercial gui's.
  • More tutorials and documentation on teaching people how to think differently. We've already seen it on the list and in our own personal coding but the 'obvious' procedural way to solving the problem can be a big barrier to thinking in a declarative way and a good selection of examples and guides may help teach people to think different!
  • flash-style lightweight deployment - JavaFX as a alternative to Flex, but Applet + JavaFX in browser is not a good idea for me. I am watching the list and the samples, and i know that you guys from development team are doing a good job with JavaFX, but i wouldn't like get involved in the language details while i cant compare with other tools with the same purpose.
  • JFXPanel to integrate JavaFX into Java environment
  • Add property support to JavaFX Script. Attributes and triggers are no proper alternative (see Triggers).
  • Roadmap
  • Clear license -- At the moment SceneGraph is published under the GPL without the classpath exception. AFAIK this forces to use the GPL also for the own code.
Community content is available under CC-BY-SA unless otherwise noted.

Fan Feed

More Planet JFX