we need Swing 2.0 which is not JavaFX-base -

I believe that there is a need for a proper Swing 2.0 which is not JavaFX-based, but a true, desktop focused, Java (the language)-based framework. My vision is one shared by numerous others, and in a brief discussion (via twitter no-less), a number of us enumerated what we believe a Swing 2.0 needs. The following list is a brief overview of what Swing 2.0 should be:

Generics-based. No more should we put our objects into various Swing data models and components only to receive Object back. It should be possible to create swing data models and components with the data type specified. There is work in this direction already with the Swing-generics project, although progress is slow. Swing 2.0 should include this project instead of duplicating work.
Support for enumerations where obvious. There are numerous places where public static final ints could be replaced by enumerations. This leads to a cleaner API.
Support for varargs. Once again, there are places where varargs could be used to clean the API.
Improved support for collection frameworks. That is, we should not still be requiring Vector lists, unless syncrhronization is absolutely necessary.
Stricter enforcement of event dispatch thread (EDT) rules. Swing is slow (or so the saying goes). This is untrue, but is unfortunately the perception. This perception exists because developers don’t understand how to deal with the EDT. There exists code out there now that can enforce the rules surrounding the EDT by essentially throwing exceptions when components are handled off of the EDT, and when tasks take too long that should not be run on the EDT. By default, Swing 2.0 would enforce EDT checking, throwing all exceptions discovered. This may make developers unhappy, but the end result is better programs and happier users. It is worth it.
Improved support for bean binding and validation. I won’t go so far as to say we need properties, largely because I don’t know enough to have an informed opinion, and I know that by saying we need properties Swing 2.0 instantly becomes far less possible without major Java language updates. But, I know that projects such as the JGoodies beans binding and validation tools are very useful, and make creating data-driven user interfaces far easier and rapid. It may make sense to incorporate these kinds of frameworks into Swing 2.0 to enable users to focus on the business logic, and not getting data to and from the user.

What you may note is missing is any mention of new components, new Look and Feels, etc. That is not my interest – in my opinion Swing 2.0 is a cleanup of the code beneath the existing Swing components. It would be ideal if Swing 2.0 could be API compatible with Swing 1.0, but I would not be adverse to Swing 2.0 becoming a separate Swing library in its own package (i.e. javax.swing2). This would allow for API cleanups, and repurposing of existing API method names.

What do you think? Do we need a Swing 2.0 that has the roughly the above features (make any suggestions you have). Is it too little too late for desktop Java (personally I think not, obviously)? Please, leave any comments or thoughts that you may have – let’s get the discussion started.

------------------------------------------------

讨论很有价值

Roger Padilla

January 26, 2009 at 2:25 pm

I like Swing, but now I’m starting to love JavaFX. JavaFX is not Swing 2.0, but you can see it as Swing 5.0 :)

Regards

Jonathan

January 26, 2009 at 3:04 pm

You must be from the Winamp school of versioning :-)

I’m not a JavaFX person yet, simply because my day job is fully Swing, and it will be for the foreseeable future. For this reason, Swing 2.0 is what I need, not JavaFX.

I think it is very important not to confuse the general population into thinking JavaFX is Swing 2.0 – because it isn’t, and for that matter, shouldn’t try to be.

Cheers,

Jonathan

Ash

January 26, 2009 at 7:01 pm

Absolutely. I hope some of your ideas become reality. Especially your demands on generics, ease and clearness of thread use and property binding would make it a wonderful standard framework available at zillions of java installations.

Jonathan

January 26, 2009 at 7:17 pm

Thanks Ash. Hopefully we might get some momentum behind a Swing 2.0 vision, and perhaps something may come from it. But of course, before that, we need a good discussion about what Swing 2.0 means to everyone out there (and anyone that says Swing 2.0 == JavaFX instantly gets blacklisted :P )

Somatik

January 26, 2009 at 7:26 pm

+1 for swing 2.0

Kenneth

January 26, 2009 at 7:41 pm

I also support Swing 2.0 idea and more importantly the fact that JavaFX is NOT Swing 2.0.

People use ( and love ) to make this confusion and IMHO Sun helps a lot making such misunderstanding.

Jonathan

January 26, 2009 at 7:46 pm

