Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2574 posts at DZone. You can read more from them at their website. View Full User Profile

Pivot a Top Project: Ready to Challenge Flex, Silverlight, and JavaFX

01.19.2010
| 14285 views |
  • submit to reddit

Nearly a year after entering the Apache Incubator, the Pivot project officially graduated to a top-level Apache project.  The ASF board passed the resolution for graduation in December and their announcement today makes it official.  Pivot is a Java-based RIA toolkit for writing applications using a combination of Java and XML.  A Pivot application can run as an applet or a standalone.  Earlier this month, the project released Pivot 1.4.

People that have been around the web for awhile remember when Java applets were just toys.  The arrival of Java-based RIA tools, like Apache Pivot, produced more sophisticated environments for developing advanced applications.  Pivot came about because Greg Brown and Todd Volkert, two founders of the project, were frustrated with the lack of good Java tooling for client-side applications.  Many Java developers had similar gripes, which lead to the creation of tools like JavaFX and Swing, but Greg Brown had issues with these tools as well. 

Swing has been around for awhile, Brown said, but it hasn't really been able to keep up with heavy-hitters like Flex and Silverlight.  JavaFX on the other hand is not a tool for Java developers, Brown said, because you have to learn a new JavaFX scripting language and new APIs.  The Pivot FAQ says that JavaFX and Pivot appear to be serving two slightly different use cases: "Pivot is designed primarily to address the 'Application' in RIA, whereas JavaFX appears to be geared more towards the 'Rich' part of the acronym."  The FAQ states: "In a sense, Pivot represents what we think Sun should have done instead of JavaFX."  

Pivot offers a comprehensive set of standard UI elements and several features that simplify the development of modern GUI applications.  These include data binding, animated effects and transitions, web services integration, and an XML markup language called WTKX for declaring the structure of a UI.  The most recent version of Pivot is more polished and adds a few more features.

WTKX Source Code:

<Border styles="{color:10, padding:0}"
xmlns:wtkx="http://incubator.apache.org/pivot/wtkx/1.1"
xmlns:content="pivot.wtk.content"
xmlns="pivot.wtk">
<content>
<ScrollPane preferredWidth="240" horizontalScrollBarPolicy="fillToCapacity">
<view>
<TreeView wtkx:id="folderTreeView">
<nodeRenderer>
<content:TreeViewFileRenderer useNativeIcons="false"/>
</nodeRenderer>
</TreeView>
</view>
</ScrollPane>
</content>
</Border>


Pivot 1.4 is mainly a documentation and bug fix release, but there are a handful of new features.  They've added missing resources in generated .jar files for compatibility with the Maven repository.  Pivot now supports native XML and has XPath support to the XMLSerializer.  A number of usability improvements were also added.

Here are some of the positive user comments that Apache included in their press release:

"I've tried the demos and I was stunned," said Pivot user Trelieux Einagen. "The framework uses easy to understand markup for the applet front end while at the same time taking advantage of the power of Java for business logic and server side processing...I think the Java community in general is fortunate enough to have those guys at Pivot stand up and build something that can actually compete RIGHT NOW with the likes of Flash/Flex and Microsoft Silverlight/WPF without losing your sanity."

Pivot user Scott Lanham said, "The current default theme has a nice clean look and feel...I am impressed with the good selection of widgets. They appear to cover just about every need of an application...Well done with Pivot!"

"Thank you guys with coming up with Pivot," said Java developer and Pivot user N. Forbes. "Java really, really needs a smooth, coherent RIA next generation framework to 'seriously' compete with the likes of Flex and SilverLight/WPF.  I looked at the source code and screamed out in joy!  You guys may actually end up bailing out the Java RIA from pure academic obscurity and back into the more popular sphere of mind."

You can find plenty of live project demos and documentation at the brand-new Apache Pivot website.  Download Apache Pivot and see how it stacks up against other RIA tools.  Take a look at the tutorial for more info on Pivot's features.

Comments

Greg Brown replied on Tue, 2010/01/19 - 12:08pm

Hi Mitchell,

