Now is the time for JavaFX to expand into other areas. Many of you will already have some ideas as to which areas JavaFX should head into next. Listed below are some some possible areas for JavaFX to head into next:
Android Support
By far this is one of the most requested ideas, JavaFX providing support for Android with a runtime. Android has become one of the fastest growing mobile platforms, which is quickly creating a potential opportunity for JavaFX to thrive on the mobile scene provided Oracle seize the opportunity. Google would certainly welcome the opportunity to support JavaFX as another viable option for Android development. The ball is clearly now in Oracle's court on this one.
If Oracle are really listening to the Java/JavaFX community then a JavaFX runtime for Android will be made publicly available on the official JavaFX website, to install onto Android devices. On the JavaFX website it appears as though a runtime may be available for Android. In the JavaFX FAQ the following section adds to the mystery, “2.5 Can JavaFX applications run on an Android handset?”. There is nothing to confirm or deny if there is a JavaFX runtime available for Android at this stage.
What I would also like to add which no one else seems to have discussed in the blog sphere is JavaFX providing access to some of the Android APIs. After all the JavaFX architecture (on the mobile side) has been designed to be completely platform independent, thus it should be possible for the JavaFX runtime to have access to major platforms other than Java.
Built-in Database APIs
Already I have covered this in a previous blog post but have mentioned this since it is an important area not to neglect. Most applications that are developed will have some access to a database in one form or another. With JavaFX it really needs built-in database APIs, not mere wrappers. Surely this would be a great opportunity for JavaFX to innovate in this space. If Oracle wishes to prove that it is firmly committed to JavaFX then this is a great opportunity to show it.
Full 3D Support
Currently JavaFX has partial support in this area. I firmly believe that the area of Graphics has always been a real strength with JavaFX. It would be common sense for JavaFX to have full 3D support. Again this is a possible area that JavaFX can innovate in, and with the arrival of Prism we may see this come to fruition in the next JavaFX release.
Basic Multi-threading Support
More and more cases are being covered where there is a great need for built-in multi-threading support. Especially on the front end side which is JavaFX's domain. Multi-threading support only needs to be basic since back-end processing in not really JavaFX's focus. A real focus on the front-end should be made here as opposed to the back-end.
Low Level Media Manipulation
Plenty of JavaFX applications do low level manipulation of media, but have to use the Java APIs. Some of these applications include Indaba Console, Blue Bill mobile, JPedalFX, MetaMaps, PiriMap, and TimeShot. Why not have JavaFX provide low level media manipulation APIs (with graphics, video, and audio)?
What this means is not only creating the media but changing it as well. This is an interesting area that has not been fully exploited by the other RIA platforms. If JavaFX really wants to stand out from the crowd in a useful way then this would be the area to target in order to get ahead.
While Android and multi-threading seem like good targets I'm not in agreement with trying to move every other Java API into JavaFX. If JavaFX had good two way interoperability with Java then there would likely be less of these requests in the first place.
ReplyDeleteI'm still left wondering how anyone could make a graphic toolkit like JavaFX and not include access to Java2D! If even this most basic, common and useful API is not included then why on earth should others even be considered. That would be putting the cart before the horse, not?
Torch - With adding new JavaFX APIs I did not convey that any Java API had to be moved to JavaFX. Merely just extend the JavaFX API's to cover new areas that would be beneficial, when creating a front-end application.
ReplyDeleteAs for Java2D this technology is restricted to the Desktop. JavaFX is designed to be used on other hardware platforms (eg Mobile and TV). Hence I could easily see the need for JavaFX to have a cross hardware platform rendering system (Prism). Would you want the graphics rendering to greatly differ, for an application designed to run on different hardware platforms?
Java2D is restricted to doing 2D rendering and originally was not designed with taking advantage of the graphics hardware. With JavaFX it was designed in mind to fully take advantage of graphics hardware and handle 2D/3D graphics. With JavaFX's current rendering system (Decora - uses Java2D) 3D graphics cannot be rendered, and the use of the graphics hardware (eg the GPU) for fast graphics rendering is extremely limited.
| I firmly believe that the area of Graphics has
ReplyDelete| always been a real strength with JavaFX.
Well, that's not true for every situation, if you have to draw large numbers of objects, Flash and Java2D is performing magnitudes better!
In fact even JavaFX 1.3 has no scenegraph capable to draw hundred thousands of nodes. In Flash and Java SE this is no problem.
In some situations even Java ME on a smart-phone with only 2,5 MB RAM and a 200MHz ARM CPU can outperform JavaFX on a modern core2duo desktop.
In fact the performance of the scenegraph is still the really weak point of JavaFX.
I think Oracle should solve the 2D performance issues first.
By the way I do not understand the official do-everything-and-anything-in-pure-JavaFX-doctrine. Java is the most popular oo-programming language among professional software developers.
So it's quite arrogant to tell developers who have used Swing for many years JavaFX would be better than Java2D and Swing. I bet that Oracle will not port neither JDeveloper nor NetBeans to JavaFX, because they know it better JavaFX is not always a good choice.
I even think without some Java experience it is not possible to find feasible workarounds to the current limitations of JavaFX.
I do not think that Oracle has any plans to port the good media support APIs of JavaSE to the JavaFX platform. ( http://java.sun.com/javase/technologies/desktop/media/ )
By the way there are Java2D implementations which can exploit the OpenGL or DirectX capabilities of the GPU drivers.
In the early days of JavaFX it was planned to build a mobile application stack similar to Android and SavaJe. But this great idea has been cancelled by some less gifted managers who did not understand why a more JavaSE like mobile platform is a real advantage over the traditional JavaME platform. Android must have been a rather traumatic experience to Sun. Android has been designed to be incompatible to Standard Java, business objective behind this decision was to build a walled app-market called appstore.
The performance of the first dalvik VMs was rather terrible compared to modern JavaME VMs, so claimed performance improvements were not truly there, but a first-class platform lock-in for Android phone buyers. ;-)
( Don't be evil is not doing things different - it is more about communicating things differently. )
Android has become that what Sun has dreamt of as they acquired SavaJe.
http://www.deviceforge.com/news/NS9280947932.html
http://en.wikipedia.org/wiki/SavaJe
Maybe this explains why Sun has shipped JavaFX for mobile Windows phones and not for Android.
Other good and politically more correct deployment targets could be maemo or MeeGo.
http://wiki.maemo.org/Task:Brainstorm_Java