Archives for category: General

JavaFX 2.0 Beta is Available!

May 26, 11 //

Great news today, the public Beta for JavaFX 2.0 has been released! The beta includes a handful of samples, including Ensemble which is the sampler for JavaFX and will be beefed up over time to include tips and tricks and other such things. There is also javadoc (though, beware, there are still JavaFX Script examples. The docs for new code is better than old code). If you find bugs, submit them to the JavaFX JIRA bug tracker.

There is a lot of great stuff in this release, including binding, observable collections, sortable and filterable observable lists, many more UI controls, enhanced animation support including for game loops (AnimationTimer), properties (observable!), and more. There are a few things we’re still adding (including some important things!), but for the most part, the features are all there and functional, so go try them out! Please do file bugs, write blogs, and let us know what you think of the APIs. Things are definitely more verbose in Java than they were in JavaFX Script, though in large part this will be solved with lambda’s in Java 8.

Especially, if you have use cases that our APIs prohibit (as opposed to API we just need to add) please please please! file these in JIRA! The reason we’ve released the beta is to get exactly this kind of feedback. API is forever, so all the feedback you have on the API please file, and the sooner the better!

Ensemble

Swing Integration

September 24, 10 //

One of the questions asked in my JavaFX 2.0 blog post, and also at my second JavaFX 2.0 talk on Thursday at JavaOne was around Swing integration for JavaFX 2.0. I wanted to clarify what my current thinking is, and give you a chance to respond.

Edit: If you haven’t yet, please go read Amy’s heartfelt ramble on swing and javafx. She’s says better (and with more authority, having been a critical engineer on AWT, Swing, and JavaFX) than I did.

Over the past several years as I’ve gone on customer visits or to conferences such as Devoxx, I’ve heard repeatedly and clearly that people want to be able to use JavaFX in their existing swing applications. This is obviously important for anybody who has a big, existing swing application or is planning on building a new application in Java and has chosen swing.

In the JavaFX 1.x platform line, we’ve supported the ability to embed Swing components in JavaFX applications. This, however, is not generally that useful for people with existing Swing applications, but rather for people writing new JavaFX applications. This ability has been crucial if they wanted to have rich text or tables or combo boxes. Basically, it acted as a patch to allow JavaFX apps to be built if there weren’t equivalent JavaFX UI Controls yet built. But it wasn’t a bridge per se.

It also isn’t supported in the new Prism pipeline.

However going the other way and allowing JavaFX to be embedded in Swing should be quite feasible, even for the Prism pipeline. Which gets to another point — why having Java APIs for JavaFX was so important.

While on the train to the first Devoxx after JavaFX 1.0 was released, Jasper and I whacked together a quick proof-of-concept implementation of a Swing component that could host a JavaFX Scene. It was subsequently released by Josh Marinacci and some other implementation (I’m not sure if it was ultimately based on what Jasper and I did) was taken and released as part of JFXtras.

The problem with this has been that you cannot reliably modify the JavaFX scene from Java code. This is because the JavaFX Script compiler would produce “obfuscated” java code (this is actually a huge oversimplification and not quite technically accurate, but correct in the essentials). Instead of the mutator for the “x” property being setX, it was set$x. But of course what it was actually called and how it actually worked was subject to change from release to release so you couldn’t dependably talk from Java to JavaFX Script except through interfaces — it was all quite cumbersome.

So to enable developers to embed JavaFX inside Swing is a two part problem: how to do it at a graphics engine level, and provide clean Java APIs for working with JavaFX.

Now that we’ve announced the latter, we’re ready to start working on the former. There are, as you can imagine, a lot of details to sort through. For example, do we force 2D rendering when embedding in Swing? That would certainly be the easiest thing for us to do, but also the least glamourous since you wouldn’t get all that nifty hardware accelerated 3D stuff we’re talking about.

We may instead try to do something along the lines of what Java3D and JOGL did — essentially embed a heavyweight in the swing app. We’ll have to work through problems that may arise when Java2D is using DirectX and JavaFX is using DirectX. We’ll also have a whole pile of thread related issues to sort through.

Speaking of threads, one of the main design goals for JavaFX was to separate the UI thread from the rendering threads. This would allow us to take advantage of all those wonderful cores on machines these days for rendering without slowing down event response times etc. However, Swing was designed such that the UI thread *was* the rendering thread (another problem with immediate mode rendering APIs).

