Skip to main content

Introducing Pivot

Posted by gkbrown on June 11, 2008 at 8:56 AM PDT

A little over a year ago, I wrote a blog entry describing how I thought applets could regain viability as an application development platform ("Re-Inventing the Applet", 3/6/2007). At the time, I made a few suggestions about what needed to improve in order for this to happen:

  • "A new, streamlined "Java Player" that can be easily downloaded and installed by end users...which, when first installed, would include only a minimal set of classes required by all applications"

    I later discovered that Sun had been actively working on this. At the time, they were calling it the "Consumer JRE", but it is now known as "Java 6 Update 10" and is scheduled for release later this year.


  • "A new GUI toolkit optimized for delivering the best possible user experience on modern operating systems and graphics hardware"

    I learned that Sun had also taken some steps in this direction, optimizing the Java2D API to take better advantage of current graphics hardware (on Windows, at least).

That left one item: the new GUI toolkit. As I suggested in the earlier article, Swing and AWT have grown a bit long in the tooth. The question then became - what should a new Java-based GUI toolkit look like? Sun seemed to think that a new scripting layer added on top of Swing was the answer, but that wasn't consistent with my objectives. I wanted something that would enable Java developers to easily build highly functional and visually engaging applications in Java, not another scripting language, providing capabilities similar to other modern GUI toolkits such as Flex and Silverlight.

After nearly a year of development, I believe I now have an answer to that question.

Introducing Pivot

I would like to introduce the Java development community to the Pivot platform. Pivot is an open-source framework for building high-quality, cross-platform applications that are easily deployable both via the web and to the desktop. It began as an R&D effort at VMware and is now being made available to the community as an option for developers who want to build rich client applications in Java.

Pivot applications are written using a combination of Java and XML and can be run either as an applet or as a standalone (optionally offline) desktop application. While Pivot was designed to be familar to web developers who have experience building AJAX applications using HTML, CSS, and JavaScript, it provides a much richer set of standard widgets than HTML, and allows developers to create sophisticated user experiences much more quickly and easily. Pivot will also seem familiar to Swing developers, as both Swing and Pivot are based on Java2D and employ a model-view-controller (MVC) architecture to separate component data from presentation. However, Pivot includes additional features that make building modern GUI applications much easier, including declarative UI, data binding, and web services integration.

Pivot isn't just another open source web toolkit - it is a full-featured, professional-grade development platform that is sufficiently functional to create a broad range of production-ready applications. We've done our best to include what we think are the most essential features for a 1.0 release, and we have tested as extensively as possible. However, we are looking to the Java development community to help us continue to expand upon what we have accomplished thus far. We need support from developers who are willing to start working with Pivot now, to help us identify issues, complete features, and create reference applications. We are excited about this platform, and we want other Java developers to be excited about it as well.

Pivot is currently being hosted at pivot.dev.java.net. We hope to see you there!

-The Pivot Development Team

Related Topics >>

Comments

Is there any documentation for the WebQuery packages yet? Would make playing with it a little easier.

Sorry, no tutorial documentation yet. But you can take a look at the Javadoc, and there is a functional example in the tutorials of using the GetQuery class (see StockTracker.java):

https://pivot.dev.java.net/source/browse/pivot/trunk/tutorials/src/pivot/tutorials/stocktracker/

Hi Patrick - good questions.

what is your reliance on AWT, the AWT event queue, and repaint management?

Pivot is built on top of the AWT event and painting system, which is how it hooks into Java2D. A Pivot component's paint() method takes an instance of java.awt.Graphics2D as an argument. However, with the exception of the Java2D classes, Pivot developers won't need to know about the existence of AWT - it is abstracted by the ApplicationContext class.

What about i18n?

Pivot applications can use the standard Java APIs for internationalization and localization (resource bundles, etc.).

RTL support?

Not yet...

And accessibility?

Also not yet. This is on our TODO list.

Look and feel support?

