posts/2009/swing-20/index

[JonathanGiles]

Java Swing 2.0

https://jonathangiles.net/posts/2009/swing-20/

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 29, 2009

@Bernd Rosstauscher: Your opinion is just as significant as everyone elses! Your thoughts are much appreciated, and I tend to agree that refactoring would be much easier, in the sense that people will instantly see progress, and we can follow a more 'release early, release often' approach.

Personally, I love refactoring, especially major refactoring - it's like breaking apart a puzzle and trying to put it back together again, but with the challenge of making the code better, cleaner, and less complicated/bloated.

I'm all for either Swing 2 approach, but my inclination is often shifting. Right now I agree that a refactor is better and faster than a rewrite.

Keep up the comments, now moreso especially because we are slowly getting the attention of people within Sun. Cheers!

[JonathanGiles]

Auto-imported comment, original author: Felker Robert Comment posted on: January 29, 2009

As a every day entreprise programmer i've take a look at JavaFX. My question to sun is : how to i deal with my legacy code ? how can i build entreprise level application without even basic standart component like Swing ?

FX respond to a need of multimedia for the multimedia client application it could not be a replacement for Swing until several months and only if it lead to an advanced framework which noboby now can even imagine.

The idea i got from Swing2 is a SwingX visually reach components framework based on the last Java grammar evolution. And said like this it perfectly feel the gap for every day job.

I do REALLY HOPE that some strong DECISION to START SWING2 will emerge from this thread.

Cheers !

[JonathanGiles]

Auto-imported comment, original author: Maya Incaand Comment posted on: January 31, 2009

Well, I don't know much but I am busy learning JavaFX and I am learning about Swing indirectly so I can use it in JavaFX.

I suggest you figure out how to use JavaFX in Swing and you will make a lot of friends:-)

[JonathanGiles]

Auto-imported comment, original author: Comment posted on: February 1, 2009

<strong>A replacement for Swing is well overdue. But it should not be based directly on Swing....</strong>

Although Java's Swing has very little usage in consumer-grade software applications, it is used in a significant amount of in-house business software at many companies, as well as in a variety of system administration tools. While it was one of the ma...

[JonathanGiles]

Auto-imported comment, original author: GeekyCoder Comment posted on: February 1, 2009

Starting from scratch seems too daunting and not many understand the internal of Swing well enough to make radical architectural change (though with the Swing team's help, it is possible but now their focus seems to be JavaFX).

Just like Aberrant thought, Is it to possible to fork out the existing Swing and probably start from there like remove deprecated methods, standardised call, add additional classes, update it (like use ArrayList and generics in gui datamodel), improve it (adding MIGLayout as core, etc). Over the years I have improved certain classes in Swing that hopefully can be backported in "new Swing". It is very likely to break binary compatibility.

Improving the Swing to such extent in OpenJDK seems impossible since Sun still wedge control over it ?

[JonathanGiles]

Auto-imported comment, original author: Nitin Comment posted on: February 1, 2009

Well, Swing2 is in development in some form :-) Richard Bair saying "new user interface control toolkit" in this JW article:

http://www.javaworld.com/javaworld/jw-01-2009/jw-01-client-side-roundtable.html

Hopefully it is in Java, NOT JavaFX and lessons learned :-)

Cheers.

[JonathanGiles]

Auto-imported comment, original author: Tom Corbin Comment posted on: February 1, 2009

I love the idea of a swing2.0 that is separate from JavaFX. I'm a groovy guy myself, but I still see a need for a swing2.0.

I would love to see it built on glazedlists, my all time favorite java library.

I also agree that taking swing1.0 and going for the swing2.0 goals via refactoring is probably the best way to achieve anything.

My vote would be not to wait for properties in the java language.

I love all of Mr, Grev's ideas except waiting on properties.

If we have to have properties, I'd rather have something we don't have to wait for in the language, but use something someone was pushing on java.net a while ago where you don't use String or Integer, but StringProperty and IntegerProperty and they have built in events and such. I know that's likely to be controversial, though. But if we had that, we wouldn't have to wait for properties in java.

it's just that properties in java is such a great idea, but for some reason hasn't made it so far, so I don't see it making it at all.

I also like a lot of the ideas in JMatter, though I don't know that they are applicable in swing2.0.

I also agree that manpower is a big issue. I don't feel that I am all that much of an expert to be able to do much of the intricate coding, and it's hard to find the time.