I guess I haven’t quite recovered from JavaOne yet. Rereading this blog post it rambles a bit. So I’d better just stop . In Summary, the current plan of record is to work towards allowing developers to put JavaFX content into Swing applications (WebView, Media, scenes, animations, etc), but perhaps not the other way around.

JavaFX 2.0

September 21, 10 //

Yesterday morning at JavaOne I gave a presentation called “JavaFX 2.0″ (which will be repeated Thursday afternoon, and again October 5th at the SVJUGFX). There were several announcements both in the talk and in Thomas Kurian’s JavaOne keynote last night as well.

Yesterday we announced the roadmap for JavaFX 2.0. If you haven’t read through it yet you should stop now and go over and read the roadmap. There are a fair number of features going into JavaFX 2.0 and we’ve identified which will be available for the early access (EA) build, the beta build, an the final general availability (GA) build. There are some really great things on there such as fully hardware accelerated graphics pipeline (Prism), High-def media, a TableView control, CSS animations and layout, and much more.

In general, JavaFX 2.0 is a continuation of JavaFX 1.0. There is, however, one big change and that is with the language. JavaFX Script won’t be updated by Oracle for JavaFX 2.0 to run on that platform. Some folks in the community have expressed interest in taking on this task themselves — and I wholeheartedly encourage this. The JavaFX Script compiler is already open source. We haven’t worked out the details but I would imagine we’d rather add community members as owners of the project than have it fork.

Up to this point the only language that could be used to build JavaFX applications was JavaFX Script. I always felt this was a needless restriction. In addition, I felt that it was actually a bad thing for JavaFX Script the language for a couple of reasons. First, since all our APIs were in JavaFX Script, it meant that JavaFX Script had to be changed to be a good language for writing APIs, whereas it was originally designed to be a good language for scripting UIs. Sometimes this created a design tension. The compiler guys very wisely kept the focus on scripting UIs instead of writing APIs (which is why JavaFX Script was productive to use for building UIs), however it made our job on the platform team more difficult.

In addition, since the entire platform was built on the language, they didn’t have the freedom to fix certain issues in the language (such as initialization, which admittedly was mostly a problem for folks building libraries). My feeling is that decoupling JavaFX from JavaFX Script frees the language so that it can continue to evolve. Most languages have years to mature before becoming stable. JavaFX Script had a few months. It is to the credit of the compiler team and Brian Goetz especially that it came out as well as it did in the end.

So even though Oracle itself isn’t going to be committing to updating and shipping JavaFX Script in the JavaFX 2.0 timeframe, I sincerely wish to see it continue to evolve and improve. The same Binding capabilities that JavaFX Script enjoyed will be exposed as a library in Java, so any updated JavaFX Script compiler will have the tools it needs to implement language binding. Also, we’re working on the initialization issue such that object literals will still be possible (we’re considering several forms of initialization including the builder pattern).

In addition, I’m very excited to see what other languages can do / will do. Charles Nutter tweeted “Perfect storm: Mirah plus JavaFX APIs.” (Sorry I’m not a very good twitter person, I’m not sure how to link to the tweet!). I couldn’t agree more, I’m very interested in what Mirah would look like for building UIs on JavaFX. Especially if a variant of it could support bind in the language (which would be incredible). Already JRuby and Groovy work quite well with our current Java-based APIs.

Of course in the world of soundbites, what we see is “JavaFX is dead” (which is obviously not the case if you have seen any of Thomas Kurian’s keynote from last night), and “JavaFX Script is dead” (which is also not the case — it is open source and many of the strongest proponents have been in the community).

JavaFX is core to the strategy for rich client application development at Oracle. Simply put, JavaFX is the evolution of the Java rich client designed to address the needs of today’s and tomorrow’s customers. This is all about making Java dominant on the client. Jasper will post some videos of actual live demos we ran on stage at JavaOne (I hope he gets it up on youtube so it will be viral. Apologies if we use a flash player… for now!).

We have a lot of work to do. I think there will be critics and doubters along the way — but that’s fine. I welcome that. Judge us by what we ship, not what we say. I think JavaFX 1.3.1 was a great release (all of the stuff Jasper is showing in his demo is achievable with the APIs in 1.3.1 + the media and prism implementations for JavaFX 2.0). I’m really looking forward to delivering the next version of JavaFX.

