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.