So, big thumbs up to Mr. Grev and swing2.0.

[JonathanGiles]

Auto-imported comment, original author: Abraxis Comment posted on: February 1, 2009

Regarding properties - I think Swing 2.0 can NOT be dependent on them - even if they are available in Java 7, still there are many good reasons to keep support for Java 5 (or at least 6).

[JonathanGiles]

Auto-imported comment, original author: Gabriele Carcassi Comment posted on: February 3, 2009

+1 from me. It seems that by posting this, and by the response, you are now have the ball to organize this... ;-)

There is one point that I would be willing to work on: models. Most of them can be easily generified without really impacting that much on the rest of the API. For example, a ListModel can become a ListModel. Then we can have a series of model implementations that constructs models from collections. For example: ListModel CollectionsModel.createListModel(List list).

I am already forced to do things like these... and other people here have already complained about models too...

[JonathanGiles]

Auto-imported comment, original author: Gabriele Carcassi Comment posted on: February 3, 2009

Oh well, it seems that the generified notation on my previous comment was lost...

[JonathanGiles]

Auto-imported comment, original author: swpalmer Comment posted on: February 3, 2009

I generally like most of the ideas presented so far, but I disagree with some of Mikael's suggestions.

• I think Components should NOT be able to paint outside their bounds (drop shadows should be handled differently if you want them to extend beyond the component bounds. Just have a way for components to paint on another layer, where their bounds don't apply.

• I think Components SHOULD be containers - e.g.: the idea that an editable combobox contains a text field and a button makes sense.

I think properties are needed if you are going to put in the effort to make a Swing 2 that is the time to get properties into the language.. rather than having another mismatch when they are added later. (Just like we have with collections framework and swing now. Or static final ints and no enums, etc.)

[JonathanGiles]

Auto-imported comment, original author: Florian Over Comment posted on: February 3, 2009

I want to give you a hint to: http://weblogs.java.net/blog/hansmuller/archive/ts-3492-final.pdf Its not directly about swing 2.0 but about important thinks in the context. For inspirational purpose you should also give groovy+swingbuilder a try, its a breaze of fresh air.

[JonathanGiles]

Auto-imported comment, original author: varan Comment posted on: February 3, 2009

I would suggest that there are too many layout managers in Java SE. For the average user this causes a great deal of confusion.

A new layout paradigm that allows the users to put components in limited number of 'structured' containers such columns, rows, grids, tabs and cards with proper specified alignments will simplify the Swing programming considerably. Imagine being able to do something like this

createRow(verticalAlignment, horizontalAlignment, oneDGUIObjectArray)

createGrid(verticalAlignment, horizontalAlignment, twoDGUIObjectArray)

createColumn(verticalAlignment, horizontalAlignment, oneDGUIObjectArray)

where the arrays contain Swing Components or the aforementioned 'structured' containers.

This will be an order of magnitude improvement over the existing way of doing things, and make the concept of layout manager essentially irrelevant for the typical users, obviating the need for every tom, dick or harry to invent his own layout manager and proclaim it to be the best among the lot.

Of course such an approach has already been implemented, but Swing can do it too.

[JonathanGiles]

Auto-imported comment, original author: CurtCox Comment posted on: February 3, 2009

@Tom Corbin Bean Properties might be the project you are thinking of. https://bean-properties.dev.java.net/

I actually prefer the approach of using a well defined property interface to that of adding properties to the language. There are a few similar projects, but I think that one is the most developed.

The problem with using an enhanced definition of properties and beans is that tool support will lag. Nonetheless, it is worth doing. Jettisoning the inherited AWT methods have similar consequences that are even more drastic. The current level of AWT interoperability that Swing provides has long since ceased to be worth the API price it imposes.

[JonathanGiles]

Auto-imported comment, original author: bjb Comment posted on: February 3, 2009

+1googol for Swing 2.0.

Let me add my own todo list :

• pure Java2D default PLAF
• full support of alpha chanel (yes, I want to be able to do overlay in applet over a HTML page)
• default vector base plaf (nimbus)
• enhanced java control pannel (default LnF, properties configuration, etc)
• Editable list ("yes we can")
• default Bean friendly/aware model
• tight integration with EJB : automagical link established whatever is the network condition (proxy, etc) security)
• default renderer for esasy SVG integration (design a SVG resource with two ID and $text and use if as button) : key feature to bring design
• enhanced HCIL event support (multitouch &amp; all) : I am already on this one ;-)
• full CSS support for styling using class and ID=command
• more default component for usual things : DateSelector where art thou ;)
• scene model
• animation engine

