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.

We seem to have unfortunately trained people in some bizarre Pavlovian way to bash Sun no matter what we do. And boy is this topic the best example of it.

I like OSGi. I have been a big supporter of OSGi for some time. Check this out. I have had the pleasure of running the GlassFish and NetBeans teams. Very early on the GlassFish team had an eclipse plug-in, explored alternative languages and frameworks and embraced OSGi. Check out what an amazing job Jerome Dochez is doing with GlassFish v3 and how integrated OSGi is in his implementation story. Here is Ludo Champenois, who drove the Eclipse plugin for GlassFish, talking about GFv3 and OSGi. The NetBeans team had internal projects some time ago looking at incorporating OSGi intimately. Hopefully paving a way to engage closely with Eclipse IDE.

Clearly not only am I still at Sun, but I have been given the awesome responsibility of running the Java team. This is the new Sun. We have been going through a transformation in the last 5 years. We are a lot more pragmatic about things and a lot less dogmatic. We are slowing making changes in places where we have been entrenched for years.

I was pleasantly surprised when Mark Reinhold, Lead Architect for JavaSE, came to my office and told me it was time to walk away from JSR 277. It was bold thinking and I loved it. Although I had been thinking about this for some time but I was totally caught off guard. There is no reason for us to standardize and implement a module system (JAM) on the fly. It makes no sense. Yes we pushed for it, but it was not the right thing to do. There are aspects of JSR 277 that I do like. The interoperability layer which enables multiple module systems to plug in is a worthwhile effort. We need to focus more on actually modularizing the JDK and less on the module system we will use. The interoperability part of JSR 277 will allow us to do that. There will probably come a time when we can standardize all of OSGi into Java, but today is not the day. It is incumbent upon us to resolve long standing issues that people have had with Java and the effort that Mark is driving to modularize the JDK is the first and foremost thing to do.