This content has been marked as final. Show 182 replies
Java is just a hammer. I love software engineering; I happen to prefer Java as my favorite hammer but I'm not going to cry when I have to switch to another tech, just as long as I can keep being creative.
Java is more than just a hammer, it's the whole toolbox plus some. With JavaFX, I now have a modern, complete, unified Java based technology stack from the front end, all the way to the back-end......except I can't deploy a client to IOS/Android/<Insert Mobile Device Name Here>. This seems a very odd omission from my point of view, given the superiority of JavaFX over HTML5 (again, in my opinion) and the opportunity that Oracle has to fix the mess that is the current state of mobile development with something like a JavaFX mobile deployment target. Imagine the current army of Java developers with access to this type of technology......the possibilities would be endless.
I'm not going to abandon Java over this, or cry over it but as another poster said, working with an inferior technology on the front end is going to be a tough pill for me to swallow.
Surely +"Hey <manager from company x>. With JavaFX, your Java developers can write applications that work on iOS and Android, as well as desktop platforms. No need to have them learn an entirely different language or platform."+ should be enough of selling point ?
I teach Java for a living, and even though I love JavaFX and rich client apps, I haven't seen any of my students start a career as a rich client Java developer. I know of only two that did some SWT as part of their internship. Most, if not all, students that end up using Java as their profession, do so because of Java EE and Spring. Students who end up doing rich client development are using .NET, Cocoa or Android.
If JavaFX evangelists are saying that rich client apps are coming back, I'd say they are right. But they are coming back because of smartphones and tablets. So an API for rich client application that doesn't support those devices is pretty much useless.
I find it frustrating that in the coming years, I will probably have to teach more HTML5 and Android and less Java, when I have a superior technology like JavaFX lying around, just begging to be used to its full potential.
Like most higher education institutions in my region, we use Java as the main programming language throughout our curriculum. Just imagine what could happen if our existing 'army' of skilled Java developers could leverage their existing skills for mobile devices as well...
The more I think about this, the more I realize I took a very one sided view of things in my first post. Since no one has done it yet, I'll play the devil's advocate. I'll use Apple / iOS as an example, but the same argument can be made for every closed ecosystem (ex: WinRT).
If I can't guarantee X years of support for an application, I can't sell it. Apple's closed ecosystem makes it impossible for me to offer any support. Even if they "approve" my application, I can't guarantee it's going to remain available, I can't create a consistent release schedule, I can't control bug fixes, I can't test updates across X% of my user base, I can't (easily) rollback broken updates, I can't maintain an older version of my application for customers with devices that have been abandoned (ex: the original iPad), etc..
If supporting a closed platform is a requirement for a business application, I think the web is the only viable option right now, even if it sucks. However, if skipping support for the closed platforms means getting a higher quality application for less money, I think you'd have a lot of people that would consider that a reasonable trade off.
I'd still really like to see JavaFX on as many mobile platforms as possible, but I think there may be some value in limiting it to open, developer and business friendly platforms. How hard would it be to get JavaFX on Android? Win8 Pro? QNX (BlackBerry)? IMO, Android + 1 other would be a good start.
I'm curious what kind of applications people are hoping to get onto iOS and how they plan to support them.
I agree that Android would be the logical starting point - it is both technically and legally a lower hanging fruit. iOS could come down the road. What's really needed/lacking is a vision and a roadmap of this to give developers confidence that JFX is a platform to use for "consumer" apps (i.e. those for use by the general public on whatever device they normally use). Currently we have a roadmap openly stating that smart device platforms (the most significant "consumer" platform out there) are not part of the Oracle's vision. This lack is an undeniable turn off for companies evaluating technologies to use in their suite.
On top of that we have long standing, known issues with JFX as a platform for regular, everyday "consumer" desktop apps. If you haven't actually tried to release and maintain a consumer desktop JFX application (and I've yet to come across any out there?) you may not yet realise that there is no good way to distribute your app to your end user that either works reliably or has a user experience that you'd be willing for a member of the general public to go through. The packaging docco (http://docs.oracle.com/javafx/2/deployment/jfxpub-deployment.htm) makes it sound pretty cool, but it is definitely not all roses. JNLP and Applets are both buggy and inherently flawed, plus the installation user experience is one that even techie users find awkward, off putting and ugly - definitely not something you would want your general member of the public having to do. Native installers are better and show promise but they have a rack of their own problems and in my opinion are still very raw (see http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-November/004228.html for more info) and there is no push to improve these any time soon.
JFX has MASSIVE potential for "consumer" apps. Having used JFX on some actual projects, my opinion is that it still has a lot of teething issues. As a new platform, teething problems are understandable and acceptable but what should balance this out is the backing/vision/roadmap - it was the potential of JFX combined with Oracle pushing to realize that potential was what sold JFX to me despite its rawness.
JFX didn't physically change at JavaOne at a code level. What did change was the direction it was heading, i.e. Oracle's vision for JFX. Mobile/smartdevice support was dropped simultaneously with a high-publicity announcement that Oracle would be massively backing HTML5 as the platform for "rich client side applications". Nothing changed, everything changed.
As it stands, it really does look like Oracle is not interested in backing JavaFX in the "consumer" space. They are happy to focus on selective, high-end "enterprise" apps that have controlled OS environments and distribution mechanisms and low requirements for mobile support (such as a large corporate where all software is on site and in house, and all systems are installed, upgraded and maintained by a skilled tech team). I'm sure it would be a lovely little bonus for them to see JFX also be a "consumer" platform, and may even be a longer term strategy for them, but as we've seen with this mobile space stuff it's definitely not high on their list. Their strategy is hands-off and at best, "let the community do it".
I'm assuming this is the case because that's where Oracle's core business and heartland lies but that is speculation. It makes perfect sense that neither consumer grade distribution mechanisms nor smart device systems are any kind of priority to Oracle when you look at where/how Oracle operates. It also makes sense that they would need to ask the question "is mobile a commercial interest to anyone", which seems like such a ridiculous question to anyone in the consumer space (why not ask if windows needs to be supported?). Having this view about Oracle makes their decision to ignore these areas at least comprehensible (if no less frustrating) and I think then opens up the way for the community to decide how best to move forward on the consumer space.
For me it is a dilemma, I am still very much in love with the potential of JFX but I am also now accepting that Oracle isn't motivated to realise that potential in the consumer space (where I operate) any time soon. I can give up on it and start investing time and effort into the obvious alternative of HTML5 or I can make an effort to try and fix or work around some of the failings of JFX in the consumer space while at the same time pushing Oracle and JFX team to do the same. Tough call - there's an easy option there, but the harder one could have the better outcome.
Currently I'm still working on the harder option. I have created two linked OSS projects that are in very early phases: a Maven build plugin for JFX and a generic build library that the Maven tool uses (the intention that this could also be used in other build tools, such as Gradle, ANT, SBT):
The main one is a Maven Plugin that builds JavaFX distributables - it currently wraps the JFX tools to build native bundles and in the next few days I will be releasing a version that also produces JNLP files. My plan is to side step the JFX packaging tools in areas where the tools don't work well and create better more flexible tools as a result. I won't be able to fix the bugs around Applets and Webstart (that's in the JRE) but I may make them slightly easier to work with. It's the native installers where I hope to improve things the most (simplify the build process, include auto updating, etc) but there's a lot of work to be done to get there. It will all depend on how motivated I stay on it. If anyone from the community wants to get involved on this, even from the point of view of just testing (especially on non-Windows platforms), doco writing or general feedback as users then that will help with the motivation.
At the same time I would be willing to support anyone wanting to try and get JFX running on Android and perhaps one day iOS, and I would also be interested in making my above build tools support these platforms too. I think at this point in time we are waiting on the code to be fully open sourced before we can move forward too much on this. One area however that people could potentially start looking at is how to create a stripped down JRE for use on these smaller devices. Project Jigsaw was meant to help us out here, but this has been bumped from jre7 to jre8 and now again to jre9. The "embedded" java team have had to create the concept of "compact JRE profiles" to support their work. These are currently being targeted only for linux but the actual work could apply to any platform. See this conversation for more info: http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-November/004385.html
And finally, it seems that making a lot of noise is also still a way to get something happening in the JFX space (see this thread http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-October/004143.html). For general community members, foot stamping is currently our only way to get attention on the issues (voting in JIRA is currently worth very little). If this (or any issue) is one you are passionate about, making a lot of noise here on the forum, in the openjfx mailing list and by directly emailing the JFX leads (and getting others to do the same) is probably your best bet for getting it on the JFX team's radar. It's not a system I'm particularly fond of, but it's the one we have.
There's little doubt that the amount of attention and passion this thread on mobile has gotten has at least made the JFX/Oracle team take note. Richard commented that he had at least noted the ongoing discussions here (see the last comment in this http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-November/004293.html) and also made this very cryptic remark about Oracle's current stance on mobile:
Which is the latest and last we've heard on the topic. What this actually means is your guess as much as anyone's.
Ok if Oracle don't have plans to support Android, iOS and Windows 8, we have to wait until JavaFX is fully open sourced.
In the meantime we could discuss the main technical challenges to bring Java(FX) to Android, iOS and Windows 8:
1. Porting JavaFX glass/prims to iOS (OpenGL ES2), Android (???) and Windows 8 (DirectX???)
2. Bundle Java/OpenJDK within the app so that it's only one binary (static linking, no dynamic library loading!) (keywords: AOT (ahead of time compiler), Java-to-native-compiler, OpenJDK zero, shark, JNI, ...)
3. Shrinking JDK to a minimum (10MB instead of 140MB)
4. native look and feel (skin, css, ...) and native looking components (e.g. date chooser on iOS, lists, tab bar, navigation, ...)
5. access to native features (like Phonegap/Cordova do it) like camera capture, geolocation, music library access on tablets, ...)
We should now start find approaches for these five points...
Edited by: Tobi on 18.11.2012 01:21
I more or less agree with all of those points.
There was a JDK 7u6 JavaFX integration - Is jfxrt.jar supposed to be on the classpath? on these forums a while back that talked about some of the problems with deployment. The whole web start / applet setup is such a mess it's probably beyond salvaging IMO.
As a developer, my blatantly honest opinion of the software industry is that we've had a lot of companies jamming crappy platforms down our throats for the past decade and it's gotten much worse as mobile has made the web the only safe choice for businesses. There are tons of web based platforms to pick from, but they're all a variation of the same garbage.
JavaFX is the first platform I've seen in a long time that seems like it was built for developers. With JavaFX I can build a better application with less time and less money than I can with any of the web based platforms. And I like to think developers are still as important as they were 10-15 years ago.
The point I wanted to make about iOS is there are a lot of situations, especially for businesses building internal applications, where distribution through the AppStore is an absolute show stopper, no matter how much better the software could be.