...

On the last points, I think lot can be "borrowed" to JavaFX ...

[JonathanGiles]

Auto-imported comment, original author: Kas Thomas Comment posted on: February 3, 2009

If we're starting from a clean sheet of paper, I'd want to see the class hierarchy flattened -- no deep inheritance chains. It should be vastly more compositional (interface-based). Why should I have to inherit hundreds of methods in order to have a menu? (JMenu has 433 methods at last count.)

Don't force me to subclass already-huge classes, or write wrapper classes, in order to do simple things. Give me some lighter weight alternatives to the big kludgy JMonsters. I don't need all 433 methods of JMenu and its ancestors.

If you're writing JavaScript, there is no way to subclass a JComponent and override a method in it (from a script), so those of us who use Rhino (or the embedded scripting features in Java 6) "in anger" are left no alternative but to ... feel angry.

It might be good to have Swing Lite and a Swing Heavy that wraps the Lite (?) -- but I still favor more compositionality and less inheritance as a motif for Swing.next.

Thanks! Great post. Great dialog.

[JonathanGiles]

Auto-imported comment, original author: Mike Reid Comment posted on: February 3, 2009

Swing is great but there is a lot of work required even to do simple things. Rather than start with all the complicated cases how about starting with simple things that people do in every application:

• display dates (without using an external library)
• display currency
• display images (much more simply than now)
• tables should have a default model that knows how to render simple objects put into it (date, text, boolean, dropdown, images etc). Then the default model could be used in most cases.

People avoid Swing not because it doesn't have enough power. They avoid it because it is too much work to do basic things (display an image requires understanding how painting works, instead it should be a single call on a component to place the image).

The problem with Swing is it was designed by very clever people in a hurry, which makes it slow for less clever people (think government or corporate developers) to develop things in a hurry. This is the real Achilles Heel of Swing as it is.

Swing 2.0 needs to be "As simple as possible, but no simpler".

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: February 3, 2009

@Mike Reid: Thanks for your comments. I think the problem with any API is that you need to know all of it to be a power user. Swing perhaps complicates this by having a huge API (due to inheritance). In the case of displaying images, you can always put them into a JLabel.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: February 3, 2009

To everyone commenting, thank you. Your support for the project, or your comments against the project, are all welcome and appreciated. We have succeeded in catching the attention of Sun - they should be getting a response back to us within the next day or two. I will post a new blog post then, and will post a comment into this post here so that anyone subscribing to comments is updated.

How Swing 2.0 continues next is a function of how Sun responds to our suggestion, so we must now wait until we hear from them. Despite this, please continue adding your suggestions to this blog post - it is certainly the best place to gather your thoughts on Swing 2.0 at this point in time!

Cheers!

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: February 3, 2009

@Gabriele Carcassi: I am trying my best to organise a Swing 2.0 :-). The only reason I have gone quiet is because I'm waiting to hear back from Sun. I would dearly love to get their feedback, and based on their comments so far, they may generally accept some, but not all, of the Swing 2.0 points in this blog. This is reasonable as this post has contradictory requests. I purposefully kept my initial post shortened to what I consider the minimum requirements for a Swing 2.0.

Perhaps instead of Sun accepting a need for Swing 2.0, they will possibly support a 'Swing 1.5' (Thanks to Rémy Rakic for that term) - in other words a more basic upgrade of Swing to support Java 1.5 features. This could be a good start.

Anyway, enough crystal ball gazing - I will update when I hear more.

[JonathanGiles]

Auto-imported comment, original author: Mike Reid Comment posted on: February 3, 2009

@Johnathan Kia Ora "I think the problem with any API is that you need to know all of it to be a power user."

That's not so bad. The problem is not with us power users, I believe is the fact that you have to know quite a lot of Swing's implementation details (EDT etc) to be able to do anything other than the simplest things.

Again, there's no default way to display things such as dates or currency that appear in a large proportion of applications. It is not that it is difficult to do, it is the fact that you have to do any work at all for these simple things that is a design flaw in the default set of Swing components. Building CRUD applications (that can display common SQL-derived data) is far, far more work than it needs or ought to be.