Thanks for posting this - you beat me to it. :-) Just want to clarify a couple of things you mentioned:

  • I wouldn't say that we have "problems" with Swing or JavaFX. :-) The main issue we see with Swing is simply that, in our opinion, it hasn't kept pace with other, newer alternatives for building RIAs. Our primary issue with JavaFX is that, even though it runs in the JVM, it requires developers to learn a new scripting language in order to use it. We (the developers of the Pivot platform) primarily want to build RIAs in Java (though using other JVM scripting languages is a nice option, which Pivot also supports).
  • It's not entirely accurate to say that "Pivot now supports native XML", though this is close. :-) Pivot 1.4 simply includes classes (in the new org.apache.pivot.xml package) that make it much easier to work with an XML DOM in a Pivot application.
  • The demos you linked to are actually live, working examples, not videos. :-)
Also, you failed to mention one of the most significant features in 1.4 - the completion of the TextArea component. Lack of a multi-line text component was a major barrier to using Pivot for many applications in earlier releases.

Otherwise, good work. Feel free to continue blogging about Pivot whenever you like. :-)

Greg

Greg Brown replied on Tue, 2010/01/19 - 12:14pm

One other comment - the InsideRIA links are a bit outdated (they refer to version 1.1). Interested readers would probably be better off reading the tutorial documentation on the Pivot site itself:

http://pivot.apache.org/tutorials/

Jacek Furmankiewicz replied on Tue, 2010/01/19 - 1:07pm

Hi Greg,

first of all congrats on reaching a milestone like this.

Second, any chances of Maven-izing Pivot and uploading it to the core Maven repo? Some Maven archetypes for creating base Pivot/Jetty (and Pivot/Jetty/Spring/Hibernate) web apps would probably help a lot too.

Cheers, Jacek

 

 

 

Osvaldo Doederlein replied on Tue, 2010/01/19 - 1:15pm

First impressions:

- Runtime size seems to be ~3.1 Mb and PureJava => OK

- Only one demo (Component Explorer) shows security dialog => OK

- Once runtime is fully cached by the java plugin (may require loading several demos), startup times (both cold and warm) are excellent - just like common Swing, or JavaFX, apps of similar size (small - not bloated by big resources etc) => OK

- Charting depends on JFreeChart, which is both good (great library: very powerful and popular) and bad (it's big: another 1.7 Mb; and it's very complex) => SO-SO

- Good feature set: many components, containers and other utilities; simple effects/transitions; simple scenegraph; data binding, JSON and a few other RIA stuff => OK

- XML-based, declarative/scriptable DSL: makes me want to puke, but I know I'm minority (Flex and Silverlight have similar XML trash)... and there's no real alternative if you must support the Java language (no DSL-able lang like Groovy, no built-for-RIA lang like JavaFX Script) => OK

- No features at all in areas that would need native code, like media playback or advanced effects; impossible to compete in this are with any of the other RIA runtimes => NOK

