What is Java's answer to WPF? [closed]

I'm mostly a .Net person at the moment, but I've been playing with Java some lately-- exploring what's out there.

Now I'm looking for the Java equivalent for WPF. I know I could find an OpenGL library or two out there, but that's not really as rich or simple as the WPF system.

Solution 1:

I think a combination of JavaFX, Swing, Java2D, and Java's browser-based JRE comprise the solutions that WPF provides:

• JavaFX applications (actually, any Java app) can run in the browser or on a desktop
• JavaFX provides high-end video support
• JavaFX provides for scripted animations and visual special effects
• Swing provides UI capabilities, and can be used in both Java and JavaFX
• Java2D, which provides the underpinnings for all drawing tasks (including Swing), takes advantage of hardware acceleration and DirectX support
• The JRE on the desktop or the browser enable Java applications to be deployed to multiple environments (including other screens, like set-top boxes or phones)

Solution 2:

I've programmed Aqua, Macintosh Quick Draw, Windows GDI and GDI+, Qt, and .NET Winforms and WPF is by far the most sophisticated API I've used. Although it has a pretty capable feature set that's better than preceding technologies such as swing, it's no match for WPF. It solves some major problems that have plagued graphics programming. If you're coming from the HTML/JS world, it is easy to learn, but if you're coming from the traditional graphics programming world, it's a major paradigm shift. Regardless, it's much easier to learn than CSS/HTML/JS. It's a clean break from the legacy concepts which plague other graphics programming environments.

The biggest strength of WPF is that it's resolution independent. It can scale across devices with little to no modifications. It requires little work to take a screen version of a drawing and output it to a high resolution printer without resolution loss.

It also supports event triggering. UI elements can respond to events of other UI elements or to your applications code, making dynamic interfaces possible. It makes it easy to separate your code from the UI in a way that even HTML/JS can't achieve. Elements can broadcast and listen to events and respond accordingly.

Another strength is its highly object-oriented and declarative capable API. Using XAML, you can easily construct a working interface quickly and efficiently with a few lines. Unlike HTML/JS, it is easier to learn and its output is far more predictable and efficient. You can even program WPF completely in code, but it's generally not worth the minor performance gain. A better method is to compile your Xaml into .NET code.

In addition, the tooling available for WPF is very extensive compared to JavaFX. There are tons of tools including Expression Blend available. There are also numerous tools for taking vector graphics formats such as SVG and Adobe Illustrator and converting them into XAML. Now, designers and programmers can collaborate on desktop publishing in a way that was very difficult to do before.

In summary, WPF is so comprehensive that the Mono team opted not to port it to the Mono code base. They claimed it would take many man years to fully implement a reasonable feature set. If a Mono compatible version of WPF existed, it would make .NET the de facto cross-platform application framework. In fact, it may even supersede HTML/CSS, since it is far more powerful and easier to get your head around. Unfortunately, Microsoft didn't see a business case for a cross-platform enabled WPF. It's why SilverLight/WPF lost to HTML5/JS. Thanks to this mistake, they are now forced to hand over not only the web but part of their desktop to HTML 5/JS.

Solution 3:

Feature-wise WPF is more comprehensive than any of the JavaFX, Swing, AWT or Java2D. That was the design goal after all, to bring everything related to the presentation in a single library. Performance-wise they are about the same with the exception of the memory usage where Java is a hungry hog