Fingers crossed Swing 2.0 makes a difference. Thanks for giving us a forum to air our ideas.

[JonathanGiles]

Auto-imported comment, original author: Lasse L Comment posted on: February 3, 2009

I think that a swing 2.0 should be a "pimped" edition of the swing that is built on the Scala language, extending Scala's unique language features.

http://www.scala-lang.org/

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: February 3, 2009

@Mike Reid: ah, looking at your email I see we have another Kiwi on the site :-) You may or may not recognise the images in the title banner on this site as Waiheke Island. Anywho, I digress.

You make good points. I push for a Swing 2.0 that enforces total EDT compliance. Like I said in my initial post, it will make developers unhappy until they learn the rules, but it makes the end result far better. It is worth it.

Additionally, there may be scope to improve the means of interacting with the EDT, but that is a discussion for another day.

[JonathanGiles]

Auto-imported comment, original author: ted stockwell Comment posted on: February 3, 2009

I would like the following in Swing 2.0....

...I would like to replace AWT with SWT.

...I would like an interface-based UI that uses a factory to create instances such that applications can plug into the factory to customize components. This enables me to use Swing API to develop most any kind of GUI, the specific implementation of UI toolkit can be customized by application.

...Removal of 'renderers' from API. Renderers prevent using Swing to develop thin-client UIs since the renderer concept does not translate well to client/server architecture.

[JonathanGiles]

Auto-imported comment, original author: Mike Reid Comment posted on: February 3, 2009

@ted stockwell

There is already an implementation of Swing on SWT, called SwingWT http://swingwt.sourceforge.net/

Incidentally, SWT works best on Windows and less well on other platforms (IMHO). It certainly has a lot of subtle inconsistencies between platforms (at least for the products I've built with SWT). In addition, SWT's internal implementation 'style' seems quite Windows-like and old-fashioned (eg. variable namimg) compared with the Swings - but as I said, this is just a style thing.

[JonathanGiles]

Auto-imported comment, original author: Greg Brown Comment posted on: February 3, 2009

Pivot does indeed address many of the issues raised in this thread. It was recently accepted for incubation by Apache, and the incubator proposal provides a good overview of the project:

http://wiki.apache.org/incubator/PivotProposal

Additional information, demos, and source code, are available on the project site:

http://pivot-toolkit.org

[JonathanGiles]

Auto-imported comment, original author: Greg Brown Comment posted on: February 3, 2009

Just wanted to share some specific examples of how we have addressed a number of these issues with Pivot:

• "Generics-based, support for enumerations where obvious" - Pivot requires Java 5 as a minimum, which allows us to take advantage of newer Java language features throughout the API.

• "Improved support for bean binding and validation" - Pivot's built-in data binding framework makes it very easy to bind bean classes to form elements.

• "Better handling of the validate/invalidate/revalidate/repaint mess. You should never have to call these as a developer." - Unless you are developing custom components, you will generally not even need to be aware of these methods as a Pivot developer.

• "Layered painting build in from the start." - Pivot's decorators serve exactly this purpose. See http://pivot-toolkit.org/demos/decorator.html.

• "Components should be able to paint outside its bounds." - Decorators are also used for this.

• "min/preferred/max sizes should be width/height and not size." - Pivot includes support for both constrained (i.e. width that varies by height or height that varies by width) and unconstrained preferred sizes (like Swing's current preferred size).

• "All Components shouldn’t be Containers." - Only components that actually make sense as containers are implemented as such in Pivot.

• "Better thought out listeners." - We think we've done a pretty good job partitioning events into meaningful listener interfaces in Pivot.

• "A single Window ancestor that is actually used in the API" - Pivot's Window class acts both as an undecorated window as well as the base class for other window classes such as Frame, Dialog, Popup, etc.

• "Adhere to the transparency of Colors. No isOpaque()/setOpaque(boolean) debacle." - Supported.

• "Oh, and SVG icons is a good idea" - Vector images aren't fully supported yet, but the API was designed for this. Both bitmap and vector images share a common base class so they can be used interchangeably.

• "Retained mode API - The desire for advanced effects and painting outside a component space needs a retained mode API to determines when parts of the screen need to be updated" - Decorators accomplish much of this.

• "Easier creation of models." - The same model interfaces are used by all data-driven components (lists, tables, and trees), and there are far fewer of them. We think this makes them much easier to work with.

• "Better layout managers. along with that a better API for interacting with layout managers." - Pivot containers and layout managers are not implemented as separate concepts - they are integrated. In our opinion, this approach is easier to work with, and is also the approach taken by Flex and Silverlight.

• "Real MVC design. Swing as it is now is only 'model-separated'" - Pivot components are defined by a model, a component, which acts as the controller, and a skin, which serves as the view.

• "pure Java2D default PLAF" - Pivot ships with a default cross-platform look and feel called "Terra".

• "more default component for usual things : DateSelector where art thou" - Pivot 1.1 includes a standalone calendar component as well as a drop-down calendar.

• "tables should have a default model that knows how to render simple objects put into it (date, text, boolean, dropdown, images etc)." - Supported. Pivot includes a cell renderer class called TableViewMultiCellRenderer that automatically renders cell content based on its type.

Throughout Pivot's development, we often talked about it as "Swing 2.0" - I'd suggest that anyone interested in the topic of "Swing 2.0" at least give it a look.

Again, there's more information on the project site and in the Apache proposal:

http://pivot-toolkit.org http://wiki.apache.org/incubator/PivotProposal

[JonathanGiles]

Auto-imported comment, original author: Gili Comment posted on: February 3, 2009

Yes we need Swing 2.0, but I would say we should go further and try to consolidate everything we've learned since Swing 1.0 while we're at it.

1) Widgets should address use-cases out-of-the-box without customization.

2) All forms of customization should be heavily documented and made as simple as possible. In my experience, Swing can do anything but no one knows how to implement it nor is it trivial to do so. I strongly believe we can do a better job the second time around.