Finally, we’re hiring! I’m looking for people who are talented, passionate, and have a good attitude. We have put together a really great team with a great atmosphere and we’re committed to engineering the best platform. If you think you’d be interested, drop me a line. We have positions in UI Controls, text, graphics, media, deployment, management, and more. Just drop me a line at my oracle email address and I’ll forward your info along into the system.

Top 10 Changes in JavaFX 1.3

April 23, 10 //

A few weeks ago we started assembling our own Top 10 change list for JavaFX 1.3. Stephen posted an excellent list of his own. Here’s our take! Over the next several weeks we will be writing about each of these topics in greater detail and link them back to this page. So without futher ado…

10. Amble Font
We’ve added some standard fonts to JavaFX which are available to all devices: desktop, mobile and tv. What this means to you is a single consistent set of fonts which look consistent on all platforms. Happiness all around!

09. Multiline Text Input
Finally(!!), JavaFX 1.3 brings support for multiline text input to the venerable TextBox. TextBox already worked for single-line single-style text input, and in 1.3 we added the ability for the TextBox to also support multiple lines of text!

08. ChoiceBox
One of the most hotly asked for new Controls was a ComboBox. ChoiceBox is a close cousin (and in our experience is used more frequently). The ChoiceBox is essentially a non-editable ComboBox. You can put any kind of data item in the ChoiceBox and let the user choose an item.

07. Layout Enhancements
A lot of work went into enhancing and simplifying the layout system in JavaFX 1.3. The majority of porting issues you will face going from 1.2 to 1.3 will be in the area of layout. It is faster, simpler, and ready for business.

06. Preview Controls
In 1.3 we have added a number of preview controls. Please try them out! They absolutely will change when they become final controls (including moving from the com.javafx.preview package in which they live), but we wanted to get them out as soon as possible so you can have a play and provide input into their continued development. In 1.3 the main preview controls are Menus (MenuItem, PopupMenu, MenuBar, etc) and TreeView. Try them out!

05. Custom List Cells
In JavaFX 1.2 we released a very lightweight ListView Control. It barely made the 1.2 release at all. In 1.3 we’ve extended it to support completely customizable cells. One of my major regrets was that ListView is still single selection in 1.3 (bummer). That being said, the ListView’s cell virtualization absolutely rocks.

04. Lazy Scenegraph
We’ve made the scenegraph lazier! What this means for you is much better performance. “Bind storms” have been eliminated from all bounds related aspects of the scenegraph, so now we don’t compute bounds unless you ask for them. We’ve seen major improvements in applications which once were limited by such bind storms.

03. JavaFX Compiler Rewrite
The JavaFX Compiler team has done it again! The JavaFX Compiler has seen some major improvements in this release, both in the type of code being generated and how those changes effect applications. The semantics of “bind” have been better defined, and all binding is now “lazy” to help quell bind storms (lazy binding means that a value is not recomputed when its inputs have changed, only when it is asked for a new value). We sometimes refer to this as “compiled bind” because in previous releases bindings were essentially interpreted whereas in 1.3 the compiler generates more bytecode for each binding which gives hotspot more to work with and, critically, reduces the dynamic footprint of a Node by 6-10x!

02. CSS
The biggest feature for the JavaFX UI Controls team in the 1.3 release is without a doubt the CSS support that was reengineered from the ground up, extended, and improved. It is also now available on all three platforms — desktop, mobile, and tv. We’re really excited about this support as it gives developers and designers much more freedom in how to style controls and really makes some very common use cases much, much simpler.

01. TV
Finally, in JavaFX 1.3 we have added an emulator for TV which allows you to develop JavaFX applications for the TV or TV set top boxes. This is the FX Experience #1 top change for JavaFX 1.3 as it completes the promise of having a platform targeting all three screens (desktop, mobile, tv). The TV implementation is based on the new prism 3D accelerated pipeline. We’re very excited to see where this leads and to put more heat into this and our other platforms in future releases.

If you haven’t yet, download JavaFX 1.3!

Seeking: Awesome JavaFX developer to join our team

January 22, 10 //

So, my team at Sun has an opening for a guru in rich-text user interface controls. This is a big project and it’s getting a huge push. As detailed in the job spec:

This is a software staff engineering position requiring the ability to design, test, implement and maintain rich-text user interface controls. The person in this role is expected to identify areas for improvement and modification of Sun’s platform products and contribute to Sun’s overall product strategy. This person will work closely with others within the team and across teams to accomplish project objectives. May assume a leadership role in projects, including such activities as leading projects, participator in product planning and technology evaluation and related activities. May use technical leadership and influence to negotiate product design features or applications, both internally, and with open source groups as needed.

We really want to get this position filled now, so if you are keen, or know someone that is keen – apply! Working in the JavaFX team, and of course in particular the team I’m in, is a great deal of fun, and you get to work with people who really are smart and enthused about what they’re doing. You’ll learn a lot, and get to really sink your teeth into a growing technology and platform. Of course, the thrill of seeing your code used around the world is a pretty cool thing too.

So, if you have what we need, apply today, and I look forward to working with you!

Happy Holidays!

December 20, 09 //

Duke SnowGlobe

Encapsulation Idiom in JavaFX

December 16, 09 //

One of the gratifying things about being involved in building a new platform on top of a new language is discovering new language idioms. As an industry we’d managed to put together quite a long list of patterns and best practices for Java, but since JavaFX introduces some new concepts (such as object literal notation) and makes other things really easy to do (binding, closures) it creates an environment where we need to discover the best practices and patterns that make for effective programming in JavaFX.

One such idiom has to do with encapsulation. I was presented with the following problem in a recent email. The developer wanted to create a chunk of scenegraph which looked differently depending on some flag. There would be 10 such flags with 10 such chunks of scenegraph. (more…)

Vancouver Olympics Chooses JavaFX

December 11, 09 //

Some really great news I’ve had to keep under my hat for the past few months is that the Vancouver Olympics website has chosen JavaFX for a really cool visualization. It is an exceptionally well done application with stunning UI and does a terrific job showing off the potential of JavaFX in data visualization scenarios.

Vancouver Olympics JavaFX Application

Go and check out the application running live. It has data going back many years showing how many metals were won by different countries over time, which athletes won which metals, and so on. It is built and delivered on the publicly shipping release of JavaFX. Really exciting for JavaFX!

That Infernal Scenegraph Warning Message: Part Deux

December 7, 09 //

Stuart Marks has written up part II of the three-part series on the scenegraph warning message that you have seen in JavaFX1.2. I covered and linked to the first version previously. It really is a terrific read, and details some of the subtle semantics of bind. Stuart always does such an excellent job describing these subtle issues.

In my earlier post on this topic I hinted that we had found a resolution to the issue surrounding the warning message, I hinted further in some of my replies to comments, and I even left it as sort of a cliffhanger as to what the resolution was. So, here’s the resolution.

We’ve decided that when a node is added to a group, that node is automatically removed from the group that previously owned it, if any. (Let’s call this the “auto-remove” feature.) We’ve also decided to turn off the warning message by default, but to have it be enabled optionally, possibly via a system property, for debugging purposes. Finally, we’ve relaxed the enforcement of some scene graph invariants in cases where the group’s content sequence is bound.

…

During the development of our current release, we kept running into this issue. A couple of us wrote code that we thought was reasonable, yet it surprised us when the warning message came out! We had a few hallway conversations from time to time, but a clear-cut answer never emerged. Finally, we realized that we had to get the interested parties in a room and have a knock-down, drag-out meeting to resolve the issue. And so on October 7, 2009, Amy Fowler, Kevin Rushforth, Richard Bair, and I got into a conference room to decide the issue. Three hours later — with no breaks! — we had decided. Actually, it was a great meeting, without a lot of conflict. There were just a lot of issues to cover. Each of us came into the meeting with our initial opinions, but the issues were so close that I think each one of us switched sides at least once during the meeting.

Writing a Java-based Task

November 24, 09 //

In a post from earlier this year I explored the concept of background tasks in JavaFX. If you haven’t yet, you might want to review that article before reading on. For the impatient: JavaFX is currently a single threaded programming language. All code you write in JavaFX occurs on the same thread. Since you don’t want to write an unresponsive application, you need to write long-lived operations on a background thread. The Task API provides a single consistent abstraction which all background operations in JavaFX are based on. This means whether you are computing fibonacci sequences, breaking down protein chains, writing to a database or reading data from disk there is a single consistent programming model and API that your GUI communicates with. And we think this is a pretty good idea. (more…)