The appearance of a Pivot component is defined by its skin. Pivot ships with a default skin package called "Terra", but it has been architected to readily support additional look and feel packages.

What tools are you using to lay out your forms, etc.?

Pivot supports layout management, just like Swing. However, Pivot places responsibility for layout on a container's skin, rather than a separate layout manager class. We think this promotes better encapsulation and is easier for developers to work with. Some other newer GUI toolkits have taken a similar approach. Pivot provides a number of default layout containers including FlowPane, TablePane, and CardPane, and developers can also create their own custom layouts.

What about a framework for developing apps, like the Swing App Framework?

I'm not familiar with this project, but a quick look at the project page says that it "provides infrastructure that's common to most desktop applications":

  • Application lifecyle, notably GUI startup and shutdown. This is built into Pivot. Take a look at the Application interface, discussed in this example: https://pivot.dev.java.net/nonav/tutorials/hello.html.

  • Support for managing and loading resources, like strings, formatted messages, images, colors, fonts, and other types common to desktop applications. Not quite sure what this means. Pivot relies on the built in features of J2SE for much of this. It is very easy to access your resources from within WTKX (Pivot's markup language), though. The WTKX loader performs resource substitution using values defined in your resource bundles.

  • Support for defining, managing, and binding Actions, including Actions that run asynchronously (in the "background"). Pivot provides the pivot.util.concurrent.Task class for this purpose.

  • Persistent session state: support for automatically and selectively saving GUI state from one run of an application to the next. Pivot does not current provide any framework support for this.

Dmitry, A grep for 'javax.swing' in the source of java/awt/* yields that Sun has built a dependency on Swing within AWT: EventDispatchThread#checkMouseEventForModalJInternalFrame(...): > if (modalComp instanceof javax.swing.JInternalFrame) { ... Container#startLWModal(...) > Component predictedFocusOwner = (this instanceof javax.swing.JInternalFrame) ? ((javax.swing.JInternalFrame)(this)).getMostRecentFocusOwner() : null; This is probably what's preventing you from purging Swing. I'd file a bug to Sun, since this dependency is horrendous!

Greg, I was experimenting with the standalone Desktop demo. If we find out how to get rid of Swing in it, we can get some nice download size and disk footprint figures for Pivot applications! For instance, TuxGuitar (http://www.tuxguitar.com.ar/), which is done using SWT, is a 9.5 MB download and takes 31.1 MB of disk space when optimzied and packaged using Java Runtime Slim-Down. These figures _include_ the required parts of the Java SE runtime. Now compare this to the JRE: JRE 1.6.0_03, which I have on my system, was a 13.9 MB download and occupies 79 MB on the disk. If you want to pursue this further, my email is at the bottom of http://www.excelsior-usa.com/contact.html Dmitry

RE: Layout. I don't see the distinction between constraint-based layout and "attribute" layout (both seem to involve associating a layout metadata with a component for the benefit of a layout algorithm) but I'm looking forward to learning more. I'm also interested in seeing if coupling a panel with a layout algorithm is a better approach for developers. If you care about the "cleanliness" of your component hierarchy, it's obviously a step backwards, but people nest panels all the time to achieve effects. I'm so used to decoupling layout from containment hierarchy (tabbed panes excepted) that I've never really considered this approach.

RE: Collections framework. Implementing a custom "java.util" Collections interface is fairly exotic; most folks just choose from amongst the hundreds of excellent implementations around. Map is not directly iterable, but all you need do is invoke a single method to get a keySet or entrySet. It's not hard, nor particularly inefficient. The SortedSet and SortedMap interfaces in java.util Collections provide sorted collections that take a Comparator. If you really want to do this with a List, you could create one with a trivial subclass. Another benefit of sticking with java.util Collections is the ability for Pivot users to take advantage of the extremely high-quality java.util.concurrent collections implementations added in Java 5 (and available stand-alone for older versions).

RE: ListMap. The only difference between a java.util Map and a ListMap is that the ListMap would presumably allow for ambiguous keys, which makes absolutely no sense in a Map. If you want a ListMap with unambiguous keys, then a SortedMap seems exactly what you want. You'd call keySet() to get a sorted collection of the map keys for the tree nodes, and the value would be a List containing the tree nodes.

RE: Conversions between Pivot collections and java.util Collections. Unless you have other reasons for doing your own collections that you haven't yet voiced, I'd run away from your current collections library and swap it out for java.util Collections. We already have way too many frameworks to choose from in Javaland.

RE: Making Pivot "work with a different, java.util-based collections library". The huge value is in making it use the standard Collections interfaces. If you use observable implementations under the covers, fantastic! But let users use the standard library for collections. There is a gap in that the JDK still does not have a standard observable list, but there are dozens of implementations still around for the taking, many of whom with licenses that would permit you to fork it for your own project.

Thanks again for sharing Pivot with the world. Obviously our opinions differ on the topic of collections, but that's obviously just a minor detail. Looking forward to diving deeper.

What a pity. Anyway, even with some Swing classes compiled I was able to get the download size of PivotDemo down to 9.3MB. The disk footprint is 34.6 MB. It also seems to use a bit less memory than if run on Sun JRE 1.6.0_03. You can give it a try if you wish: http://www.excelsior-usa.com/download/jet/jrsd/640/PivotDemo-setup.exe Dmitry

Hi Greg--this is a pretty brave project to take on, and VMWare deserves high kudos for open-sourcing the effort.

Some questions--what is your reliance on AWT, the AWT event queue, and repaint management? What about i18n and RTL support? And accessibility? Look and feel support? What tools are you using to lay out your forms, etc.? What about a framework for developing apps, like the Swing App Framework?

I'm excited to see what the community does with this.

Cheers

Patrick

Hi thirdy, No IDE integration yet, but the framework has come quite a long way since this entry was posted. Check it out at http://incubator.apache.org/pivot. No reason you can't currently use Hibernate as your back end - Pivot comes with built-in support for working with REST services, but you can really use any Java-based web service API you like. We have some sample applications that talk to AMF (Flex) back ends as well as XML-RPC services. I haven't personally tried building a Pivot app using Axis, but I imagine you could do that pretty easily as well. Greg

Although I have yet to type Pivot in Firefox's address bar, I'd say Pivot is great :D I hope there's an IDE integration now, and if there's one, I hope it's NetBeans. I'd also like to see Pivot as full stack framework, with Hibernate underneath. Then go to full throttle effort to get it really mature framework like Seam, Grails, Rails, JSF, etc.

Why not use something like SwiXml (or various similar technologies) instead of replacing Swing?

Honestly, because Swing is 10 years old and hasn't significantly evolved in that time. It just isn't quite as nice or as easy to use as some of the newer toolkits (Flex, WPF, and even DHTML, to some extent).

Why not use something like SwiXml (or various similar technologies) instead of replacing Swing? Not to say that you don't have a good reason. I just don't see the _explanation_ here of why to replace Swing rather than use XML/CSS and binding from Java for behavior while still using Swing underneath.

Hi; the demo application gives me this: "java.security.AccessControlException: access denied (java.util.PropertyPermission sun.awt.noerasebackground write)" Firefox 3, JDK6.0.10b25

Nice to see a bold new initiative, and some of the ideas are certainly intriguing. But forcing another collections library is a big turnoff, and the fact that the development team was unaware of stuff like JGoodies, GlazedLists, Swing App Framework, Eclipse & Netbeans RCP, but being intimately familiar with WPF, Flex etc. makes me wonder. Just how much of this is pure NIH?

I'm a little confused by your post. Netbeans and Eclipse are IDEs...Pivot is a UI toolkit.

You can use Netbeans or Eclipse to build Pivot applications (or you can use a command-line build tool like Ant). We actually use both to build Pivot.

Kudos to you for your work, but for you to convince experienced swing / swt hands to use it, I think you should compare against the big RCPs (Netbeans, Eclipse). With the infrastructure / framework the RCP's give you out of the box(itf you build on them, it's at least 2 man years worth of development) I'd like to know why I'd choose pivot over them. Obviously for desktop scenarios...

Netbeans and Eclipse are IDEs...Pivot is a UI toolkit

Eclipse RCP and NetBeans RCP are application frameworks based on SWT/JFace and Swing respectively that give you a bunch of additional value-adds on top of the traditional features of a GUI toolkit. Both include a dizzying array of common (and esoteric) functionality commonly used in the construction of applications.

I know it's early in the development stage, but Is there any documentation for the WebQuery packages yet? Would make playing with it a little easier.

Ah, thanks for the clarification. I took a quick look to get a better understanding of what these platforms offer. It seems like something that could certainly be added to Pivot in the future, if it made sense. I wouldn't think that the lack of such a feature would preclude building "real" applications using Pivot now, though. Not all applications require that level of infrastructure.

PS. Forgot to mention, great work. Looks Fabulous.

Hi Greg

How are multiple repaint managers used to paint reflections?

See chapter 11 of Filthy Rich Clients, they go into some detail about the techniques to use, why it's necessary, etc.

Serialization of a component tree

I would be looking for a very reliable and fully functional system to be able to load/download form or panel layouts on the fly from some serialized form. Editable and serializable would be even better, e.g. not a binary format. A standard serialized form (e.g. support officially by Pivot) would also allow us to move more easily between visual GUI/layout tools--currently there is no such standard for Swing, thus, for example, NetBeans has its own forms description, IDEA has its own, etc.

Thanks

Patrick

this is probably the most excited I've been in a long time! Having had to work on a Swing toolkit (originally developed by Travell Perkins whose probably reading this) and dealing with Swing for way too long, this is a great start to breathe new life outside of JavaFX (which by itself seems promising). The difficulty we have all had is when you go side by side to other frameworks like Silverlight 2, Flex, and look at the code behind techniques, binding, etc, it is a huge difference going back into Swing. Its the feel, the context switching, the amount of code, everything. In fact, I would dare say that from the looks of it, this is where the application framework should have been going all along, but I guess that's pretty much DOA. We've been using the JIDE components for a while now, very nice widgets with their own framework. Its the glue in between that is missing and hopefully this will address it.

Double-buffering strategy? How is this different from Swing's?

Pivot does double-buffering at the display level. All repaints are double-buffered. We first try to use a volatile image; if that fails, we use a standard buffered image. If that fails, we just call paint() directly.

RepaintManager? Is there just one global one? This is a complaint regarding Swing for people who want an "extended" RM for special cases (like painting reflections).

Interesting use case. We don't have a dedicated RepaintManager class - all repaints get funneled through the ApplicationContext, which is effectively our interface into the AWT paint system. Since that is a singleton, I guess it could be considered a global repaint manager.

How are multiple repaint managers used to paint reflections?

Serialization of a component tree?

We support reading of a component hierarchy using WTKX - we don't support writing. Do you have a use case for that?

Layers? Projects like JXLayer try to address use cases like "I want to paint a standard text field with an 'invalid entry' marker"

In Pivot, you might do that by extending the text input's skin class. Alternatively, the Form class provides a means for you to "flag" components containing invalid data. However, we have talked about adding a generic "layer pane"-type class. It would basically be a CardPane where all the cards are visible instead of just the selected one. I imagine there are a number of use cases for a component like this (displaying a background image is another example).

Hi Greg--thanks for your answers. Some follow-up questions

Double-buffering strategy? How is this different from Swing's?

RepaintManager? Is there just one global one? This is a complaint regarding Swing for people who want an "extended" RM for special cases (like painting reflections).

Serialization of a component tree?

Layers? Projects like JXLayer try to address use cases like "I want to paint a standard text field with an 'invalid entry' marker"

Thanks!

Patrick

I would be looking for a very reliable and fully functional system to be able to load/download form or panel layouts on the fly from some serialized form.

This is most definitely supported by Pivot.

Editable and serializable would be even better, e.g. not a binary format.

Pivot's serialization format is XML, which seems consistent with your requirements.

A standard serialized form (e.g. support officially by Pivot) would also allow us to move more easily between visual GUI/layout tools

Pivot's XML format is called WTKX, and it is officially supported. However, this doesn't preclude developers from writing their own. We intentionally left pivot.wtk (component classes) and pivot.wtkx (component loaders) separate for this reason.

How do you see layout working in typical developer scenarios? I'm used to setting a layout manager on a container and then dealing with the layout manager's API. Are you planning on a more centralized approach to layout where most developers use built-in skin layout algorithms? Do you anticipate developers rolling their own layout managers, subclassing a skin, setting it on a component, and having the skin invoke the custom layout manager?

Layout is effectively baked into the container. A FlowPane performs flow layout, TablePane performs table layout, etc. To modify the behavior of the layout, you can set a style property (e.g. set the "horizontalAlignment" style of a flow pane to "center"). Where Swing and AWT might use a constraint, you can use what Pivot calls an "attribute". Attributes are properties that are attached to components and only have meaning to the component's parent. For example, TabPane has a "label" attribute. I believe WPF does something similar, and it seemed more elegant to us than layout managers w/constraints.

If you wanted to write your own layout manager, you'd just create a new subclass of Container, implement a skin, and off you go.

There are already numerous observable collection implementations in the open source world; the Glazed List project has some of the best.

That's true - though we didn't discover the Glazed List project until after the Pivot collection classes were essentially complete and in use. There are other things that made Java collections less desirable, though. The Java collection interfaces are not as simple to implement as the Pivot interfaces, and working with sub-lists is a bit clunky. Additionally, Map is not iterable, which, ideally, it would be (so it could be used like an Object in JavaScript). Finally, Pivot collections can be assigned a comparator that ensures the collection contents are automatically sorted. This is convenient when implementing an editable tree view whose contents should remain in alphabetical order, for example.

What do you mean by combining collections? I didn't see a MapList amongst your classes; does it do something more than a HashMap would?

What I meant was something like creating a subclass of ArrayList that implements Map. This is very handy for creating a tree structure: the list contents are the child nodes, and the map properties are the node attributes (such as "label" and "icon"). I had forgotten that it is actually possible to do this using the java.util collections, because Map does not extend Collection (otherwise, the template types of the base Iterable interface are likely to clash). However, that's also why Maps aren't iterable. In any case, this works with either Java or Pivot collection classes - so never mind. :-)

No conversion constructors in your collections that take the java.util.Collections versions?

That's definitely something we want to address. Probably the easiest thing to do is write wrapper classes so we don't need to copy the data (in fact, this is how the Pivot collections are currently implemented, but that will change in the future).

Clearly, creating a new set of collection classes is controversial. Could we have made Pivot work with a different, java.util-based collections library? Probably. Would it have been as easy, and would the result have been as elegant as we would like? Maybe not. If developer interest in Pivot grows, I'm sure there will be additional discussion in the future on this point.

It is handled in a manner very similar to Swing - components call invalidate() as needed, and layout() is called during a validate(). The actual layout() implementation is delegated to the container's skin.

I did notice the component-level layout / paint contract was nearly identical to Swing, I just wasn't sure where the layout algo was actually implemented.

How do you see layout working in typical developer scenarios? I'm used to setting a layout manager on a container and then dealing with the layout manager's API. Are you planning on a more centralized approach to layout where most developers use built-in skin layout algorithms? Do you anticipate developers rolling their own layout managers, subclassing a skin, setting it on a component, and having the skin invoke the custom layout manager?

We created the Pivot collection classes largely to work around the limitations of the existing java.util collections: no support for events

There are already numerous observable collection implementations in the open source world; the Glazed List project has some of the best. What do you mean by combining collections? I didn't see a MapList amongst your classes; does it do something more than a HashMap would? No conversion constructors in your collections that take the java.util.Collections versions?

Were you shooting for "Swing evolved?"

Swing certainly influenced a lot of Pivot's design, yes. However, we tried to incorporate some of the better features from other toolkits as well.

do you support any label text formatting? doesn't look that way

Not in the Label class. We'll eventually be adding a rich TextArea component that will support this.

Why in heaven did you create your own collections classes? Why, man, why?

Excellent (and anticipated) question. We created the Pivot collection classes largely to work around the limitations of the existing java.util collections: no support for events, and an inability to combine collections - primarily List and Map. A MapList is a great way to model a tree node, or an XML element - it's just not possible using the Java collections.

Do you have any analog for Swing's UIDefaults?

Not yet - that's a TODO item.

Why did you leave state out of your Action interface? Do you have any analog to Swing's Action interface in terms of sharing action state?

Do you mean the get/putValue() methods, the is/setEnabled() methods, or both?

I didn't see any layout managers; how do you handle layout?

It is handled in a manner very similar to Swing - components call invalidate() as needed, and layout() is called during a validate(). The actual layout() implementation is delegated to the container's skin.

In any event, welcome from this third-party developer.

Thanks!

I have lately contemplated writing "Heresy", a concurrent GUI toolkit (i.e., has built-in support for pushing long-running operations into a background thread, etc.)...Will be fun to see what you've done to address common problems in Swing.

Pivot has support for this via the pivot.util.concurrent.Task class. In conjunction with pivot.wtk.TaskAdapter, this class can be used to execute tasks on a background thread and post results to the UI thread. This is actually how asynchronous image loading and web service calls are executed in Pivot.

Your demo shows a basic set of components; do you innovate beyond those?

We tried to include the most common components for this release, but we plan to add more over time. Also, we designed Pivot to be easy to extend - we're hoping that other developers will do so by creating some of their own Pivot-based widgets.

Do you address Swing's limitation of preferring width and height atomically instead of separately?

Yes. Pivot supports the notion of "constrained preferred size" - the Component class defines getPreferredWidth(int height) and getPreferredHeight(int width) methods in addition to getPreferredSize(); passing a value of -1 to either of these methods indicates no constraint, but any other value tells the component to return its preferred size given this constraint. This allows us to wrap text in labels, for example.

Do you have any layout managers matching the sophistication and maintainability of JGoodies FormLayout?

I think so. I haven't used FormLayout myself, but after a quick visit to jgoodies.com, I think our Form class is probably comparable.

What are the specific characteristics of your application that make it different than Swing, other than "Swing is large and old"? ;-)

Heh. Well, you've already hit upon one of the big advantages Pivot offers over Swing - constrained preferred size. A couple other advantages are:

  • Cleaner implementation of MVC - Pivot Components have no intrinsic presentation (i.e. no setFont() or setBackgroundColor() methods); this is left entirely to the skin (Pivot's equivalent of a UI delegate) and is exposed as a set of "styles".

  • Layout containers vs. layout managers - like most modern UI toolkits, we make layout an intrinsic responsiblity of the container (actually, the container's skin) rather than an attached layout manager.

  • UI construction via XML markup, including CSS-like styling.

  • Common data model - all data-driven components use the interfaces in the pivot.collections package for model data. There isn't a separate TreeModel, TableModel, etc. It is analogous to Swing using the classes in java.util for model data (though this isn't really possible since those classes don't fire events). The benefit is that any data that can be modeled as a collection is instantly available as a data model for a Pivot component.

    For example, Pivot includes a JSON serializer that deserializes JSON-encoded data into Pivot collections. This data can immediately be applied as a data model without any intermediary translation to the component's "native" data model.

Your demos are broken on Firefox 3.0 RC2 on OS X 10.5.3 running the latest Java 5.

If you are using Mac OSX, this is unfortunately a known issue. Pivot does not currently work in Firefox on the Mac. We'll have to see what we can do to address that.

Looking over your classes now. Interesting how your architecture is from a high-level is very similar to Swing. The contract for components, UI delegates, listeners, etc. is all quite similar (e.g., the way layout works is in particular very similar). Were you shooting for "Swing evolved?"

I can see you've hit a few of my favorite Swing pain points:

  • preferred width and height available as separate or atomic properties
  • wrapping labels (do you support any label text formatting? doesn't look that way)
  • row-based table data model
  • built-in "form" constructs

Some addt'l questions:

  • Why in heaven did you create your own collections classes? Why, man, why?
  • Do you have any analog for Swing's UIDefaults?
  • Why did you leave state out of your Action interface? Do you have any analog to Swing's Action interface in terms of sharing action state?
  • I didn't see any layout managers; how do you handle layout? The tutorial mentioned that skins do it, but I didn't see any contract stand out (other than the built-in methods on Container).

Thanks,

Ben

Yes, it did after I restarted. Interesting work.

Can you throw up some JavaDocs somewhere?

Fun to see another Java2D-based GUI toolkit wade into the waters; haven't seen a new player since Thinlet back in the day (although it appears Thinlet is still under active development).

In any event, welcome from this third-party developer. Many in the Swing community daydream of writing a new Java2D-based toolkit, few get around to it. I have lately contemplated writing "Heresy", a concurrent GUI toolkit (i.e., has built-in support for pushing long-running operations into a background thread, etc.); I'll never get around to it. Will be fun to see what you've done to address common problems in Swing.

Your demo shows a basic set of components; do you innovate beyond those? Do you address Swing's limitation of preferring width and height atomically instead of separately? Do you have any layout managers matching the sophistication and maintainability of JGoodies FormLayout? What are the specific characteristics of your application that make it different than Swing, other than "Swing is large and old"? ;-)

Your demos are broken on Firefox 3.0 RC2 on OS X 10.5.3 running the latest Java 5. Works on Safari.latest on OS X 10.5.3, but the project page times out on Safari so I had to discover the demo link from Firefox and paste into Safari.

Congratulations on bringing to light all your hard work over the past year!

That exception shouldn't be a problem. Does the demo run OK otherwise?

You are correct - Pivot does not have any dependencies on Swing. I'm not sure what might be loading those classes. It's possible that the plugin requires Swing because the Java control panel uses it.

Greg, My understanding is that Pivot is meant to be a replacement for Swing. But I see some Swing classes in the HotSpot log if I run the desktop demo using "java -verbose": [Loaded javax.swing.TransferHandler$HasGetTransferHandler from C:\Program Files\Java\jre1.6.0_03\lib\rt.jar] [Loaded javax.swing.JComponent from C:\Program Files\Java\jre1.6.0_03\lib\rt.jar] [Loaded javax.swing.JPanel from C:\Program Files\Java\jre1.6.0_03\lib\rt.jar] Because of this, Java Runtime Slim-Down (http://www.excelsior-usa.com/java-download-size.html) does not let me omit Swing and the resulting installer is over 9.5 MB. I further believe that Pivot applets won't start on Java Kernel until Swing is downloaded. Can you confirm whether Pivot has Swing dependencies or not? If not, do you have an idea why those classes appear in the log?

You make some good points. I'll try to address them.

  • Forcing another collections library is a big turnoff

    I can certainly understand your perspective. However, you are not required to use the Pivot collections library - the standard Java collections are still available to you. They can also be wrapped in a Pivot collection if you want to use them as your component's data model. Additionally, you may find that working with the Pivot collections is easier - I do.

  • The fact that the development team was unaware of stuff like JGoodies, GlazedLists, Swing App Framework, Eclipse & Netbeans RCP, but being intimately familiar with WPF, Flex etc. makes me wonder.

    Fair enough. We haven't done active Swing development for a couple of years, and we've probably missed a few things. However, exposure to these other technologies really helped us identify what worked well in Swing and what other toolkits did better. Pivot is a better platform because of it.

Keep in mind that Pivot was not necessarily designed as a replacement for Swing (although it can certainly be used that way in a number of contexts). It may actually be more immediately useful to non-Swing developers, especially those currently working in AJAX. While a seasoned Swing developer may be aware of the various add-ons that have been created by the open source community over the years, a new (or returning) Swing developer probably won't be. Pivot attempts to provide a complete "out of the box" solution that we think can serve a wide range of developers' needs.

> are they really valid arguments to throw a framework like Swing overboard? We think so. :-) Note that the SwingAdapter class Todd mentioned doesn't actually exist yet - it's just something that we have talked about building, to help bridge the gap between existing Swing apps and Pivot. However, as Todd said, it wouldn't be terribly difficult to create it.

Hi Greg & Todd, I actually had already the referenced article on http://java.dzone.com/news/interview-greg-brown-todd-volk but still didn't think the mentioned arguments very convincing. I mean they are valid points (although I personally find UI construction using XML markup quite debatable regarding not being cumbersome), but are they really valid arguments to throw a framework like Swing overboard? For me one of it powerful aspects is it's extensibility. For instance you mention the lack of databinding, but what about the beansbinding project? Anyway, I hadn't read about the SwingAdapters so I will definitely have a look at that.

Christiaan, As a follow-on to Greg's reply, I'd point out that writing a SwingAdapter component for Pivot would not be that tough. Such components weren't a priority for us when writing Pivot because we believe that there's a lot of value in replacing Swing entirely, but for organizations that want a seamless migration path, one exists :) -Todd

Christiaan- One more link for you - the comments here also go into some detail comparing Swing to Pivot: http://java.dzone.com/announcements/introducing-pivot As I mention in one of the comments, it is worth noting that we didn't create Pivot strictly as a replacement for Swing. It may actually be more useful to non-Swing developers, especially those currently working in AJAX. You can do a lot of the same things in Swing that you can do in Pivot (though we think Pivot makes it significantly easier to do so); creating similar functionality in AJAX is much more difficult. We tried to address the needs of multiple audiences when designing Pivot. -Greg

Hi Christiaan- Take a look through some of the previous comments - I think they articulate some of Pivot's advantages over Swing pretty clearly. See this article for some additional discussion: http://java.dzone.com/news/interview-greg-brown-todd-volk -Greg

Looks very promising. I definitely would consider this when starting a new "rich-client" project. However, I am not so convinced about your argument "because Swing is 10 years old and hasn't significantly evolved in that time" Just look at a company like Jide and all the components they produce. I wouldn't want to throw this overboard and start from scratch. I think it is a wise decision of Sun to enable reuse of this "legacy" in javafx. Introducing a new UI toolkit is probaby a big barrier to get widely accepted. I would love to see a technology to render a swing application in the browser. Too bad you decided to create your own component structure;-) kind regards, Christiaan

Just wanted to mention as a follow-up to my last post, http://www.tentackle.org/html/en/index.html their FAQ is funny, what's your comment on this project? I watched saw Adobe's new Catalyst, looks like it's gonna get popular (for people(swarm of them) who use Photoshop). I think and I hope tentackle is the framework for me (I hope I'll get things done this time), but Pivot's UI is still awesome!

Hi, Greg Thanks for the quick reply! To be honest I'm still a newb, my only experience is with Java/Swing, JDBC/Wicket then I just recently struggled with the different Java ME optional API's. Right now my project is a CRUD based business app, not necessarily web-based but looking for fast, easy and convenient way to develop with Java, I got attracted to WaveMaker, but now that I need to code logic, I found myself typing "mvc framework for swing". That's why I got here (but before that I saw lot's and lot's!!! of framework, I even saw VB6 on top of Java, http://www.jabaco.org/ haha). But seriously, IMO, there should be an effort in making a single Solution for Java that would get lot's of audience like VB6 did, but this time it's Open, Free, Easier, Simpler but more Powerful. Anyway, I'll try my best to try to make a CRUD in Pivot/Hibernate. Btw, Pivot's UI are awesome! thirdy