I’m going to do something today that I almost never do, and that is discuss briefly some of the bigger picture trends that I see widely in the industry, and discuss some of the things we’re doing but haven’t really talked a lot about yet.
At Sun, we would regularly talk about everything we were working on. Everything. Whether it was fully approved, funded, strategically relevant, or not. We’d just sort of throw it out there. Which was wonderful and liberating because we could just sort of say anything. And it was awful because nobody knew what they could trust. We’d announce something, work on it for a while, find out it didn’t really work out right, and then bail on it.
At Oracle, we don’t do that. We pretty much keep things quiet until we’ve lined up everybody — Management (which pays the bills), Product Management (which aligns the strategy), Engineering (who says what can or cannot be done technically or feasibly), Sustaining (who has to support whatever it is we do for the next 10 years or longer), SQE (who has to be able to test whatever it is we’re doing), and so forth. Once we’ve got each of those groups aligned with a strategy and roadmap that we are all confident we can execute on, and which we’re confident we can support for the foreseeable future, then we make an announcement. And of course we talk a lot with partners to find out what they think about the strategy and whether it makes sense to them. As often as not, we will make the announcement with some functioning code available that you can download and get started with.
You’ve seen this pattern for the last couple years in the Java and JavaFX groups after the Oracle acquisition. By the time we’ve made an announcement, we’re fully committed and usually we’ve got code to back it up. More often than not, we’ve got a Developer Preview or Early Access or Beta ready to go and we’ve actually been working on it for a while. This makes sense, because engineering can’t always ascertain feasibility without at least some kind of prototype. And we have now built up a track record of delivering either on time or ahead of time whatever it is that we commit to.
This has been a very conscious decision. Those from Sun, and those from Oracle, both knew that Oracle was going to have to prove itself as the steward of Java. We needed to execute continuously for several years to build trust with developers that when we say we’re going to do something, for goodness sake, we were going to do it.
And that is why we haven’t made any official announcement about Metro tablets or Android or iOS. And that is why I’m not going to make any official announcement in this blog post :-).
At various times people have written articles or blog posts or forum posts asking the question, what is JavaFX? Is it a competitor to Flash? (The answer would be No, though competing with Flex would be a Yes). Is it a competitor to Silverlight? (The answer would be Yes, for some use cases). Is it a replacement for Swing? (The answer would be an emphatic Yes).
I think at its heart, JavaFX is about application development. Good old fashioned native application development. The sorts of things you see in the iOS app store, or Android app stores, or that you install on your desktop. Think money management, banking, data visualization, entertainment, data entry, etc, etc. It isn’t competing with the web, unless you also think that native apps are competing with the web (in some sense, yes, but in a larger sense, no). The Web, to me, is two things. First, it is a medium for “browsing” or “surfing” data and information. And for that it is unparalleled. It works really, really well. Second, it is a distributed client/server architecture — REST. And that part of the web is used both by browser apps and by native apps. Pretty much every application worth anything these days has some web component, in that it is talking to the cloud using REST like principles and architecture for web services.
So for me, I don’t see any competition between “the web” or HTML and JavaFX. In fact, JavaFX ships with the WebView which allows you to integrate FX and Web content seamlessly. Users won’t even know which is which. You can manipulate the web page from Java or call Java routines from the web. Whether on desktop, embedded, or mobile that is very powerful. If you have some browser-like requirements in your application you can easily use them. Likewise, Java has networking libraries which allow you to use REST-style web services, either low level or with something like Jersey & JAXB. And of course any of these techniques can (and should!!) be used from JavaFX.
One thing I’d like to see more of in the future is streamlining the REST style web service usage from within JavaFX apps. We have some BSD use cases out there (the Henley Car Sales demo is one), but I suspect more could be done to make things work really, really well out of the box. Suppose we have Project Avatar on the server which handles REST requests in some standard fashion. We could then have really nice libraries in JavaFX for talking to those REST web services and consuming them. Of course if you want to do something custom, you can do that as well.
When we were designing the scene graph we really looked at different styles of application development. On the one hand you have standard techniques for building applications, that every native toolkit has offered for many, many years, such as layout managers and so forth. On the other hand you have the web, which because it was originally designed for text-based content grew into a completely different style of application development, as people attempted to use HTML for building larger applications. The CSS box-layout style is a royal pain to use (in my opinion!), but it also is really great in that it gives the CSS author a lot of control over what the final view will look like. Using things like “responsive design” principles you can automatically redesign the website for different screen resolutions (although in practice this appears to only work well for simple use cases — in reality you almost always need to customize the user experience for different form factors).
Bootstrap is a great example of being able to use CSS to create different UI, all from the same basic div structure.
Also, because HTML is all about flowing text, if your layout for your application is basically a flow layout, HTML is really a great choice. But if your layout for your application is about sliders and panes and tabs, then something more traditional is what you want. With JavaFX, we wanted to provide both approaches so you could choose which approach to use.
The best way right now to do that is to use a WebView when you want flowing-text intermingled with other elements. But it really isn’t matching my vision yet. One thing I had wished was that the FlowPane would just use the Box-model for flowing, and you could use full CSS layout techniques from CSS for manipulating it (with all the quirks that it comes with). The challenge here is that we didn’t want to reproduce the box-model in Java layout code. We’ve got the WebKit browser handy (with WebView), so I would much prefer that we could leverage WebView to do all the right stuff as far as layout is concerned. Maybe FlowPane could use a WebEngine in the implementation in some manner. I’m not sure exactly how this should be done, but it would be awesome if FlowPane (though for compatibility maybe we need a BoxPane instead that used the box model) could be adapted to do real HTML style layout. People could then take techniques and CSS that exist on the web and repurpose it easily for JavaFX.
It was very important to us that JavaFX 2.0 be evolutionary, and that it be something that people could easily adapt to when either coming from Swing / SWT / Silverlight / Flex, or when coming from HTML. CSS was a very strong part of the HTML success story, because for the first time it really empowered designers to get in there and have an impact on application design. It is no accident that web sites, generally, are some of the best (and worst, to be fair) looking apps around.
Of course iOS and Mac also have a strong legacy of good looking applications. But if you look at HTML and Cocoa, they’re not actually all that nice to really program in. I think the reason Cocoa-based apps tend to look good is that Apple apps are always so inspiring and so many designers use Macs that there is just a high bar there. We’ve all seen complete garbage in the iOS app store (in terms of visual appearance or usability of apps), but they tend not to do as well as the ones that were really well done.
JavaFX is a very capable platform for producing stunning applications. Jasper shows this again and again. One thing I’d like to see a lot more of, is professionally designed UI in JavaFX. I think the fact that we have CSS is an advantage, because if you hire a professional UI designer, they should be able to get in there and make an impact rather quickly. But what we still need to do is to add layout from CSS, so that a designer can also impact all the layout constraints that are involved in a particular layout pane. We do allow you to customize padding and such, which is a good start, but we really need to take it the next step and let you also perform layout (and animation!) from CSS.
Now, I started off by answering the question, “What is JavaFX? What does it compete with?”. I answered that by saying that JavaFX is, fundamentally, an application development platform. Yet how does one actually go about deploying JavaFX applications? Obviously, on iOS or Android or Metro, the answer would be that you have to create a native app bundle and submit it through an app store. But why stop there? Both Apple and Microsoft are also introducing (or have introduced) app stores for their desktop operating systems as well. Linux has several application packaging and deployment mechanisms. On Apple you could have either an .app or a .dmg for distributing your application.
Lets talk about Mac for a moment. Apple is pushing hard for folks to use their Mac App Store. Obviously it is good business for Apple. If everybody used only the Mac App Store, then Apple would get some chunk of revenue from every application running on the Mac, they’d get information on who each of their developers are, they’d know how many times each app was downloaded, how popular any given app was. That’s pretty valuable business data (and revenue)! In addition, they could control security better, ensure a consistent update experience, improve application discoverability, and provide a better user experience.
Historically a different approach on Mac had been taken, where each application was distributed from their own website (and every developer handled purchases, etc). Then each app would handle its own “auto-update” procedure, though most everybody seems to use a library called Sparkle. Basically it handles the auto-update headaches and is really easy to integrate into your app.
So today you basically have two models for application deployment on the Mac — the Mac App Store, and direct distribution + auto-update.
Windows is trying to also get into the app store business (remember all those good business reasons I mentioned above? They apply to Microsoft just as equally). And on Windows of course you can also download and install software manually, and each app has to handle its own auto-update functionality. Chrome for example does this, along with other software from Google. On Windows you also have IT department sanctioned and pushed software, which typically is all MSI based. In a way, it is like an enterprise app store, except that the IT department can push software updates to clients instead of waiting for clients to update on their own.
Ideally, JavaFX would be dead simple to deploy using any of these above techniques. It should be easy to produce native application bundles (exe, msi, app, dmg, rpm, deb, etc), and it should be easy to send these to a Mac app store, Windows app store, or some linux distribution mechanism (sorry, I haven’t used it for years so I’m not fully up to date on the whole app distribution model on linux :-)). You can use the MSI approach and give it to a corporate IT department to push. Or you can deliver standalone application bundles with a built-in auto-update mechanism.
These application packages should be co-bundled with the JRE and with JavaFX and any other library you require. They shouldn’t require that Java be pre-installed. Now, some folks have already complained about that, and for those folks I’m also willing to say you can omit Java/JavaFX from the bundle and rely on a preinstalled version of Java/JavaFX, but you then will have no control over what version of Java/JavaFX is installed. Its up to you to make sure your customers have the right version installed and that your app works with newer versions of Java/JavaFX.
The fundamental problem here is that there is a tension between security and stability. When you write an application, you want to be able to know that “in the wild” it runs against a very specific version of Java — the version you developed against. You can enforce this by co-bundling, or you can “soft” enforce this by having your users upgrade (or downgrade!) to a specific version. Or you can just not worry about it and hope that future versions of Java are “compatible enough” that things just tend to keep working. The problem with multiple installed versions of Java is that Java, like any piece of software (including browsers, as we are all-too-often reminded) have security bugs, and as those bugs are fixed, users must upgrade. And on every upgrade, there is a non-zero chance that your app will break.
By co-bundling, you avoid this. Since only your app can execute the co-bundled version of Java (since it is not installed in a shared location or used by web start or applets), and since your app has full permissions anyway, there is no security issue. Which means there is also no stability issue since you can then know exactly what version of Java your users are using.
Besides, this is the only way it will work with the iOS, Metro, Mac, and Windows app stores. And as has been discussed, Apple and Microsoft have business reasons to make sure the app model becomes the dominant model. So if we’re going to plan here for the future, the obvious answer is to co-bundle and create native apps.
I think it also makes for a much better user experience and fits much better into native tools and workflows, like the IT department usage of MSI mentioned above. It is more work for the developer to produce all these bundles, but some of the best software out there was doing that anyway. I think we need to move forward aggressively on the app bundle + auto-update approach, much as Jasper has with FX Experience Tools project. I can be confident that my app is going to work almost everywhere without any hassles. I like that.
Of course, we want to leverage Java 8 modularity for creating a subset of the JRE and JavaFX, so that the download size is as small as possible. We’re not there yet. Some support for creating native app bundles is in the JavaFX 2.2 builds using javafx-packager (and associated ant task). There will be a lot more work coming in this area.
In other words, although we have no announcements or any roadmap for Metro, it seems a worthy area of investigation and fits in well with the broader picture of where JavaFX really can excel — at application development.
Since JavaOne last year we’ve been showing off demos of JavaFX running on iOS. Most people are very excited about the prospect, some reacted with doom and gloom that Apple would never let Java on there. In the meantime, Adobe (using AOT compilation), Unity, and others have succeeded in doing basically what we have been investigating. That is, Apple relaxed their restrictions to allowing third party frameworks be used in the development of iOS applications. There are still caveats and challenges — like the lack of JIT (no dynamically populated executable memory segments) — but these are challenges that others have already met (by using AOT compilation).
Another huge and growing segment of the market is around embedded — UI for cars, printers, industrial systems, etc. If there is one thing that the iPhone has done is raise the expectation for what good UI is on small form factors. And if there is one thing the Raspberry PI is doing, is showing to the world that the ability to produce such UI cheaply is quickly becoming a possibility. The opportunity for a cross-device application platform in Java is, I think, compelling.
From the 10,000 foot view, I see JavaFX as a cross OS / device application development platform. It has been only 8 months or so since we launched JavaFX 2.0 and the response (on this blog and elsewhere) has been huge. I believe that by focusing JavaFX on application development and improving the native application deployment problem JavaFX usage will increase dramatically. In that time we’ve added Mac as an official platform and Linux is in developer preview (quickly approaching GA). We’ve open sourced our UI controls with more to come. On the JavaFX team we’re going crazy with all the work that needs to be done (largely porting to all sorts of new devices and platforms, and performance work and new features and all the rest). I think the nature of JavaFX — a cross platform / cross device solution in Java with great web integration and graphics — really opens up a lot of opportunities for application developers when designing solutions and lowering the cost of application development. It isn’t the best choice for solving every problem (for example, HTML 5 seems to be really doing great for traditional web sites and web apps), but I feel it uniquely and powerfully addresses a huge (and rising) set of use cases around desktop apps and embedded apps.