- Seems to be a bit of NIH, doing its own stuff everywhere (except charts); I would prefer more reuse of existing/upcoming popular projects, e.g. Trident for all the animation => NOK? (unless many third-party libs are wrapped by Pivot's APIs)

- Remarkably, contains a full API/toolkit for components; you can't use a straight Swing components for somethig as simple as a button: got to use Pivot's wtk.Button class instead of JButton. In my POV this validates Sun's decision to abandon Swing and some up with a full-new API. Pivot is just a more straight replacement for Swing's upper layers, it reuses more stuff in its core (Component, Java2D) and probably also in the programming model; but that's both an advantage and a big compromise. => OK (for Pivot), NOK (for Swing)

Overall, looks like good stuff... but at the same time, I'm very happy that Sun didn't go through this route instead of JavaFX. If you gotta change so much stuff - from the entire high-level API (J* classes) to the introduction of some kind of DSL - then just take the opportunity the change everything that is wrong and design new stuff without any major compromise, which is the JavaFX way.So, even though Pivot is by itself a nice toolkit, it's ultimately a big thumbs-down for the Swing status quo - fails big-time to "bring Swing to RIA", as I don't see much of Swing there to talk about.

Mitch Pronschinske replied on Tue, 2010/01/19 - 1:47pm in response to: Greg Brown

Thanks for the clarifications, Greg. I look forward to covering Pivot more as a Top-Level Project.

Jose Maria Arranz replied on Tue, 2010/01/19 - 1:47pm

Hi Greg, I would like to make a (decent) proposal:

What about a Pivot "Web" Browser?

Let me explain, maybe you know Batik and the Batik applet demo. Batik is based on Java basically providing W3C SVG (markup and DOM), with Rhino JavaScript can be used for scripting, the Batik applet in some way is a SVG browser embedded in a web (HTML) browser, that is you can download an external SVG file with JavaScript behavior embedded.

Another similar example is SVGWeb, in this case the JavaScript engine is of the container browser (Batik is by far more "similar" technically to Pivot).

Why am I interested in this "weird" thing?

Because I'm the author of ItsNat a Java based server centric framework. ItsNat loves markup, almost any markup renderer can be "emulated" in server, in server ItsNat can "control" the client as a very smart "slave" of the server. 

In the upcoming v0.7 version ItsNat supports Batik applet, SVGWeb and other SVG plugins.

The Batik applet example is more similar to Pivot. ¿How it works? Batik applet is like a SVG web browser, ItsNat adds AJAX to the Batik applet and better applet-browser coordination. In server and client the SVG markup is loaded and converted to DOM, when something in server DOM changes then custom JavaScript code is generated and sent to the client to synchronize the DOM in client, when a DOM listener is registered in server a custom DOM listener is also registered in client and any client DOM event of this type is sent with AJAX to the server, received as a W3C DOM Event and dispatched to the server listener. 

By this way an HTML web page containing one or several Batik applets (with SVG markup) is reflected in server as a W3C DOM HTML document with several W3C SVG DOM child documents (in this case accessed through DOM applet nodes), because in server and in client HTML documents and SVG documents are connected, the server Java application can manage both HTML DOM and SVG DOM like a Single Page Interface application.

How does Pivot fit in this scenario? 

 Pivot needs Rhino/JavaScript support, embedded scripting in WTKX code (something like a script tag), something similar to JSVGCanvas  , AJAX simulation in Java accesible from Rhino (I have this code running in Batik). With a similar foundation to Batik applet, Pivot applets could be mixed with HTML code and controlled in server providing rich widgets to web applications.

  Pivot applets in ItsNat environment would be driven by Java code in server and WTKX templates loaded as W3C DOM in server (and in client). A Pivot-W3C Events bridge could convert W3C DOM event listeners registered in server to Pivot listeners in client as JavaScript code, and Pivot events could be converted to W3C Events transported with AJAX (custom events can be possible).

  These ideas fit well with ItsNat, anyway outside ItsNat in my opinion are very interesting too.

 Contact with me if you want a v0.7 pre-release of ItsNat "Batik ready".

 

Greg Brown replied on Tue, 2010/01/19 - 2:37pm in response to: Jacek Furmankiewicz

Hi Jacek,

Pivot has actually been Mavenized - the artifacts were uploaded to the central repository earlier today! :-)

Greg

Jose Maria Arranz replied on Tue, 2010/01/19 - 2:28pm in response to: Jose Maria Arranz

Ugh! my bad, Pivot already supports scripting, the first I've seen Pivot was a Java-only framework.

 

Greg Brown replied on Tue, 2010/01/19 - 2:39pm in response to: Jose Maria Arranz

Hi Jose,

You are correct - Pivot was originally a Java-only framework. However, we have been adding and enhancing scripting support over the past couple of releases. In fact, many of our demos and tutorial examples are written using JavaScript embedded in WTKX.

Greg

Greg Brown replied on Tue, 2010/01/19 - 2:50pm in response to: Osvaldo Doederlein

Hi Osvaldo,

Thanks for the thoughtful and thorough review. I have a couple of comments on some of your observations:

Charting depends on JFreeChart, which is both good (great library: very powerful and popular) and bad (it's big: another 1.7 Mb; and it's very complex)
Charting doesn't actually depend on JFreeChart - Pivot's charting support is pluggable. The only current implementation happens to use JFreeChart under the hood, but others are certainly possible.
Trident for all the animation => NOK
FWIW, I don't think Trident existed when Pivot was created. I'm not saying that we definitely would have used it, but it wasn't an option at the time. ;-)
fails big-time to "bring Swing to RIA"
Also FWIW, Pivot was never meant to be an effort to "bring Swing to RIA". Like JavaFX, Pivot is intended to be an alternative to Swing, though one that allows developers to actually use Java (and XML markup) to build RIAs rather than a new scripting language.

Greg