As I’ve said numerous times before, Sun would do well to employ a person or two whose job was to ensure consistency and clarity of message. Java versioning can be confusing (i.e. 1.5 vs 5, etc), the role of JavaFX and Swing (is JavaFX a Swing 2.0? is it for internet sites and/or for desktop applications? etc) is unclear, and there needs to be someone who either has the answers, or is the person who can give the definitive answers (after seeking from the relevant internal people). This is a role for someone able to talk to the community as well as talk to the technical people inside Sun.

Anyway, back onto subject. Thanks to Somatik and Kenneth for your messages. It’s great to see the comments coming through. Do you have any suggestions on what you’d want Swing 2.0 to be, or do you pretty much agree with what I outlined in the post?

Cheers,

Jonathan

Mikael Grev

January 26, 2009 at 7:55 pm

Hello Jonathan,

The things you mention is good to have for sure, but it doesn’t do that much for making Swing simpler to use, not counting binding and validation.

Here’s a few additions that trip developers and make then spend hours trying and trying again:

* Better handling of scroll panes. Components that should scroll should extend a scrollable component. This makes it easier to handle in its API. Of course a generic JScrollPane that you can wrap with should be there.

* Better layout manager(s) (It just happens I know a good choice ;)

* Better handling of the validate/invalidate/revalidate/repaint mess. You should never have to call these as a developer, it should happen automagically.

* Layered painting build in from the start. That way you don’t ave to sub class to customize. Layers should be able to handle events too so that you for instance can add a “disabled” layer over a specific component.

* Components should be able to paint outside its bounds. This is so you can for instance add a drop shadow layer without having to change the bounds of the component.

* min/preferred/max sizes should be width/height and not size. And they should take the size in the “other” dimension as an optional parameter, just like SWT. This is very important since it makes the job of the layout manager so much easier. No more wrapping problems in TextComponents.

* Real properties. JGoodies’ binding is great but it lacks refactor survivability. We NEED real properties. I’m not talking simple replacement for getters and setters.

* All value classes such as Point, Dimension, Rectangle etc. should be immutable.

* I know there is more… Much more..

And finally. Saying that JavaFX is Swing x.0 is like saying that MFC was win64… ;) That doesn’t take anything out of JavaFX though, it’s just a different beast.

Cheers,

Mikael Grev

Tbee

January 26, 2009 at 8:17 pm

Swing 2.0; I just realized I’m kinda building it myself. Already have the JTextField extention with generics (JFormattedTextfield alternative). And varargs for constructing the horizontal panels and the like. So yes, we do need Swing 2.0. And the points you make here are to be included.

However, I already have the EDT checker in my swing projects. I already use JGoodies binding. I’m already using generics and varargs. So these are no brainers to include; that could/should be done in the application framework.

Personally my problem is more with the components itself; they are complex to use for anyone not very skilled in Swing. One needs to add listeners to all kind of “weird” models (SelectionModel, ListModel, etc). And the events being fired are not practical for binding, so there are all kind of “yes-but” things when trying to bind.

So IMHO we indeed need a Swing2.0, but as a fresh library with well thought through components, written with the coder actually using it in mind. MVC is great, but should be an implementation detail, there when you need it, but not fully exposed. Swing core is just fine.

Paul Loveridge

January 26, 2009 at 8:18 pm

Swing 2.0 is a great idea, especially when sun continues to try and tie javafx development to netbeans ( a persistent bee in my bonnet ).

Is there and easy way we can get this started ? A java.net project perhaps ? It also strikes me that the earliest versions could simply wrap over the top of the existing swing classes ?

You’d need a better name than swing 2.0 for packaging – perhaps one of thesaurus.com’s synonyms ? I’d go for javax.rock simply because it would.

Mikael Grev

January 26, 2009 at 8:24 pm

OK, I remember a few more..

* All Components shouldn’t be Containers. There is no reason a button should be able to hold other components. Especially since layers are there. SWT and .NET got this right.. Basically this means fixing the hierarchy that was complicated when Swing extended AWT back in the days.

* All listeners should be single method interfaces so they would work well with CICE (or BGGA). You should switch on the type. That would mean easier extensions when new type becomes available.

* Better thought out listeners. Now there’s a zillion different listeners and many of them overlap in concept.

* JavaBeans 2.0. This is almost as important as Swing 2.0. It would mean super great handling in IDEs and much easier to write components that would work in all IDEs.

* A single Window ancestor that is actually used in the API (Frame vs Dialog vs JFrame vs JDialog vs Applet vs JApplet vs Window problem).

