February Open Source Update
by Richard Bair | Feb 11, 2013 | News | 49 comments
We’ve been making progress in getting JavaFX open sourced. I wanted to take a few minutes to include this information on fxexperience (since many of you aren’t watching the mailing list). Oh, and you might want to read this one, there is some big news at the end of the post 😉
Late last year at JavaOne our Executive VP Hasan Risvi announced at JavaOne that we would be open sourcing all of JavaFX by the end of 2012. We didn’t quite make that (actually, it was a pleasant surprise to me as the announcement was made as much as to everybody else in the audience!). We quickly got into gear and started the substantial effort that goes into open sourcing each project. We have a lot of code. The following projects have already been open sourced as of this writing:
| Project Name | Release Date | LOC* | Description |
|---|---|---|---|
| apps/ConferenceScheduleApp | Oct 22, 2012 | 11,052 | Conference schedule application shown at JavaOne 2012 |
| apps/Modena | Nov 27, 2012 | 2,578 | Experimental application as a playground for prototyping a new look and feel for JavaFX |
| apps/ModenaTest | Jan 23, 2013 | 289 | Simple test app for Modena |
| decora-compiler | Nov 06, 2012 | 20,032 | Build-time tool for compiling .jsl files into fragment shaders |
| decora-d3d | Feb 07, 2013 | 45 | D3D specific decora implementation |
| decora-es2 | Feb 07, 2013 | 45 | OpenGL ES 2.0 specific decora implementation |
| decora-jsw | Feb 07, 2013 | 9,891 | Java2D Software decora implementation |
| decora-prism | Feb 07, 2013 | 1,033 | Prism-based base classes for implementations of decora |
| decora-prism-ps | Feb 07, 2013 | 4,157 | Pixel shader / prism based implementation of decora |
| decora-prism-sw | Feb 07, 2013 | 529 | Software / prism based implementation of decora |
| decora-sse | Feb 07, 2013 | 5,378 | Native SSE implementation of decora (java half) |
| decora-sse-native | Feb 07, 2013 | 7,733 | Native SSE implementation of decora (native half) |
| deploy | Dec 18, 2012 | 13,356 | JavaFXPackager and launcher deployment tools |
| javafx-anim | Dec 18, 2012 | 17,622 | Animation APIs and implementation |
| javafx-annotation-processor | Dec 18, 2012 | 1,569 | Builder-generator annotation processor (build-time only) |
| javafx-beans | Feb 05, 2013 | 100,041 | Beans, Properties, and Collections |
| javafx-beans-dt | Dec 12, 2011 | 6,443 | Design-time API for Beans (not shipped yet, but used by SceneBuilder) |
| javafx-common | Dec 18, 2012 | 7,758 | APIs common to all of FX (events and utils) |
| javafx-concurrent | Dec 23, 2011 | 8,368 | Worker, Task, Service, and related concurrency APIs |
| javafx-designtime | Dec 12, 2011 | 683 | Design time implementations (not shipped) |
| javafx-embed-swing | Feb 04, 2013 | 2,224 | Swing embedding APIs |
| javafx-embed-swt | Feb 04, 2013 | 1,990 | SWT embedding APIs |
| javafx-fxml | Sep 20, 2012 | 11,302 | FXML API and implementation |
| javafx-geom | Dec 18, 2012 | 32,180 | Internal geometry classes used by prism |
| javafx-logging | Dec 18, 2012 | 378 | Internal logging helper |
| javafx-sg-common | Dec 18, 2012 | 4,344 | Internal interfaces for scene graph peers |
| javafx-sg-prism | Dec 18, 2012 | 10,537 | Prism scene graph peers |
| javafx-ui-charts | Feb 23, 2012 | 9,316 | Charting APIs |
| javafx-ui-controls | Nov 10, 2011 | 154,214 | UI Control APIs |
| javafx-util-converter | Dec 29, 2011 | 2,902 | String converter APIs |
| pisces | Dec 18, 2012 | 3,735 | 2D software rasterizer |
| test-stub-toolkit | Dec 23, 2011 | 4,855 | Stubs for testing |
| tests/bigapps | Feb 10, 2012 | 468 | Start of a big-apps test based on Ensemble |
| tests/functional/SceneGraphTests | Dec 17, 2012 | 57,090 | Functional tests for the Scene Graph |
| tests/tools | Feb 03, 2012 | 28,918 | JemmyFX for functional testing of JavaFX apps |
* LOC is just a simple wc -l on the Java files (and in the case of javafx-sse-native the .cc & .h files). This is not comprehensive, doesn’t include build files, etc. But it does include tests.
An additional 7 projects should come out within the next two weeks (glass, image I/O, and much of prism), representing another 138,034 lines of code. We’ll follow that by releasing the remainder of prism, web, and media sources within the next one-to-two months. At that point we will ALMOST be fully open source. The only remaining nugget is javafx-font, and we’re working on the OpenJFX list on a plan to replace this in the open source with direct calls to the native operating system.
We’re also going to open source our iOS and Android implementations over the next couple months. We THANK YOU for filling out the survey forms we posted last month, these were of great value. A majority of you said you’d contribute to an iOS / Android port (either via bug reports or direct code contributions) and we’re working hard to be setup so that when the code is opened you’ll be able to start in on it. One aspect of this is fixing up our build / test setup so that it is trivial for people to build and test fixes on JavaFX (including us!). I’ve prioritized fixing the build / test system now so that we will be in a position to accept contributions at a more rapid pace. The first bits and pieces for iOS should be out next week, with the rest of iOS and Android coming out at about the same time as the rest of prism (there is some timing dependency there). Both our ports are based on an as-yet unreleased version of JavaSE Embedded for iOS/Android.
There have been some question about licensing on iOS as Apple doesn’t allow for GPL licensed applications in their app store. OpenJFX and OpenJDK are both licensed with the same GPLv2 with Classpath Extension. My understanding (and I’m not a lawyer) is that this means that if you take OpenJFX + OpenJDK (minus any binary stubs released under a different license), then you can safely combine this with your application and release your application under your own license as a single application co-bundle. You can do the same with the GA release of JavaFX + JavaSE. The difference is that we do not yet have iOS / Android on our official release roadmap, so that for the time being, the only way to use JavaFX on iOS is via OpenJDK / OpenJFX. I can imagine this would make open source guys smile (open source goes where closed source does not!). This is also why we’ve been prioritizing open source so highly for the last little while — when OpenJFX can be built without any binary stubs, then there is nothing stopping you from taking OpenJFX with iOS port + OpenJDK and creating commercial applications that can be sold in the iOS app store.
I am looking forward to seeing what you all will do with this contribution, and hope to be running many Java apps on my phone / iPad in the near future.
Update 2/19/2013: The response to this post has been incredible! I got a ton of positive feedback, both here and in the press. It’s great that there is so much interest. In reading all the feedback and media coverage, I’ve realized that I there are a few things I should clarify. I mentioned "We’re also going to open source our iOS and Android implementations over the next couple months." It turns out that that statement can be read in a bunch of different ways, and deserves a clarification. I’ve made the same points previously on the openjfx-dev mailing list, but not everybody reading this blog is also reading the mailing list and so some context is missing.
A few years ago at JavaOne 2011 we showed a demo of JavaFX running on Android and iOS devices. This was a proof-of-concept which has two essential elements. The first is a port of the Windowing / Graphics layer of JavaFX (Glass & Prism) to use iOS & Android APIs. This is what we are open-sourcing, nothing more nor less. We are not providing a JVM for these platforms, nor am I aware of any such plan, so it’s not in any way a complete solution. Nor do we have a plan for releasing these ports in any release. We’re just opening up JavaFX code to the Java community for further experimentation.
Speaking of which, there are a ton of things that we continue to look toward the community for help with in the core platform which apply to all our target platforms including desktop and embedded (such as the Raspberry PI). There are a lot of areas that need more work, such as support for X on Raspberry PI, a Windows 8 Metro port, more controls (formatted text anyone?), performance optimizations, 3D, printing, internationalization, camera and video recording and much more. If you want to pitch in on any of these projects visit JIRA or our openjfx-dev mailing list!
I also received some questions about my statements regarding the GPL and Apple. I told you I wasn’t a lawyer and I wasn’t kidding! Law is complicated so it’s probably just best to disregard any statements I might make on the subject.
Lastly, cross-platform development for these mobile platforms isn’t a first for Oracle — check out what my colleagues over in Oracle’s Java Tools and Frameworks group released a few weeks ago with Oracle ADF Mobile. You may have seen the announcement at this past JavaOne. You write your logic in Java and use HTML5 for the UI. The best part is that if you use JDeveloper you have an environment with declarative binding to datasources and the whole bit. So far, they’ve released it on iOS and Android – and it’s fully supported. Oracle is basing most of its mobile application development going forward on ADF Mobile and customers are already having success like the folks at ECSTeam. You can download it and try it out for free.
I hope to see you on the dev list and can’t wait to see what we can do together in this community!
49 Comments
JavaFX on android and ios ! really ?
ReplyIt’s amazing.
just one word…AWESOME !!!!
Thanx a lot for making it possible !
ReplyGreat news! Congrats and thanks to all!
ReplyThis is stunning news!
I tried doing `gradle build’ on Sunday; of course, it did not quite work yet, however I am sure with the correct JDK8 bundle and time it will. Great stuff!
ReplyJavaFX on Android and iOS implementation will be no longer a rumor!
ReplyVery positive direction!!
ReplyHi Richard,
thank you very much for all your great efforts! Thanks Oracle!
Could you please tell us more about the “unreleased version of JavaSE Embedded for iOS/Android”? Is it a special version of JavaSE embedded ARM?
What about your prototypes for iOS and Android? Do they use AOT? If we want to build iOS apps for the AppStore we need one single binary! So we need AOT…
Best regards,
ReplyTobi
Thank you…that will be a game changer…
ReplyVery good news!!
When ios and android ports become possible JavaFX will reign the UI toolkit scene, for sure.
How will the contributions to this open source project work? will it be like what happens with the rest of the javafx sdk?
Cheers,
ReplyAMAZING!! This will end up being one of the most disruptive events in the history of programming! JavaFX rocks! A HUGE THANK YOU!!!
ReplySuper Cool!
I don’t want to sound cheesy but I was thinking about the movie ‘Field of Dreams’ where Kevin Costner hears the whispering of “If you build it, they will come.”
Being able to build everything will be awesome.;-)
Keep up the amazing work!. Kudos to the JavaFX teams.
Thank you!
Carl
Replycooooooooooolllllllllllllllllllllllllll………………………. Java Rocks……………..
ReplyExcellent news !!
JavaFX is really a broken rules Toolkit, and Oracle an awesome OpenSource contributor 😀
Big Thanks to JavaFX Teams !!
ReplyThis is awesome news!
Can’t wait to try out and spread the word 🙂
Thank you very much
ReplyI like to say “I love you JavaFX” . My 2013 Valentine is you 🙂 …WAITING FOR ios and droid develpment
ReplyCongrats. I believe that community support will increase exponentially. Could spend more information about java SE is embeded ANDROID and IOS?
ReplyThis is so great Richard!!!
BIG THANK YOU to everybody on the Java/JavaFX teams!!!!
ReplyThanks a lot! You’re awesome!!
ReplyWhat an awesome news !!!
Thanks a lot to all of you @Oracle to make this possible.
ReplyMarvellous!
ReplyThis is amazing!
ReplyWow. I was impressed with the FX demos at JavaOne and in the FX HOL. If there are iOS and Android implementations, and it is OS with reasonable licensing, it gives me hope that FX could get some real traction in the marketplace. It’s nice to see you are keeping the momentum going. It will be interesting to see what FX there is at J1 this year… If Android release is ready we might try to do a project at java.net for home automation…
ReplyOhhh My Gosh , This Is Awesome …free at last, free at last, thanks Oracle almighty JavaFX is Free last …
Humm JavaFX on IOS and Android that’s Just Insane …man i’ll believe when i see it !
Keep Up the Good work
Thank you JavaFX Team !!!
ReplyBest news of the last decade or century!
ReplyThank you JavaFX Team … and Bair you are Man to next java revolution
Thanks Richard for all the hard work you’re putting into this. OpenJFX is an amazing and very rewarding project to work on, and this is definitely you’re biggest merit!
ReplyThis is the best news for 2013!
ReplyThank you guys.
I’m extremely excited to see the Android / iOS stuff.
I’ve been spending a decent amount of time looking at the options for mobile development over the last month and I was starting to get pretty dejected about it. The web-based options produce a sub-par UI, the native options require A LOT more work, and everything seems to be built on a network stack that’s far more complex than what I need for the types of applications I want to write.
I bet we could eventually see some pretty compelling end-to-end Java application platforms built around JavaEE, JavaFX, the Application Client Container, and upcoming v8 language features. How about one line of code that gives you a CompletableFuture that’ll contain the result of a server side call from an auto-magically injected resource plus it works across desktop and mobile? Yes please!!
Reply“I bet we could eventually see some pretty compelling end-to-end Java application”
Hopefully we will also see it become similar to Vaadin but using Java all the way.
What I would like to have is a solution where I write a single application and Java separates it into a serverside war and a JavaFX applet. I would want annotations like @RunAt(Server) and @RunAt(Client) which will mark which class of function goes where. Java should take care of all function calls that happens between client and server and whatever advanced network code that is used for it.
ReplyHuge respect Oracle!!! Stay the course.
ReplyThis is Oracle’s style: not much talking and vaporware, but instead lots of hardworking behind the scenes to finally give us amazing results!
I’m glad to know I won’t have to go for HTML 5 and code my applications in javascript when there are far supperior choices in the Java platform, such as Scala.
Thanks Oracle for the commitment and investment made to the Java platform!
ReplyYou’re awesome!!!
ReplyThanks a lot for great work.
You might have just saved me 200K — thank you.
ReplyGreat!
ReplyThanks Oracle.
ReplyYeahHhhHhHhhhH….!!!! Thats what it defines JAVA cross platform… OnAndroid and OniOS
ReplyJavaFX on Android and iOS! What about? Great news, thanks for your great job! Really.
ReplyIt’s soooooooo GREAT! Huray Oracle! Huray JavaFX!
ReplyWould someone create JavaFX mobile OS like Addroid? We propose Oracle to do it.
ReplyExcelente.
ReplyFelicitaciones.
“There are a lot of areas that need more work, such as support for X on Raspberry PI, a Windows 8 Metro port, more controls (formatted text anyone?), performance optimizations, 3D, printing, internationalization, camera and video recording and much more.”
I have noted that Java do not use Qt which I think would simplify a lot of this work. Are there licencing problems or any other reason to not use Qt?
There are lots of overlapping functionality in the OpenJDK sources I have reviewed and Qt. Unless there are some really compelling reason not to use Qt and save a lot of development cost I do not see why the Java developer should reinvent the wheel and maintain multi-platform code where Qt already does this.
Qt5 has support for X on many platforms, including RasPI. It is likely that Java would not need to do anything to support RasPi:s X.
Qt Controls are quite fast, able to utilize hardware acceleration and integrates well with OpenGL. The currently unsupported QtJambi integrates support for JOGL.
Therefore Qt would work well as a base for JavaFX, Swing and Java2D.
QtWebKit are ported to many platforms. I have observed that JavaFX also ships with webkit which are in the pipeline to be released. Again the wheel have been reinvented.
More controls? Qt have a many controls, including formatted text… and QtWebKit.
Printing? Qt have platform independent printing including print to PDF and PS.
3D? QtJambi supports 2D + JOGL integration that works quite well.
Internationalization? While Qt have that I suppose that doing something in pure Java may be better.
“camera and video recording”
Qt have platform independent support for cameras, video recording and playback. Making a platform independent music and video player in Qt is quite easy and that could naturally be useful for Java.
And also there are the big elephant in the room. Bindings. Qt have the community project QtJambi that provides Java bindings for Qt. Those are not officially supported by digia that owns Qt, but I bet that Oracle can fix that with a phonecall.
By utilizing existing code like Qt you decrease development and maintenance costs for everything that’s supported by that code. That cost could be redistributed in order to provide more functionality in other areas.
ReplyJust great to have an alternative to Objective-C! We are with Java since 1997!
ReplyTrackbacks/Pingbacks