Jacek Furmankiewicz replied on Tue, 2010/01/19 - 3:29pm in response to: Greg Brown

Cool, didn't see yet in the Maven search browser...you should probably add a quick Maven setup section to your site on what is the group Id/artifact/version.

Preferably with a sample of how to create a Maven web app, have it automatically create the applet, etc. I find Maven archetype a great way to reduce the learning curve for new frameworks like this.

Andres Almiray replied on Tue, 2010/01/19 - 5:07pm

I must say I was esceptical at first when I read about Pivot more than a year ago, but after espending a few days with the API I've found it to be a refreshing alternative. If Swing 2.0 came out today, its API would certainly resemble Pivot's a lot. I'm not so happy with some class name choices (Pivot's ArrayList & HashMap) but they get the job done. Seems to me that the Pivot team decided to mix popular Swing libraries (like GlazedLists, Swingx components for example) which make Pivot not just an alternative UI toolkit but actually a platform (plenty of goodies to be found on its core and util packages).

If a may, the following links show some examples of Pivot being used as main toolkit on a Griffon application

These are valid Pivot applications too, not just Griffon :-)

Rogerio Liesenfeld replied on Tue, 2010/01/19 - 6:56pm

So, as a Java developer it should be easier for me to learn Pivot than JavaFX? I don't think so.

Pivot has its own declarative language to express the UI, which happens to use XML (a terrible choice, IMO). Any half-competent Java developer should be able to understand the declarative syntax of JavaFX Script (which, BTW, is not an scripting language) in a matter of minutes. Learning Groovy or Scala syntax, by comparison, is harder than JavaFX Script. Also, we already have several good books about JavaFX ("Pro JavaFX Platform", for example), not to mention sites like this one.

Pivot may be interesting, but JavaFX is a game-changer.

Jacek Furmankiewicz replied on Tue, 2010/01/19 - 7:08pm in response to: Rogerio Liesenfeld

It's been out for a while now...and it has changed nothing.
Most of us want to stay in Java...that's why.

And JavaFX layers of JSON-style nested brackets are hardly more readable. Just my $0.02.

 

Bryan Young replied on Tue, 2010/01/19 - 8:54pm in response to: Jacek Furmankiewicz

As far as I can tell Pivot isn't much younger than JavaFX, and it also "has changed nothing". While some form of JavaFX/F3 has been available for a couple years now, they're still adding basic components to it. It's still early.

Peter Thomas replied on Tue, 2010/01/19 - 11:11pm

Add me to the list of people who wish to see decent multimedia playback / streaming capabilities.  JavaFX has been very disappointing:

JavaFX won't stream media anytime soon

Andres Almiray replied on Wed, 2010/01/20 - 1:38am in response to: Rogerio Liesenfeld

Oh really? let's see how Java/Groovy/Scala/JavaFX Script stack together (from Java's POV):

 Java
 GroovyScala
JavaFX Script
class declaration
 class Foo{ ... }
class Foo { ... }
class Foo { ... }
class Foo { ... }
variable definition
 <type> name;
 <type> name
 var name:<type> var name:<type>
constant definition
 final <type> name = x;
 final <type> name = x
 val name = x
 def name = x
 method definition
 <access_modifier> <return_type> methodName(<type> arg) { ... }  <access_modifier> <return_type> methodName(<type> arg) { ... }
 def methodName(arg:<type>):<return_type> = ...
 function methodName(args:<type>):<return_type> { ... }
 String concatenation
 "foo" + "bar"
 "foo" + "bar"
 "foo" + "bar"
 "foo" "bar"

 

So, JavaFX Script is actually closer to Scala than Java. Consider that JavaFX Scripts adds new access modifiers that are not available in Java, whereas Groovy and Scala remove the 'package private' modifier. There are of course unique features on each language, I'm afraid JavaFX Script has the short stick as it does not even compare with Java (+ binding, +expressions, +object literal, + functions/closures, -jdk5 features(enum, annotation, static import), - inner classes), in other words JavaFX Script != Java + (binding, closures, object literals, expressions). Both Groovy and Scala sport pretty much the same features as Java and then some, it is not even funny to list them all here.

Learning JavaFX Script is easier than learning Groovy/Scala for a "half-competent Java developer" (as you put it)? don't think so.

Haha Hahahoho replied on Wed, 2010/01/20 - 2:53am