* Much better handling of Z-order of both components and top level windows. For instance you can’t today change/control the Z-order of top level windows except by making a Window a sub-window to another window.

* Using Paint instead of Color everywhere. Return Graphics2D (or a new one with the old obsolete methods removed. Java2D is great but some of the classes use old and dated API).

* Adhere to the transparency of Colors. Setting the background to new Color(x, y, x, 128) would make the component’s background transparent without artifacts. No isOpaque()/setOpaque(boolean) debacle.

I don’t promise there won’t be more… :)

Cheers,

Mikael Grev

Jonathan

January 26, 2009 at 8:31 pm

Dang, I had a long response to everyone get lost….ok, brief response time:

@Michael: Couldn’t agree more with almost all of your thoughts. The only reason I don’t push for properties is the requirement to change the language, which is obviously a rather large hurdle when all I’m pushing for at the moment is a better Swing API. Regardless, thanks very much for all your input – these are all so important to get right, so I much appreciate your thought – keep the ideas rolling in.

@Tbee: That’s really the whole point I guess – what’s the point in everyone having their own ‘Swing 2.0′ when a collective, agreed upon release could be so much better. I tend to think the current event model in Swing is very good, but there is scope to look out for overlapping event listeners and to overall clean out the API.

@Paul Loveridge: I think we don’t move much further than discussing on this blog now. Perhaps in the next day or two we can entertain this idea, but there is no point racing into things yet. I would really love to get a proper discussion rolling with Sun about the topics discussed in this blog post before we jump headfirst into a very big project!

Overall, thanks to everyone giving thought to this problem. Only through your comments and ideas can a Swing 2.0 ever become realistic. Ideally we’d get our voice heard within Sun, and maybe some thoughts from their way. Lets hope so, for the sake of Swing.

Christophe

January 26, 2009 at 9:00 pm

painters ?

Jonathan

January 26, 2009 at 9:01 pm

@Christophe Painters would need discussing – I only know a little about them in the context of SwingX, but not enough to say yes or no absolutely (in my opinion). What do you think – are they something that should absolutely be part of Swing 2.0, or are they a sideline feature?

Thierry Lefort

January 26, 2009 at 9:04 pm

Should Swing 2.0 break the backward compatibility with Swing?

Don’t start with what feature you would want to add. This is the central debate.

Swing 2.0 should improve the components API, there are too many features missing in the current API especially in the JTable, you just have to check the hacks needed to build the SwingX JXTable to make the highlighting and filtering work to be sure of that.

So the real question should not be shall Swing 2.0 be done inside or outside JavaFX. The real question is do you think Swing 2.0 should break the backward compatibility.

If yes then JavaFX is a place where it can be done, if not then you are stuck with the current API and the features that can be added won’t answer your need.

Mikael Grev

January 26, 2009 at 9:13 pm

Painters are used as layers in a component. It’s like a super super light component that is basically just a paint() method (and possibly a processEvent(Event e) method). They are used to paint components. For instance a Button might consist of a backgroundPainter that paints the background. A contentPainter that paints the actual button look. A foregroundButton that paints the text. This way you can for instance easily wrap the text and make it blurry and have this work with all Look&Feels.

It makes it less probably that you need to subclass a component to change the look and even if sub class it you can’t make the text blurry in Swing.

Also, it’s easy to add ornaments like a validation red cross over a text field if validation deems the content invalid.

Simply put they increase the flexibility and plays nice with Look&Feels.

It should be noted that Painters will never be very good in Swing 1.0 since it wasn’t build with those in mind from the get go.

Another area they would excel is as Rendereds in Lists, Tables and ComboBoxes. Now a Component is used in Swing, with the tricks and problems associated with that. For instance, in Swing, if you don’t override a couple of methods in the CellRenderer’s returned component to do nothing, your JTables will be slow as heck.

Cheers,

Mikael

Aekold Helbrass

January 26, 2009 at 9:15 pm

As for me the first task is to create package javax.swing2 and implement all “up-to-date” features of Swing without maintaining compatibility of all that dead code inside. It will make possible faster extension and maintainance of Swing. Of course all great ideas of current Swing should be ported to new Swing.

Second, one of the most interesting features as for me – Swing is very advanced, it makes customisation simplier for you. And suggestion for throwing exception is not an option – sometimes I am writing special thread-safe components and use them instead of plain components because of al

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论