3) One piece of advise: don't freeze the API too early. I would advise freezing API components only if they haven't changed for over 2-3 years. That should be enough time for the community to catch any design flaws.

[JonathanGiles]

Auto-imported comment, original author: DipX Comment posted on: February 3, 2009

swing 2.0 :

Painter,Timing Framework++(Project Scene Graph),JSR295,JSR296(need more simple),Powerful-LayoutManager(MigLayout,JGoodies-FormLayout...etc)

does anyone have other idea?

[JonathanGiles]

Auto-imported comment, original author: Matt Nathan Comment posted on: February 4, 2009

re painters: While I think the idea of painters is awesome (being able to replace specific parts of the painting code with your own implementation without going through the LnF hacking stage would be great) I do think that the current incarnation of them (in SwingX at least) could do with some work. For example a painter has no intrinsic size, this leads to separation of logic (in the bad way), for example in a TextPainter that is used to paint a label how does the label know what size the text is going to be so that it can decide on it's preferred size.

On a related note one of the features that I would quite like to see re-thought in swing is the minimum/maximum size properties. These APIs, while having the best of intentions, could be accomplished using a single API that also provides much more flexibility for a component to define how it should be re-sized.

For example I've been experimenting with something similar and found that an API like public Dimension fitInto(int width, int height) allows for much more flexibility (for example you can define a component that maintains it's aspect ratio, or only stretches in the vertical axis or has a maximum width or any combination) with a single api method. A similar API for painters (and scalable icons where I currently use it) could also be used.

[JonathanGiles]

Auto-imported comment, original author: gregor Comment posted on: February 4, 2009

Miglayout? Ha!

All we need is to start requiring Java programmers to instantiate objects with arguments like this: "[10][20:30:40][40!][::40]" (typical argument gleaned from the Miglayout guide in a few seconds).

[JonathanGiles]

Auto-imported comment, original author: evildeathmath Comment posted on: February 4, 2009

+1 to better EDT enforcement. +1 (and then some) to support for generics, and ditching Vector in every dang constructor.

-400 to the suggestion to remove renderers. . . DO NOT DO THIS!!! The capability to completely customize the appearance of complex components such as tables is one of the major reasons I currently choose to do GUI development in Swing; reducing the power of the toolkit isn't the way to improve it.

Don't think language-level properties should be required; the .NET implementation, at least, tends to make it extremely hard to determine what will and won't automagically update; I'd rather have to explicitly call a method (or something) so that I know I'm updating a property and triggering changes elsewhere.

Having a good TreeTable or other multi-column tree implementation built into the toolkit would be really, really nice.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: February 4, 2009

@gregor: You're welcome to continue using current layout managers. I in fact have never used MigLayout (sorry Mikael!) - but I have used a similar framework heavily (JGoodies Forms). The question as to handling layout managers is a complex one - I understand their use, but I don't know of a better way to handle laying out components if layout managers were to be wiped out of Swing tomorrow. Thoughts?

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: February 4, 2009