Do you think swiXML will be good enough for doing application part of RIA.

Though in case of Java Swing based enterprise app it work great and also can be extended with many functionlity.

Todd Volkert replied on Wed, 2010/01/20 - 11:33am

@Bryan, FWIW, Pivot's meant to be a viable RIA alternative for those wishing to stay in Java - we never claimed it'd be a "game-changer".  There will be those who prefer C#, ActionScript, or JavaFX, but others that prefer Java.  And those that prefer Groovy or Scala (or JavaScript) can run Pivot using its JVM scripting ability.

Ronald Miura replied on Wed, 2010/01/20 - 2:15pm

How does it handle threads? Is it thread-safe (doubt it, since it builds upon AWT)? Are there any SwingWorker-like API built-in, or some 'good practices' to follow?

Andres Almiray replied on Wed, 2010/01/20 - 5:40pm in response to: Ronald Miura

All UI interactions happen on the AWT thread. The ApplicationContext class provides methods that deal with tasks (deferred and scheduled). I believe you can create your own tasks similar to what SwingWorker provides but I'll leave that to be answered by a Pivot expert.

Greg Brown replied on Wed, 2010/01/20 - 8:50pm in response to: Andres Almiray

Correct. Like Swing, all UI operations execute on the EDT. Pivot provides a Task class for simplifying background execution, and a TaskAdapter class to ensure that task results are processed on the EDT:

http://pivot.apache.org/1.4/docs/api/org/apache/pivot/util/concurrent/Task.html

http://pivot.apache.org/1.4/docs/api/org/apache/pivot/wtk/TaskAdapter.html

However, you can also use Thread directly and post messages back to the UI thread using the ApplicationContext.queueCallback() method, if you prefer:

http://pivot.apache.org/1.4/docs/api/org/apache/pivot/wtk/ApplicationContext.html#queueCallback(java.lang.Runnable)

Greg

Osvaldo Doederlein replied on Thu, 2010/01/21 - 7:25am in response to: Greg Brown

