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.
Folks have been asking us about Windows Metro, and how we’re going to handle that. We don’t have any plan whereby Applets will work in “metro mode”, since Microsoft is basically disallowing all plugins (except for a few sites which use Flash where they have whitelisted them and will allow them to work in Metro). Instead, I am interested in whether we can have a version of JavaFX which would use Metro-only APIs for graphics and such. Initially it sounded like Metro graphics was all JavaScript + HTML, but that of course isn’t the case. You can use C++ and DirectX, which means we should be able to run on there quite well. There is a question about JIT, which we are investigating, although a little AOT + application bundles would solve that quite nicely.
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.
co-bundling: thank you! Finally, the Java guys get it! Most people call this an embeddable JRE. This is critical for native development on Win/Mac/Android/iOS.
Two big points you don’t seem to get:
JavaFX is not a fit for creating games. Game developers want their programming tools to give them access to OpenGL and get out of the way. They want to build & use game engines like OGRE and Unreal. They do not want the JavaFX scene graph or a special Java game engine. Game developers would love a JVM cross platform alternative to C/C++, which projects like lwjgl and jogl do, but that tool stack is very weakly supported. Java also hasn’t provided an easy way to embed/hide the JRE (which this post suggests is coming as “co-bundling”).
HTML/JS web apps absolutely compete with native apps, whether they are Flex/Swing/iOS/Android/JavaFX/Silverlight. Don’t you see how HTML/JS applications like Google Docs and Zoho Docs have replaced native applications like Microsoft Office or Libre Office for many users? With emerging technologies like WebGL, HTML/JS is dramatically growing what it can be used for.
@Clay
I said entertainment, but by that I didn’t actually mean games, I was thinking more along the lines of a media browser (think: Netflix on Apple TV). Casual games I think, no problem you should be able to do that with FX, but definitely for FPS or other more involved games folks will want a surface to run their highly optimized C code against. They would probably be interested in something like FX for handling menus, popovers, or such things that are more 2D GUI stuff vs. the 3D gaming.
As for HTML, I don’t buy the argument. I meet with people *all the time* who complain about the horrific experience of building what should be a traditional native application in the web with HTML. HTML does what it does well, and it does what a desktop app does very poorly. Can you use HTML in some task for which it is not well suited? Sure, but that doesn’t mean you should.
If you were to draw a Venn Diagram of where different technologies have their design center, you’d find that something like JavaFX (or .NET or Cocoa or WinRT or …) doesn’t have the same design center as HTML. Of course there is overlap, so you could claim that any two technologies compete because for some use cases developers are going to have to choose between the two.
Both JavaFX and HTML are cross platform, but JavaFX is better designed for application development and HTML is better designed for browsing / document layout. People have done amazing (and unnatural!) things to HTML in order to try to grow it out so that there is more overlap between native application technologies and HTML. But fundamentally HTML just isn’t as good for this stuff.
Of course I see and understand that there are people who want HTML to rule everything. They want it for every UI they ever have to build from now into forever. And they want it for idealogical reasons, I expect. And although Java is GPL and open source and all that goodness and developed by a standards committee, for some people the WhatWG or other working group is more open or whatever. Anyway, I digress. Sure of course there is a current right now that says that HTML is the one true way and everything else should get out of the way. Yes, if you push and prod and poke and squint your eyes you can sort of see how that strategy would work. But frankly, I’m not a fan. As an application developer myself, I’d rather not have to use HTML and JavaScript for writing all my UIs.
So for me, I don’t see it as competition. I think you can use HTML for exactly what it is good at, and use JavaFX (or other native application frameworks) for exactly what they are good at, without having to go all one way or all the other. I think it will more likely be a balancing act.
HTML isn’t going away any time soon, and neither is Java. They both have way too much momentum and commitment behind them. JavaFX takes the position that both can work together to create a better solution than either separately.
C is absolutely dominant for 3D games, but that doesn’t need to be. All game developers know that the C language and C programming tools are way behind, but there isn’t a better alternative. There’s a huge opportunity for the JVM: the major show stoppers are the inability to make native looking apps on Win/Mac/Linux and the inability to target iOS — both of which you suggest are about to be fixed. JVM has too much going for it: cross platform, near C runtime performance, the best ecosystem of build tools, profiling tools, and IDEs, and far more elegant languages — Java alone is far better than C, but many prefer Scala or other JVM-centric choices.
I fully understand your points regarding some limited overlap between HTML and native apps, but different design centers. Having written some JavaFX apps, it’s a better and more elegant toolkit than Swing or Silverlight’s XAML stuff for that style of component GUI framework.
HTML/JS is clearly a poor fit for full client application development. No one uses it because it’s elegant to develop with, people use it because it offers adavantages from the user’s perspective in terms of simplicity, accessibility, and a completely universal runtime. I don’t think Google Docs would have achieved a fraction of its current success if it required Flash or Java or a native client to run, even though those toolsets would be more elegant to program with.
I don’t see client Java or JavaFX working together with HTML/JS as much as they are overlapping toolkits with different strengths that are racing to improve and grow their Venn diagram circles of applicability. The HTML/JS platform is growing its capabilities with technologies like WebGL while the Java platform fixes the runtime support issues and lets developers build native looking apps for all the major workstation and consumer platforms Win/Mac/Linux/iOS/Android.
Great points Clay, thanks for the comments!
I agree, co-bundling – about time.
As for game programming I don’t agree. Most people want a library on top of OpenGL to do game programming, also 2d game programming might be good with javafx.
Of course there is JMonkeyEngine for 3d programming in java as well.
On another note oracle should add joystick support to Java/JavaFX. I know this can be done with JInput etc, but it should be part of java. I really don’t understand why this hasn’t been done in the past.
“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”
Yep. This is much more than a “nice to have” feature, at least for me. I’d vote for making it super easy to create really nice native application bundles should as a high-priority feature. Can’t come soon enough! There’s no reason for a typical end-user to see any difference between a native app, and a Java/JavaFX.
Not sure about Cocoa being not that nice to program in. I think that used to be true. However, since Xcode 4 introduced Storyboards to integrate making trivial parts of UIs with coding; and iOS5 introduced automatic reference counting to stop half your code (and more than half your time) being about memory management, it’s actually pretty nice and pretty productive. Certainly a long way from being horrible.
Hi Simon — I agree they’ve come a long way, but I still haven’t crossed the learning curve of using their documentation! I even find MSDN to be easier to navigate, and that’s saying’ something 🙂
Hi. You are doing great work. It’s a hell of a scene graph. Now, in NetBeans, if we can just choose File…Tools…Build Native App Bundle For Any Platform On Earth… Thank you.
Ha! Also have such a plugin for Hudson so your continuous integration server can pump those apps out, that would rock.
This would cause a huge boost for JavaFX, i think.
A real today´s “write once, run everywhere” for traditional Windows, Linux, Mac and Android, iOS and Metro…that would be absolutely stunning!
Please do it Oracle! 🙂
And where do you put text editor (an application editing flowing-text) between JavaFX and HTML?
Thanks,
I put a text editor squarely in the “crap this is complicated” category :-). No honestly, it is a really good question, and I’m not completely settled on it. There are a number of use cases there, such as normal rich text, customized text editing (think MathLab or something), editing text boxes that are laid out along a path (think PhotoShop or Illustrator like software), etc. In general for basic rich text I favor an HTMLEditor like approach, because I think for most cases HTML has proven itself to be the standard rich text format. I need to think about this question more.
Given most data editing is happy with a scenegraph (data model), and most (mixed) content editing is simpler with a streaming model (like StAX [1]), isn’t it possible to build a styled paragraph node upon Canvas streaming API and not upon current Text nodes model and layout.
Adding a single character to the paragraph can change all positions of text nodes and need a full reflow: like canvas cleaning and redraw. You will have one node (wrapping one canvas) per paragraph, then reflow will be short (for usual authors, writing paragraphs with some lines).
[1]: cf. by example EXI encoding of XML:
http://www.w3.org/TR/2009/WD-exi-primer-20091208/#exiBody
Look here (http://tomsondev.bestsolution.at/2012/06/03/about-mixing-and-matching-jdt-and-javafx/) for a Rich-Source-Editor embedded into JavaFX
In order to create novel applications involving text, two things are needed. One is the ability to render text efficiently. About that efficiency, some thoughts come to mind. If every word or letter is a node is a scenegraph, we’re doomed for to me obvious reasons. Sure, text can be rendered in a node, but if every time the style or layout changes , we’re re-rendering the scene graph it’s hard to see that this won’t be where all the processing power goes, leaving nothing left over for document analysis etc. Making every potentially sub-word stylistic change in a lengthy document carry the full weight of the scene graph node hierarchy is putting the limits of today’s computers to the test in terms of memory and processing power.
CSS itself is really a set of programming instructions to be carried out against a document and while it’s great for designers – they change a few things in the CSS stylesheet and everything in the document changes, there are potential specification requests in the CSS style sheets which will result in processing chains which are horrible in terms of memory demands and CPU cycles .
So the concern I have is that text rendering of documents is being chained to two technologies which is memory and computing power were infinite would be fantastic but are so heavy weight that the real result will be too slow and bloated .
And it’s not like things are going to get better. The trend is clearly towards larger documents and more numerous documents (big data) being linked together to form a kind of super document, with everything being edited and resident in memory. Even if Moore’s “Law” continues to hold, the demand for processing larger and larger ‘documents” will always grow far faster.
Sure you can argue that the whole document isn’t going to be rendered at once- screen size is limited even if the document size is huge- but the rendering at any given portion, especially using CSS, is or can be dependent on everything that has been (theoretically) rendered prior to that point in a document.
So you end up applying the rendering chain to the entire document , or at least to the part of the document up to the part you want to display, just to know where and how to render the part that IS actually shown on the screen.
Add to that arbitrary CSS transformations that actually do require analysis of the entire document and you have – I fear- quite a mess of memory and CPU utilization just to get words on a screen, never mind DO anything with the document based on the semantics of those words.
The object model of any styled text editor comes to look superficially similar to a scene graph. There are nodes whose boundaries are / can be defined by styles applied to those nodes. There new nodes coming and going as content and styles change. The nodes have positions in Cartesian space
But that shouldn’t lead anyone to believe that the nodes of a scene graph – or the scene graph in FX can be used for the nodes of a styled text component and still have everything scale. I fear it won’t scale, in spectacular fashion.
It’s the whole point of creating object models specific to a domain- they’re efficient because they’re specialized and not dragging around huge hierarchies in memory or invoking processing nighmares for scenarios which aren’t pathological .
If you open Word or whatever generate a 10 million word document without paragraphs then go the very beginning of the document and insert a single letter, you can basically watch the rendering happening in real time as Word goes through and is forced to recalculate the position of every single letter in the document whose position just got effected by that insertion. There are no paragraph breaks , so there’s no point at which Word can say – and from this point forward, nothing can be effected. It’s a pathological case.
But this is what I am afraid will become the normative case using a scene graph and CSS and the object models for styled text.. Both these technologies have to process everything in even common, thinkable cases. It’s a very very heavy weight way of doing things implemented by a very very heavyweight object model.
thoughts?
An AOT compiler (especially for iOS) sure would be a huge thing. We [1] are currently going through a lot of pain to port our FOSS Java game development framework to iOS through MonoTouch and IKVM. Needless to say that the development cycle is far from being ideal. None of the tools available on the JVM can be used, and having to use a competing, commercial platform (Mono/.NET) to make JVM apps work on iOS is making me feel dirty inside.
According to stats gathered by AppBrain (grain of salt), our offering is currently the #1 game development framework on Android, with 1.24% of all apps being build on top of it [2]. We are actually highly competitive with Adobe Air and leave any other offering far behind [3]. We even have games on Steam that are build on top of our technology. We even expanding into the web space via GWT and already have a few people pushing pure Javascript/GWT games to Facebook or Google Chrome store.
This goes to show that Java as a gaming platform is not to be underestimated. I think Oracle is missing out on an oportunity here. A simple to bundle, AOT compiling JVM would mean an entirely new segment of developers would consider the JVM as their #1 goto place.
We’d highly appreciate efforts to expand the JVM environment to new platforms like iOS or even consoles.
[1] http://libgdx.badlogicgames.com
[2] http://www.appbrain.com/stats/libraries/details/libgdx/libgdx
[3] http://www.appbrain.com/stats/libraries/dev
Great news!!! Deployment always have been a pain in Java. But what about the decompilation problems? Any news about this? Now that our apps will be more accesible it’ll be a good idea to protect them, not in the way of code obfuscation, but with flow obfuscation or another technique.
And what about Java Web Start? Any future support with these new deployment potions?
Great work!!!
It would be really nice to have deployment support for Win/Mac/Linux, for the Mac store and Metro because it takes a considerable amount of time to sell and manage app subscriptions. Also iOS and Android support would be great too.
Is there any demo creating an own JRE with JDK8 jigsaw?
You could start with the JDK base image + jmod packages from http://jdk8.java.net/jigsaw/ and then add in additional modules you want by following the quickstart: http://openjdk.java.net/projects/jigsaw/doc/quickstart.html
” But if you look at HTML and Cocoa, they’re not actually all that nice to really program in.” That was being very kind to both.
I was really waiting for an article like this.
But I have two questions:
1) I have a lot of AWT legacy code still running (well) on my customers and I am really worried. I saw some classes for AWT/Swing integration with JavaFX and viceversa. Still have I a chance to avoid full app rewrite?
2) I like the mention about iOS, Android or Metro. Customers are askings for apps for iOS and will be for the other platforms. When will I be able to see my Java app running on an iPad? Thats an apparently simple question I think I share with many Java developers.
I think your chances of avoiding a full rewrite of your legacy app are good as long as you don’t expect to deploy your legacy AWT based java applet to an iPad.
I agree about co-bundling & AOT for client side java. One of the weak points of java for client side currently is that the JRE is huge and startup time of an app is horrible. A modular JRE + natively ahead of time compiled code should drastically improve this. Only then will client side java become attractive. Otherwise Java (like it’s now mostly) will be mostly confined to server side (and it’s loosing share there also to other languages).
I never understood why SUN kept for so long preaching JIT (and you even can’t reuse already jitted code if you restart an app!) for java everywhere. That’s ok for server side (well not really but everybody seems to just live with it since the JVM dominates cross-platform server side dev) if you can wait several minutes for a server to startup but is a no no for client side. I remember doing an embedded java project (digital TV) around 2000 with a AOT compiling JRE/JVM called TaoVM. So if it was possible 10 years ago it should certainly be possible now.
I do not agree 100% on your view of co-bundling. Having to ship/download/install each time the whole java platform is just silly. Especially on mobile devices with limited bandwith and “disk” space. I mean: you don’t reinstall the whole C/C+++/.NET every time on Windows/Linux/Mac also everytime you want to install a (small) app, do you?
I think a future solution should do the following:
The app developer co-bundles all the JRE (jigsaw) modules/JVM and specifies the depencies of the app on these modules in some manifest (part of jigsaw). There should be some library included with java/javaFX that’s part of the installer/auto-updater that checks before downloading the java platform is there is already a compatibel java runtime installed on the client and if so it only downloads the application code not the java platform and runs the app on the shared JRE. If there is a compatible JVM but some needed modules are missing then these should be downloaded together with the application code and the app is run on the shared JRE again. If there isn’t a compatibel JVM/JRE then the whole bundle is downloaded and the app runs on this JRE. I think this crucial and should be part of standard java (part of jigsaw).
Terrific high-level overview Richard.
The future is clearly native app bundles of some flavour and in this regard a cross-platform auto-update mechanism would be huge for us. We’re presently deploying as browser-hosted applets and updating by replacing jars and tweaking jnlps on our web server. We see value in unshackling ourselves from browsers but would rather have your talented crew deliver an auto-updater.
Great write-up we definitely need more of these to spread more awareness about JavaFX!
I think with so much work going into this, one thing stands out always as a sore point is that how challenging it is to make your apps deploy seamlessly in all environments. This really should be number one priority, especially when lines get blurred comparing it with the richness offered by HTML5.
I do not like the idea of being locked into a third party browser where my mission critical app is at the mercy of the browser crashing just because some other poorly written app, running in another tab caused a irrecoverable failure.
Great response Ashish. And its been an argument I’ve used against browser apps for years.
However, most enterprises already depend on browsers for many (certainly not all) mission-critical applications. And browsers are improving dramatically every day in functionality, speed and security. Probably the only thing holding back full-bore adoption of web apps over native is the loathing that most enterprises have for JavaScript (an observation I’ve had over the past 10 years in the NY metro area).
And I would propose that “mission-critical apps” means something different these days than 10-15-20 years ago. With mobile and cloud infrastructures, its no longer a monolithic UI ‘mission-critical’ app on a desktop.
Helpful summary. This might just be one Oracle project/product that doesn’t make me want to vomit.
Also, you say: “JavaFX is a very capable platform for producing stunning applications. Jasper shows this again and again.”
Where? All I’ve ever seen are endless demos of pie charts and bar graphs, and equally snoozeworthy stuff. By comparison there are stunning examples of HTML5 all over the web.
I don’t disbelieve you, but some real, live, running examples of these stunning JavaFX user interfaces would be great.
We are excited to be creating a P2P Social Media Client purely in Javafx.
+1 to Dave.
When i first heard about JavaFX, it was announced as the killer tool for making RIAs, that will kill Flash, Flex, Silverlight. This was five years ago, and nothing happened besides a dozen of similar announcements with updated wording (now less about beating Flex, more about getting it run on iOS).
Your goals and ideas sound really good, but people believe you less and less if you just make empty promises. Just look at your examples: If Adobe released a fully working AOT compiler 1,5 years ago, where is yours?
Your comments about people complaining about using HTML/JS to write applications is a bit out of date.
HTML5 is a *programmatic* foundation; it is different than just HTML4+1. There are APIs for doing all sorts of application-centric functions. It is a loose term and encompasses not just markup but APIs from drawing primitives to device APIs (cameras, accelerometers, microphones, etc). It is an inflection point in the web.
Fire up Chrome and visit ChromeExperiments.com and see if JavaFX can compare graphically. And most of these demos are just apps built with JS and HTML5 Canvas.
Every single browser manufacturer (including WebKit which is bundled with JavaFX) supports HTML5 features (visit caniuse.com to see which features).
I appreciate the effort put into JavaFX up until this point, but JavaFX’s positioning needs to be readjusted imho. There needs to be a short-term strategy (eg, JavaFX to JS/HTML5 converter a la GWT) and a long-term strategy (eg, hybrid API for mobile, deeper cloud integration, et al).
Btw, I run the NYJavaSIG (17+ yrs), a very strong Java proponent (and used to teach Swing some years back… so I’m not anti-Java.
I would argue that HTML has become more about information structure rather than flowing text. Done properly, CSS determines the layout and flow. HTML is just a set of information and dividers with no formatting at all.
Also, when first I saw the stylesheet model, I was “huh?”, but I get it now and think that this will be a good decision. Separation of concerns where the developer develops and someone else makes it pretty. Seldom do you find both skills in the same individual.
As for JavaFX embracing HTML5. I’d like to see this taken a step further and embrace WebGL as well. There are many gaps in the JavaFX offering. You mention one, the text editor. Often we have to reach out to the web engine to fill these gaps. I assure you that there are many more and it’s amazing to have a promiscuous technology capable of embracing and extending components written in other languages and other frameworks in a seamless manner. Without WebGL I am finding that there are still some barriers. I’d love to integrate Processing.js and three.js work into my own. There are amazing capabilities there that the JavaFX community has yet to match.
Furthermore, I like having options. The option to leverage a web component or write it within Java/Scala or Groovy as the need dictates.
All of this I am doing (minus WebGL :-)) in my JavaFX app called Dex. http://dexvis.com/ In this application there is some interesting intermingling of languages. My application is java/javafx. It might call to a groovy component which reads a template file, feeding it parameters and data to create a HTML page on the fly which is then fed to the WebEngine. All in a seamless manner in which you never realize that you have left JavaSpace a few times.
Anyway, thanks for the insightful post Richard, especially concerning the cultural differences between Sun-Java and Oracle-Java.
– Pat