@gregor

A bit short sighted, maybe peek a few more seconds. I usually use one of the other syntaxes that MigLayout supports;

add(xxx, new CC().spanX(2).fillX())

[JonathanGiles]

Auto-imported comment, original author: Abraxis Comment posted on: February 4, 2009

Regarding EDT (again) - just an idea for brainstorming: Is there any reason why NOT to wrap every "setter" (.setText, .add - etc.) by something like this?

if (!isEDT()) { Swing2Utilities.invokeThisAndWait(this.thisMethod); }

Then Swing2 API would be "non-EDT" and inside we could keep using EDT or anything else in future.

[JonathanGiles]

Auto-imported comment, original author: gregor Comment posted on: February 4, 2009

@tbee

add(xxx, new CC().spanX(2).fillX())

is not much of a improvement over

“[10][20:30:40][40!][::40]".

Look, I don't want to bang on one Layout Manager or the other. The point is that if so many Layout Managers have been developed because those bundled with JDK suck, and even the new ones suffer from the need for such cryptic commands, perhaps some new thinking is required.

I think Java Sun people basically know this. As late as 1.5 they had to come up with a new Layout Manager, and they gave us the Group Layout Manager. The earlier versions of JFX had used Group Layout, but finally as far as I understand they have given up on it.

Imagine that JDK required you to specify your own hash functions for different type of objects, and the JDK came with a sucky hash functions that work only with Integers and Doubles.

The situation is similar with the concept of Layout Managers. They may be necessary evils, but a higher level abstraction is needed for the programmers who just want to show a nice looking table of components for example.

[JonathanGiles]

Auto-imported comment, original author: Alex Ruiz Comment posted on: February 4, 2009

@Abraxis:

Nope, that would kill performance. It is better to consolidate as many actions as possible in one call to the EDT.

Cheers, -Alex

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: February 4, 2009

@Abraxis: Alex is correct - you have to remember each time you put something onto the EDT you are creating a new Runnable, so performance would be killed by do each setter individually. It's a nice idea, I have done similar in the past, but not at the level of setters - rather when I know a method should be called on the EDT but it may not - but I bunched together all EDT-relevant operations into that method so as to not kill performance.

[JonathanGiles]

Auto-imported comment, original author: Jemsquash Comment posted on: February 4, 2009

I stumbled upon this discussion per chance. I think it's an excellent idea and I agree with the majority of what's been said. A cleaner simpler API would solve a lot of problems when developing gui applications in Java.

I am a bit surprised that very little has been mentioned about unit testing though. I'd personally like to see a framework or an ability to unit test my gui code. I'm currently using FEST which has become an indispensable tool to me. It however has a lot of shortcomings, most notably that the swing components are actually visible and the mouse cursor is controlled by the unit tests while they run. This leads to slow tests and also renders the computer unusable while the tests run.

Wicket is an excellent example of where a good simple (to use anyway) unit test framework improves the developers life in testing. A web server is not required to be running like so many other web frameworks.

In a similar approach I'd like to see some sort of test container that mimics the OS gui and the unit test in effect does not need visible components or the user of the physical mouse cursor.

That's my 2 cents worth anyway. Nothing quite like dumping ideas on others that haven't been thought through thoroughly.

[JonathanGiles]

Auto-imported comment, original author: Alex Ruiz Comment posted on: February 4, 2009

@Jemsquash,

I'm pleased to hear that FEST has become an indispensable tool to you. I'm also interested in known the shortcomings you have found (besides the mouse-controlling behavior.) Would it be possible to talk about this in private or in the FEST mailing list? I'm always looking for ways to improve the project. Thanks :)

@Jonathan,

I apologize for talking about FEST stuff, not related to your post :D

Cheers, -Alex

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: February 4, 2009

@Alex Ruiz: No problem - I'm glad testing has come up, as it was always something I imagined should be researched leading into a Swing 2.0, and if desirable, be made part of the scope. I'm sure an API designed with testing in mind would be nice for some developer. For that reason, it is great to have you monitoring this discussion Alex :-)

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: February 4, 2009

@Jemsquash

I did that in my application a few years back, as the solution to the EDT problem, even considered using AspectJ to do that for everything javax.swing.

