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 #
@lqd
I don't understand Jeet's answer to 7; and I'm not sure of the reasons for Sun's decision to create a new file format. What I will say is - there are a number of scenarios where it *could* make perfectly good sense. For example, if you are developing a new platform for doing fancy things with graphics (e.g. like JavaFX); you can't predict what features you will want to implement in the future. Whereas, if you own the file format, you have the control you need to ensure that whatever you do in future, your file format can support it (lots of potential for future innovations in areas such as compression and delivery of content over a network etc, as well as graphical effects themselves). Or, it might be the case that existing "standards" in the area are too flaky and/or variable to be reliably supportable. Whereas, with your own format, you have the chance to ensure that your software supports your file format correctly.
Bottom line is: if you intend to innovate in your problem domain; and you have the ambition to build super-reliable software... then, I think there are good reasons to consider creating your own file format(s).
Posted by Simon Brocklehurst on December 17, 2008 at 08:46 AM PST #
Hi everyone,
I'm the guy who came with the FXD/FXD idea and who's team is working on the JavaFX Production Suite. The main reason for creating FXD (and FXZ as compressed version with embedded assets) was we needed a mechanism which would map 1:1 to the FX scene graph APIs. Because of that we couldn't really use SVG directly, as not all elements we have in FX are present in SVG (e.g. advanced filter effects, ) and also not all SVG features can be easily represented in FX (e.g. defs/use mechanism).
Furthermore we are planning to enhance the format over the time as the FX platform evolves - new scene graph elements are coming, high level components (UI controls) are coming, maybe 3D scene graph at some point, etc .... In the case we would be using SVG, we have to follow the standard and all advanced features coming from FX would have to exist in a different namespace and all tools working directly with SVG would obviously ignore them. Not exactly the best solution and definitely not scalable.
Also FXD has been designed to always map 1:1 to the FX classes. With SVG or other formats it would be nearly impossible to achieve the same (e.g. group is 'g' in SVG would you like to use class 'g' in FX - I'm not sure about that.).
And finally - FXD/FXZ has been designed as a design-time format. For the time being it is being used as the runtime format as well, but in the future we might introduce a binary runtime format, which would be a way more efficient than the design time. For you developers nothing will be changed, as you will always work with FXD/FXZ and the SDK/tools will be responsible for translating it into a binary form, so the the runtime will be able to read the optimized binary form and the runtime should be able to read that in a way more efficient way (this is important especially for smaller devices such as mobile phones or other embedded devices).
Let me know if this explained the reasons why FXD and not SVG or any other existing file format. I'll try to post this also to the official javafx blog.
Posted by Martin Brehovsky on December 17, 2008 at 10:14 AM PST #
The release-then-think-about-foss-licensing approach seems very backward to me and a lost opportunity. If JavaFX has been developed as a FOSS project with a community, as the original OpenJFX site seemed to suggest, then you would be less wanting for JavaFX developers now and it would be being packaged in GNU/Linux distributions as we speak...
If the media stuff is a problem, why not just use an existing FOSS licensed layer like Ogg Theora? I'd guess most content developers wouldn't care too much as long as there is a nice shiny button that says Encode and the result looks okay.
Posted by Andrew John Hughes on December 17, 2008 at 11:05 AM PST #
Screw On2, yeah, blabby blabby, flash supports it. You could have provided Theora or Dirac as a 100% cross platform stopgap measure till the codec was ready for linux.
I keep seeing this excuse, but HTML 5 did it for default video support.
Posted by Dan on December 17, 2008 at 01:09 PM PST #
lqd, Simon, Martin: thanks for the extra clarifications. It seems that graphics file formats are a topic of strong opinions, I found other blogs/forums with people arguing over FXD :) And yes, blame on me for not checking if the SVG->FXD conversion was complete. Anyway, the other advantages of FXD certainly hold, and Martin's details on that are just what I would expect. Happy to know the FX team is considering a good binary format (die ASCII, die!! he he)
Posted by Osvaldo Pinali Doederlein on December 17, 2008 at 05:09 PM PST #
@Martin
Is it also possible to create an FXD file from a existing scene?
(I'm looking for a serialization format for a simple JavaFX designer I want to build)
Posted by Kees Kuip on December 18, 2008 at 11:43 AM PST #
@Kees
Not at this moment, but this is certainly a good idea and it shouldn't be very difficult to create a writer which would output a structure for given scene graph tree. Please file an RFE to our bugtracking system: http://javafx-jira.kenai.com
@Osvaldo
You are very welcome. BTW I still see a value in an ascii based format for the design/build time. For the runtime though, this is a different story. This is especially important when you load really complex graphics we can easily output from AI these days - in this case an optimized binary format can make really a difference.
Posted by Martin Brehovsky on December 18, 2008 at 07:22 PM PST #
Hello Jeet (took me 10 tries to get the simple math question correct on this page btw)... Anyway back to the Designer Tool for me, rock on fx kids!
Posted by aNt on December 19, 2008 at 04:44 AM PST #
I'll try to bring another point of view to this talk, the content creator/provider one.
Considering audio and video support in JavaFX, On2 VP6 + MP3 is a show stopper. VP6 is ok, but MP3 is not.
For example, to get a good audio quality in MP3 a 128kbps bit rate is needed, while in AAC LC the same quality could be achieved in 64kbps and in HE-AACv2 48kbps would do.This bits wasted on audio could be used to improve video quality.
Considering de video side of the problem, H.264 is the way to go. It's a standard compression technology , widely adopted by the industry and is the way all the content industry and delivery platforms (Flash and Silverlight) are heading to.
We content creator/providers have got so much invested in H.264 + AAC, that I urge Sun, if you want JavaFX to succed as a media delivery platform then embed cross platform support for H.264 + HE-AACv2 is the only way to go.
Posted by Gabriel Lamounier on December 19, 2008 at 06:02 AM PST #
Re: 8. Some people complained about ugly security dialogs.
Yes. You guys NEED to fix this. This isn't just about deploying Swing apps on an intranet anymore. If you want JavaFX to come onto the open web as a viable Flash/Silverlight alternative, a security dialog is simply unacceptable. Does youtube need to show a scary dialog every time it shows a video? Neither should JavaFX.
Please have the plugin silently accept JavaFX runtime9 permissions or whatever you need to do to make this problem go away.
Posted by Bruno Garcia on December 22, 2008 at 03:47 PM PST #
This is a cross-post of mine from Kirill's blog:
h264 is a patented codec and distributing h264 content(not even codecs, just content) within your software is subject to royalties unless you're not making any money by providing it, not even indirectly via advertising.
Hence, h264 is an awful codec for "developers". On2's codecs specifically circumvent this by allowing 3rd parties to distribute VP6 encoded content royalty free. This is a gift from Sun wrapped up with a bow tie on it and I'm struggling to understand the resistance.
The crying over audio quality loss of mp3 vs AAC is also a perfect waste of time as most of users are listening to audio on either $5 headphones, built in speakers, or low quality desktop ones.
If audio is really paramount, one can:
a) bump up the mp3 quality to 256kps
or
b) distribute different content for different OS's since Windows will support WMV/WMA and OSX will support h264/AAC.
Any decent NLE will let you export the timeline differently this way.
For 5 min of 44.1 kHz stereo audio, there is a 3 mb difference in file size between 48kbps and 128kbps. This will buy you very little in terms of video quality and, in general, is somewhat irrelevant given the massive pipes and file sizes everyone's become accustomed to. Non-issue.
I'm realy not seeing any real drawbacks so far, and some huge advantages for us Java multimedia developers.
Posted by Alex on January 02, 2009 at 08:23 AM PST #
"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."
==> Frankly this is NOT answering this enormous issue.
How difficult it is for us developers. We work month and month is not years to have an "almost perfect" java Web service and them our ambitions are stopped by this issue. People see now java as a scary platform, not Flash.
Look : our potentieal clients are anyone on the Web.... thus most of them do not feel secure with this warning dialog.
One thing : think about the sucess of Youtube or any Video Flash service. Do you think those would have had the same sucess with a "security Warning dialog". Of course not...
You really want java to be part of Web-service and Mashup ? Them I think Sun should get rid of those awfull scary dialogs.
Thierry
Posted by Thierry on January 03, 2009 at 03:27 PM PST #
Is Sun thinking of deprecating J2ME in favour of JavaFX or are both roles of both technologies complementary in long run(and just not in immediate short run).
Posted by Saurabh on January 06, 2009 at 02:49 AM PST #
@Alex
I see your point, but you haven't seen mine. We, the content industry have got an uncountable amount of content already enconded in H264+AAC that are delivered everyday to iPods, iPhones, flash players, mobile phones, blue ray discs, etc.
Why would us have to reencode our assets just to deliver it via javafx? This would increase production and storage costs considerably.
On the quality issue, VP6 and MP3 are much less eficient than h264 and AAC. Increasing the bitrate of them to get better quality is not an option as it would considerably increase storage and delivery costs.
I'm not talking about creating an application and deliver some media embeded within it, I'm talking about massive content distribution.
Posted by Gabriel Lamounier on January 07, 2009 at 08:26 AM PST #
I am very excited about JavaFX, it's possibilities and architecture, but the path that was chosen for cross-platform media support makes me worried for if it will succeed on that terrain.
I'm sure the deal with On2 was a good one from a commercial point of view, but I'm not sure if you can get revenue from a technology that technically was a dead-end road already for Flash.
@Alex
The On2 codec way will quality-wise be rather fine when looking at Video-on-demand only. Especially as supposedly JavaFX would support On2 VP6's successor VP8 at some point this year(?).
But the story is a different one when it comes to live streaming. I know this chapter hasn't been written yet in JavaFX, but it starts under very unfortunate preconditions with the On2 technology. Even if JavaFX would support RTMP as streaming protocol, and thus you could use the few (2) livestream-encoder available in the Flash ecosystem, you gonna have big problems finding the right solution for many needs. Not even speaking of lacking support by widely used FLOSS standard tools like ffmpeg and vlc. If this threat of low accessibility of live-streaming to JavaFX is not adressed, JavaFX will not be able to challenge Flash as the top dog of live stream receiving. And we aren't even speaking about live encoding support...
I know you can't have everything that is in Flash right now, but the general direction taken by now really worries me.
Regards, Alex
Posted by Alexander Bethke on February 19, 2009 at 01:32 AM PST #
i want javafx with database connectivity.can JAVAFx provide this feature for the web applications
Posted by SapSandman on February 23, 2009 at 01:23 AM PST #
Draft spec link is 404.
http://tinyurl.com/588o2w
Posted by Joshua Smith on February 26, 2009 at 09:50 AM PST #
Third ... Rosenberg says that we are opening our "competing proprietary products long after a successful open source project has eclipsed their proprietary alternatives." He then juxtaposes SPARC vs x86 as an example of this. Fascinating. I didn't know that OpenSPARC was in response to the previously open source x86 project. I must have missed that one.
http://www.watchrolexshop.com
http://www.gamegoldme.com
http://www.cheap-lotrogold.com
http://www.globalsale.me/Aion-gold-083.aspx
http://www.cheap-gamegold.org
http://www.gamegoldvip.org
Posted by replica rolex on June 25, 2009 at 01:38 AM PDT #