Hi Greg. The bit about JFreeChart is good to hear; I've spent some serious time programming JFreeChart some years ago so I'm kinda fan of it - but then, it didn't seem to have caught up with the times. The API is bewildering (although you can wrap around it, like everyone does - CeWolf, etc. - I did it myself inventing a higher-level framework... admittedly including a big XML-based DSL and taglib and data binding and plugin system - all to make it productive for people writing end-user webapps). The rendering is not fast enough for animation, perhaps because it's not scenegraph-based (JFreeChart does have its own chart metamodel, but I guess it's not designed for incremental change and rendering). Right now, IMHO JavaFX 1.2's charting package totally blows it away: there's less chart types and decorations, but it's MUCH smaller (1/5 of JFreeChart's runtime size) and wins by a landslide in speed, ease of programming and extensibility, etc. I'm not plugging for JavaFX, I guess the charting support in latest Flex and Silverlight should be similar goodness; and I'm sure David Gilbert would be able to write a next-gen charting package to have all these others for breakfast. It's just a matter of abandoning Java2D/Swing and legacy APIs.

I'm aware that Trident was not available, indeed its v1.0 release is very recent. Perhaps you could replace the guts of Pivot's animation while keeping the user-level API?

WRT, Swing, I agree, it's more clear now to me. But please fix your FAQ, it contains an embarrassing wrong comment "Finally, JavaFX's widget support is based on Swing, which suffers from the limitations outlined above."  JavaFX's widget support was never based on Swing, not even in FX 1.0 when the javafx.ext.swing package was a mandatory workaround for apps needing components - that was clearly a temp workaround; JavaFX's native component toolkit is completely independent from Swing and that was true even in v1.0 (there was a single TextBox component plus a few other classes like Control). JavaFX does use a little bit of JavaSE AWT/J2D/Swing in its runtime, but it's less than Pivot (FX components don't inherit Component for example - FX exposes 0% of JavaSE's legacy APIs as its API) and the trend is depending less and less of that stuff in future releases (Prism will say goodbye to much, if not all, of the Java2D/Swing bits used today, even the font engine).

Osvaldo Doederlein replied on Thu, 2010/01/21 - 7:40am in response to: Jacek Furmankiewicz

The excessive nesting that you see in some JavaFX programs (unfortunately including some official samples) are just bad style. My JavaFX sources don't have such nesting, I just break the application's scene graph in many pieces, assigning each piece to a variable, then I bring everything together in the end. Just like, say, you don't write a 500-line method just because the Java language allows it - you refactor it into many helper, private methods, to avoid a mess of formatting (deep-nestes loops and conditions) and maintainability.

OTOH, the "big monolithic tree" style is just great for vector graphics resources (FXD); the JavaFX Script language doubles as a great SVG replacement and it's excellent for that. I can produce some graphic resources in some editor that exports SVG, then convert that to FXD, and what I get is basically a piece of JavaFX Script code (with some restrictions, i.e. only literals as values for properties); I can choose to keep this as a separate FXD/FXZ resource and load it as an Image, or if it's something small I can just copy/paste it into my scene graph code - and perhaps edit it to be more dynamic: it's like programmable SVG (or MXML, etc.), but just DON'T need to open a horrendous CDATA block and write scripts in a completely different and not-integrated syntax. In short, it's just a beautiful thing to see. Upcoming visual editors - JavaFX Composer is already beta, but still focused in the forms/components side - will make this transparency of code/resources more advantageous. (But some people will just complain that now you can embed a 10Mb vector graphics resource in the code so your entire app is a single .fx file - then again, it's not a defect of the language if some programmer has no common sense to properly modularize his code.)

Osvaldo Doederlein replied on Thu, 2010/01/21 - 7:45am in response to: Peter Thomas

JavaFX does support streaming, with the RTSP protocol. This means you must get media from a proper server (rtsp://... URL).

Osvaldo Doederlein replied on Thu, 2010/01/21 - 7:59am in response to: Andres Almiray

I agree that Groovy is a much easier learning curve, up from Java. But Scala? You must be freakin' joking. Scala is a massive language - and yes I'm also very attracted to it, mostly for the functional side - but learning the entire JavaFX Script (reasonably, not guru-level e.g. detailed knowledge of the faster and more elegant way to program anything) is a weekend job. Scala, not so much to say the least, in fact it joins Clojure as a great language that may still flop big-time regardless of its great design and advantages. it's not just size and complexity, Scala breaks the Java intuition in important places, e.g. implicit parameters/converters. JavaFX Script, in contrast, keeps the WYSIWYG feel of Java. In my dreams I would abandon Java in favor of Scala (or similar) for most of my server-side development; but I this this day is much farther in the future than that of massive adoption of JavaFX for the clients-side.

Peter Thomas replied on Thu, 2010/01/21 - 11:12pm in response to: Osvaldo Doederlein

I'm not personally convinced that just RTSP support can compete with the likes of Flash and Silverlight.  Did you read the link I posted?  Here, I'll post it again:

JavaFX won’t stream media anytime soon

Forget about non-existent Ogg support, looks like even H.264 streaming doesn't work.

Osvaldo Doederlein replied on Fri, 2010/01/22 - 5:37am in response to: Peter Thomas

I did read the blog. In part 1, the problem is probably that JavaFX doesn't yet support all FLVs content, just the subset spec'd as FLM. But they also say that on each platform it supports additional media through the native runtime, but then I don't know if this only means media supported by the OS (i.e. FX on Windows may integrate with WMP codecs but not necessarily with Flash if the latter is installed), or perhaps the problem is specific to RTSP which is a new addition to 1.2 and may be limited to the portable formats?

Greg Brown replied on Fri, 2010/01/22 - 8:20am in response to: Osvaldo Doederlein

Re: JavaFX/Swing - I updated the FAQ and removed the line about JavaFX widgets being based on Swing. From a practical standpoint, when the FAQ was written, this was true - JavaFX's native widget set was not sufficient to build a real app. However, you are correct that this is no longer the case.

Re: "JavaFX does use a little bit of JavaSE AWT/J2D/Swing in its runtime, but it's less than Pivot (FX components don't inherit Component for example...)" - I think you may have a slight misunderstanding of Pivot's architecture. The Pivot Component class is not related to the AWT Component class (in other words, org.apache.pivot.wtk.Component does not extend java.awt.Component). Pivot uses Java2D under the hood, but that is the extent of it. No AWT details other than Graphics2D are exposed to the developer. My understanding was that JavaFX also used Java2D under the hood, but perhaps I am wrong about that.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.