However I ran into unexpected behavior, can't remember what exactly. Then I switched to using invoke later, again unexpected behavior (setText had not set the text - yet). Did manager to fix that with a second variable holding the value, but ended up installing the EDT checker and really resolving the issue.

All this may very well have happened because of other faults in my code, so the solution may work. As said; AspectJ can solve a boat load at once.

[JonathanGiles]

Auto-imported comment, original author: Abraxis Comment posted on: February 5, 2009

@Jonathan: yes, there would be some overhead but my point is that this overhead mostly already exists! Lot (most?) of Swing developers is already using "invoke*" or have to bypass it somehow (send "messages" to EDT).

So why not just make our daily development easier? And if creating new Runnable shows to be the bottleneck (which I don't think so - just a feeling, no hard data!) then we can change Swing 2.0 internals to be more effective - while still keeeping API!

[JonathanGiles]

Auto-imported comment, original author: Alex Ruiz Comment posted on: February 5, 2009

@Abraxis,

I tried something similar to what you suggested (EDT access in setters) and performance was horrible. Once we consolidated many actions in a single call (or Runnable) in the EDT, performance was not only great, it was faster than not using the EDT at all.

My point is that using Runnables in the EDT do not imply performance penalties if we use them correctly.

-Alex

[JonathanGiles]

Auto-imported comment, original author: Alex Ruiz Comment posted on: February 5, 2009

@Abraxis,

I re-read your last comment. If the overhead you talked about is the overhead for the developer to deal with a cumbersome API, yes! I agree with you. Simplifying EDT access (API-wise) is a tough problem to solve, IMHO, and without closures in the Java language even tougher (my intention is not to discuss if Java should have closures or not.)

-Alex

[JonathanGiles]

Auto-imported comment, original author: Abraxis Comment posted on: February 5, 2009

@Alex Ruiz: EXACTLY - "using Runnables... correctly". Let's face it - there are many developers who just does not care about anything else then if the code compiles and does +- what it should :-)

Can't we somehow make Swing more intelligent so you don't have to think about EDT? Just an idea without too many deep thinking - if bundling more changes into one EDT call dramatically improves performance, then why not let Swing to have "change queue", put required changes in this queue and once a while (100ms) process whole queue? (of course it's very rough idea, implementation would have to very different ;-))

Again - my main point is to allow developers to call label.setText("Hello") from any thread.

[JonathanGiles]

Auto-imported comment, original author: Tom Corbin Comment posted on: February 5, 2009

@CurtCox

That was exactly what I was thinking about, only half remembering.

It's a very interesting project, though I doubt any one else would use it. It looks very powerful, though.

I'm betting sun won't help - I don't think they have the manpower or interest. In fact, I'm guessing they'll want to discourage this work by making it hard to keep up with swing1.0 improvements.

But I guess we can only wait and see.

My preferred way of handling Swing 2.0 is to start with Swing 1.0 and start doing refactoring. I think we'll get the most bang for the buck and while we wouldn't be 100% backwards compatible, we'd maintain the most backwards compatibility this way and lower the learning curve.

I do have to admit that Pivot (and others) sound great, I'd rather incorporate their ideas into a swing 1.0 refactoring.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: February 5, 2009

Just an update: Danny has posted his thoughts on Swing 2.0 on his blog here: <a href="http://blogs.sun.com/theplanetarium/&quot; rel="nofollow">http://blogs.sun.com/theplanetarium/&lt;/a&gt;

It's pretty much as expected - they need to be conservative so an incompatible Swing 2.0 is not something they can do. They do encourage other people to do a Swing 2.0 externally however, given that all source code is available.

What are your thoughts?

[JonathanGiles]

Auto-imported comment, original author: Dan Howard Comment posted on: February 5, 2009

I haven't read all this thread yet but I just thought of something that might make this thread keep going MUCH longer. :)

For swing2 why not drop the layout managers and follow the MS way of using containers with relative layout.

I would love that - I could never get my head around layout managers.

[JonathanGiles]

Auto-imported comment, original author: Gili Comment posted on: February 5, 2009

Not to be an ass, but this conversation sounds more and more like it's being run by a bunch of amateurs. A few of the suggestions that have been made make little sense yet no one called them on it. I also get the feeling that there isn't a single senior API designer here.

Yes, we need Swing 2.0, but there is little sense working on it without some very senior developers leading this effort. Good luck nonetheless!