I have been getting a lot of great feedback on JavaFX after the launch and obviously a lot of questions too. Since people don't have the ability to walk across the hallway to question Jai, our PM for JavaFX, and get questions answered; I will do that here. I loved Osvaldo's blog. It contains a great set of questions, so I will respond to them along with a few others that I have encountered.
1. When will Sun publish a complete specification?
Sun is committed to open standards and open source, and specifications are coming soon. We'll be publishing the specifications for FXD, FXZ, FXM and the language spec for JavaFX Script shortly. We have already started working on a draft for the language reference guide for JavaFX Script.
2. Any plans for open source?
There are some dependencies on licensed code that cannot be open sourced. We are working towards decoupling the dependencies so that the non-proprietary portions can be open sourced. Currently the JavaFX compiler, Netbeans JavaFX plugin and Eclipse JavaFX plugin are already being developed in the open source. The scene graph is out in the open. We will put the core runtime out in the open over time.
3. A detailed roadmap
We will be rolling out JavaFX releases fast. The mobile platform will be released by March. You will get to see JavaFX Mobile in action at the Mobile World Congress in February '09. The current Desktop release of JavaFX 1.0 already has a beta runtime for mobile. The mobile release will be for OTA deployments that will allow JavaFX applications to run on existing phones. Following the mobile release, a visual designer tool for JavaFX will be available in mid-2009. Better media support with streaming capabilities will also be added in this release. We will be releasing bug fix releases on a continual basis.
4. Where is the public bugtrack?
Developers can currently file issues at http://javafx-jira.kenai.com/secure/Dashboard.jspa. We have linked this bug database from the downloads page at http://www.javafx.com.
5. Do you have plans to reduce the desktop FX runtime's dependency on Swing?
Yes we will be adding new UI controls and widgets that'll be based on the common profile of the JavaFX platform. This will remove dependency on Swing and allow the UI components to be used across all devices. We will, however, also provide a better integration for existing Swing applications separately.
6. Can you share more details about the FX Mobile platform?
We intend to support CLDC and CDC stacks. Ideally we would like people to build JavaFX Mobile applications on MSA subset to enable compelling solutions, but the JavaFX runtime has a hard requirement on mostly JSR135. At this point of time there are no plans to release a full stack with the OS. We might do that in the future though. Yes we intend to support a thin layer on existing JavaME stacks so existing partners can deploy JavaFX on the OS of their choice. There will be support on Windows Mobile.
7. What's the reason to create a new vector graphics format, the FXD?
The FXD file format provides significant advantages such as preservation of layers when a graphic created in Photoshop or Illustrator is exported to FXZ format. And FXZ can handle vectors and rasters as well. This allows developers greater flexibility in manipulating the exported graphics and creating amazing new visual effects.
8. Some people complained about ugly security dialogs
The security dialogs are critical in providing applications a secure runtime that allows deeper system access than other technologies. However we recognize the usability issues surrounding this model. Our goal is to make the Java browser plugin completely "invisible" while keeping the powerful security model of the Java browser plugin. Java SE 6u10 is a great step in this direction. Future releases of the Java runtime will further address these issues.
9. When will the JRE CDS be enhanced to support non-RT libraries?
At a higher level we are working on fixing the startup time for JavaFX and Java simultaneously. One of the initiatives is around the work that Mark Reinhold is doing with OpenJDK 7. Stay posted - we are making big changes.
10. Perspectives on performance?
We intend to continually improve performance. It is very high on the priority list. Our current focus is on JavaFX Mobile performance. The JRE provides a great foundation for this.
11. Do you intend to support other codecs?
The On2 VP6 codec is our cross platform story for media. We also support native codecs. Over time we will expand the number of codecs supported. We are also following OMS closely.
12. Will there be Linux support?
Yes there will be Linux and OpenSolaris support. Check out Josh's blog for more detail.
One of the best places to get answers is the FAQ on javafx.com/faq.
1. When will Sun publish a complete specification?
Sun is committed to open standards and open source, and specifications are coming soon. We'll be publishing the specifications for FXD, FXZ, FXM and the language spec for JavaFX Script shortly. We have already started working on a draft for the language reference guide for JavaFX Script.
2. Any plans for open source?
There are some dependencies on licensed code that cannot be open sourced. We are working towards decoupling the dependencies so that the non-proprietary portions can be open sourced. Currently the JavaFX compiler, Netbeans JavaFX plugin and Eclipse JavaFX plugin are already being developed in the open source. The scene graph is out in the open. We will put the core runtime out in the open over time.
3. A detailed roadmap
We will be rolling out JavaFX releases fast. The mobile platform will be released by March. You will get to see JavaFX Mobile in action at the Mobile World Congress in February '09. The current Desktop release of JavaFX 1.0 already has a beta runtime for mobile. The mobile release will be for OTA deployments that will allow JavaFX applications to run on existing phones. Following the mobile release, a visual designer tool for JavaFX will be available in mid-2009. Better media support with streaming capabilities will also be added in this release. We will be releasing bug fix releases on a continual basis.
4. Where is the public bugtrack?
Developers can currently file issues at http://javafx-jira.kenai.com/secure/Dashboard.jspa. We have linked this bug database from the downloads page at http://www.javafx.com.
5. Do you have plans to reduce the desktop FX runtime's dependency on Swing?
Yes we will be adding new UI controls and widgets that'll be based on the common profile of the JavaFX platform. This will remove dependency on Swing and allow the UI components to be used across all devices. We will, however, also provide a better integration for existing Swing applications separately.
6. Can you share more details about the FX Mobile platform?
We intend to support CLDC and CDC stacks. Ideally we would like people to build JavaFX Mobile applications on MSA subset to enable compelling solutions, but the JavaFX runtime has a hard requirement on mostly JSR135. At this point of time there are no plans to release a full stack with the OS. We might do that in the future though. Yes we intend to support a thin layer on existing JavaME stacks so existing partners can deploy JavaFX on the OS of their choice. There will be support on Windows Mobile.
7. What's the reason to create a new vector graphics format, the FXD?
The FXD file format provides significant advantages such as preservation of layers when a graphic created in Photoshop or Illustrator is exported to FXZ format. And FXZ can handle vectors and rasters as well. This allows developers greater flexibility in manipulating the exported graphics and creating amazing new visual effects.
8. Some people complained about ugly security dialogs
The security dialogs are critical in providing applications a secure runtime that allows deeper system access than other technologies. However we recognize the usability issues surrounding this model. Our goal is to make the Java browser plugin completely "invisible" while keeping the powerful security model of the Java browser plugin. Java SE 6u10 is a great step in this direction. Future releases of the Java runtime will further address these issues.
9. When will the JRE CDS be enhanced to support non-RT libraries?
At a higher level we are working on fixing the startup time for JavaFX and Java simultaneously. One of the initiatives is around the work that Mark Reinhold is doing with OpenJDK 7. Stay posted - we are making big changes.
10. Perspectives on performance?
We intend to continually improve performance. It is very high on the priority list. Our current focus is on JavaFX Mobile performance. The JRE provides a great foundation for this.
11. Do you intend to support other codecs?
The On2 VP6 codec is our cross platform story for media. We also support native codecs. Over time we will expand the number of codecs supported. We are also following OMS closely.
12. Will there be Linux support?
Yes there will be Linux and OpenSolaris support. Check out Josh's blog for more detail.
One of the best places to get answers is the FAQ on javafx.com/faq.
Just a tiny correction, the scenegraph (and css support) is not really out in the open, the old 0.6 version is, that's true; the v1.0 (with bug fixes and new features) on the other hand isn't yet, nor are the improvements and fixes that are being done or will be added in the future either, obviously.
So we don't really know if they are to be considered 2 different entities, or only one being dual licensed: gpl (in that case, where is the source ?) and fx license (which prohibits distribution of the runtime other than with jnlp extensions - so hosting the jars is a no-no guys) which seems a conflict of interest since open source licensing is all about restrictions and rights for the people you distribute software to.
Even then, the chosen license might also be too restrictive (especially within the open source community, which seems counterproductive).
It's more restrictive than OpenJDK's license itself which is way more strategic than the scenegraph. That's a little puzzling.
This is a question we've been asking for quite some time now, and we'd really like an answer.
But I'm also interested in this: why the change of heart ? It all started in the open, under openjfx branding. I'm sure renaming it to closedjfx would be bad for its image so the openjfx site is left gathering dust in a corner, even though it was for quite some time the only source of information on javafx (and that was not a whole lot btw, and the important strategic value of it certainly not up to the scope of what you're trying to accomplish with the technology).
The story is all in the older revs of the compiler runtime (with some funny things license wise, different licenses on different revs of the same file, a component which seems taken from the internet being, presumably incorrectly, dual licensed under incompatible licenses)
What's good for such strategic products such as java and openjdk must be good for smaller but still strategic ones, why the change of heart ?
Could we know the roadmap about splitting the runtime into an opensource + binary 3rd party, or an approximate ETA ? JavaFX has been a long time coming and very little communication has been effectively done since the early beginnings. We have quotes of Nandini Ramani dating back May 2007 stating the runtime will be open sourced, so this is certainly not a new topic for you guys internally or for us asking questions about it. A roadmap on that topic would certainly be of great interest to all of us.
Thanks Jeet
Remy
PS: the answer to point 7 is pure marketing spin :) Tried and tested (and even open standards) formats do the exact things you mention, and then *way* more. The tool that was written to export to fxd could have exported to any of those formats. It would have been more complicated to do so, and a constant source of bugs, maintenance and support issues, user dissatisfaction, for something that in effect you provide for free, i understand that completely. Knowing fxz/fxd i can tell you the answer has nothing to do with the question. Come on, that's not very nice.
Posted by lqd on December 17, 2008 at 01:17 AM PST #
Jeet, thanks a lot for your time and for a great reassurance of Sun's openness now for the JavaFX platform. I admit that some of my questions were mostly "baits" just to have somebody give authoritative answers. A few of the questions were already answered by others, or I found the answers.
One of the questions in the latter case is exactly #7. I'm just finishing to write a huge article on JavaFX, for the Brazilian leading Java Magazine publication (Portuguese speakers: stay tuned!), in this process I investigated and learned a lot, and now I think the FXD format is a great idea - which I explain here for Remy and other readers.
First off, FXD is not a different file format, it's just pure JavaFX code. More exactly, it's just JavaFX's Object literal format (in turn, basically static-typed JSON), restricted to scene graph trees. You can copy&paste an entire FXD into a JavaFX class if you want - or even do the reverse, with some restrictions (e.g. you can't have expressions like "height: 100.0 + 50.0" in the FXD, only literals). If you add that to the fact that JavaFX is also a great GUI DSL (doesn't need external syntax like XAML or Android's layout XMLs), this produces an incredibly homogeneous system where everything - application logic, GUI structure, and even sophisticated 2D image assets produced in high-end graphics packages - is represented in a single syntax.
[Of course that doesn't mean you should write your entire app in a monolithic "God Class" embedding multi-megabyte FXDs; but that's up to developer discipline. You don't instantiate a GUI as complex as the NetBeans main frame from single, 10KLOC initialize() method, even though Swing allows it.]
I see also that like I hinted in the blog, FXD is much easier to parse than SVG (no XML complications like namespaces, encodings etc.). I tested other SVGs that become even smaller in FXD, so it looks like a draw in size. But FXD compresses MUCH better. Try for example the list.svg in the WTK 2.5.2's SVGContactList sample:
- SVG = 35 Kb
- FXD = 34 Kb
- Zipped SVG = 10.4 Kb
- FXZ = 2.4 Kb!
SVG packs in a amazing 15-to-1 ratio. And it could be better, because it uses tons of spaces for indentation; hint to Sun: INDENT WITH TABS! I did a test and the result is:
- FXD = 17 Kb (!!)
- FXZ = 2,1 Kb (still a good improvement)
(The same spaces-to-tabs conversion in the SVG delivered a very modest reduction to 34 Kb, because the SVG used a much denser layout with little indentation.)
That's a HUGE advantage in my book, especially for mobile / JAWS / Applets. (But no surprise here, XML in general is Just Plain Stupid when it comes to efficient storage - even for the standards of text formats.)
Still, a formal spec of FXD is important for tool builders, people who write graphics packages and other programs that must read and write graphics files, because they won't want to learn the whole JavaFX or extract the relevant bits of its grammar and APIs, just for the sake of understanding the FXD format.
Posted by Osvaldo Pinali Doederlein on December 17, 2008 at 04:54 AM PST #
That's a useful concise FAQ.
By the way, for those who are confused by different JavaFX file formats (FXD, FXZ, FXM), so here is the explanation.
(or whatever those terms are officially called. The following terms is just my best guess from the abbreviation)
FXD: JavaFX Description File
FXZ: JavaFX Zipped Asset File (FXD + Resource files)
FXM: JavaFX MultiMedia File (On2's Video + MP3 Audio)
From URL: http://support.on2.com/javafx/
"JavaFX's native video file format, FXM, is composed of On2 VP6 video and MP3 audio."
From URL: http://javafx.com/docs/gettingstarted/production_suite/
"When you export a graphic from Adobe Illustrator or Adobe Photoshop to JavaFX, a file with an FXZ extension is created. FXZ is a compressed file using zip compression and file format. It always contains an FXD file, which is a text description of the graphic. In addition, it might contain embedded assets, such as image files or TrueType fonts. The FXZ file is used as a source file by JavaFX developers. The NetBeans IDE 6.5 for JavaFX 1.0 will display the contents of the file and also allow developers to view the graphic, the source description, and archive information."
Posted by GeekyCoder on December 17, 2008 at 07:14 AM PST #
Sorry Jeet, this is gonna be off topic as a reply to osvaldo.
Osvaldo, the problem is you didn't check the generated fxz close enough. The exporter doesn't seem to support custom svg fonts, and the smil animations are gone too. If you remove that from list.svg, the file is now 16k, which is also around 2.3-2.7k compressed just as the fxz. The amazing 15-to-1 ratio is surprisingly easy to obtain if you strip half the file. Try it in squiggle, you'll see the fxd looks nothing like the svg !
Also, how exactly the fact that it is easy to parse and compresses well (just as well as a zipped svg for instance as i've just shown) - which are the two features you give to validate fxd's existence while i say it's because it was easier and cheaper - gives "developers greater flexibility in manipulating the exported graphics and creating amazing new visual effects" ?
This is a rhetorical question, it doesn't.
I don't care about the shortcomings of the converter at all, I just wouldn't want people to believe blindly what you, Jeet (or Jai) just said before thinking about it for a minute.
My points still hold up. So let's not get into that discussion here, we can continue it if your want on your own blog, jeet needs his comment space for his own on-topic answers :) (hopefully answers to my other questions too)
Posted by lqd on December 17, 2008 at 07:58 AM PST #