posts/2009/swing-20/index

[JonathanGiles]

Java Swing 2.0

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

[JonathanGiles]

Auto-imported comment, original author: Roger Padilla Comment posted on: January 26, 2009

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

[JonathanGiles]

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

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

[JonathanGiles]

Auto-imported comment, original author: Ash Comment posted on: January 26, 2009

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.

[JonathanGiles]

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

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 )

[JonathanGiles]

Auto-imported comment, original author: Somatik Comment posted on: January 26, 2009

+1 for swing 2.0

[JonathanGiles]

Auto-imported comment, original author: Kenneth Comment posted on: January 26, 2009

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.

[JonathanGiles]

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

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

[JonathanGiles]

Auto-imported comment, original author: Mikael Grev Comment posted on: January 26, 2009

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

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: January 26, 2009

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.

[JonathanGiles]

Auto-imported comment, original author: Paul Loveridge Comment posted on: January 26, 2009

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.

[JonathanGiles]

Auto-imported comment, original author: Mikael Grev Comment posted on: January 26, 2009

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

[JonathanGiles]

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

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.

[JonathanGiles]

Auto-imported comment, original author: Christophe Comment posted on: January 26, 2009

painters ?

[JonathanGiles]

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

@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?

[JonathanGiles]

Auto-imported comment, original author: Thierry Lefort Comment posted on: January 26, 2009

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.

[JonathanGiles]

Auto-imported comment, original author: Mikael Grev Comment posted on: January 26, 2009

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

[JonathanGiles]

Auto-imported comment, original author: Aekold Helbrass Comment posted on: January 26, 2009

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 all this SwingUtilities.invokeLater(new Runnable() {public void run() {value++;}}); As for me GUI builders should be smarted, so people who are using them really should not care about EDT rule, while if I want smart component - this new politics will always assume I am as lame as all that guys from SQLDeveloper (for example) and will require more work to remake the component to let me violate this rule in my way. There should be better solution, which will be suitable for both advanced and simple guys, or just some startup swing politics or second level of components, like javax.swing2.advanced. And of course, throwing exception from components aboud EDT violation will break any compatibility with old swing. And of course binding is third, but it should not be some "few hours implementation" but should use some advanced architecture, to be the best possible solution ever but not a subject of change in every next version. As for me generics, enums, varargs and collections are not something that will make your life as swing developer better. Of course with current interpretation of EDT rule ArrayList should be much faster than Vector, but it should be subject for discussion after first parts will be implemented.

[JonathanGiles]

Auto-imported comment, original author: Dimitris Menounos Comment posted on: January 26, 2009

javax.swing2 great idea! Standard java distribution needs yet-another gui toolkit to raise the bloatness bar to an ever higher level. I dissagree with the no-new look and feels proposal though. Every new java gui toolkit deserves to have its shiny new ugly look - we shouldn't break the tradition. In addition I think that properties (and closures) are desperately needed to finish the good job generics did improving the language.

It would also be beneficial to business. More bloat means more hardware and language changes means more books and training, and api changes means more application rewrites.

Let the momentum grow!

[JonathanGiles]

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

@Thierry Lefort: I'm a little confused by what you're trying to say. My argument for Swing 2.0 has nothing to do with JavaFX, and to be fair I wouldn't want to go anywhere near it as it is irrelevant to the discussion (I believe).

@Michael: Sounds like Painters should be central to a Swing 2.0 then.

@Aekold Helbrass: To clarify EDT verification and exception handling, I would suggest that any exceptions be (unchecked) runtime exceptions that clog the log, but not necessarily exit the application.

I disagree regarding generics, varargs, and enums not being something that will make your life as a Swing developer easier. If that is the case, I suggest you aren't using Swing enough :)

Also, to clarify, I would assume that Swing 2.0 would start with all of the Swing 1.0 codebase intact, probably building above the Swing-Generics codebase.

Regardless of whether you agree or disagree with me, thank you for the comments. I am no gatekeeper to Swing 2.0, I am simply trying to spur on discussion so that we can ascertain what is and isn't priority for a new Swing version. Please don't take me disagreeing with you as a sign that you are wrong!

[JonathanGiles]

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

@Dimitris Menounos: I get the distinct feeling that you disapprove of Swing 2.0. You do realise that the standard java distribution has currently only two GUI toolkits: AWT which is largely unused externally, but which builds the foundation for Swing. So in other words, you're complaining because Java has one proper GUI toolkit?

I'm not looking for a religious debate about closures, properties, and whether generics were implemented correctly. I'm far too pragmatic for that. You may be surprised to understand also that just by including a new GUI toolkit there is no requirement for a business to buy new hardware or rewrite their applications in it. Of course, they may want to, but I would suggest a Swing 2.0 application is written from the ground-up as a Swing 2.0 application.

Please grow up, and return here when you have a positive attitude and something to say. You could have objected to this discussion in a far more adult manner. As it stands you come across as an idiot. I assume you're better than that.

[JonathanGiles]

Auto-imported comment, original author: Chipu Comment posted on: January 26, 2009

I also support an incompatible swing 2.0, there is too much legacy code that makes newbies (and also some more experienced people) cry.

I would support the idea of allowing svg for icons (and skins if possible), so we can have a single icon for any size

[JonathanGiles]

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

@Chipu: Thanks for the comment. The suggestion regarding SVG icons is a great idea. You must be related to Kirill :P Kirill Grouchnikov has done a lot of work in this area, so a Swing 2.0 could potentially incorporate this work to support SVG icon rendering.

[JonathanGiles]

Auto-imported comment, original author: Mikael Grev Comment posted on: January 26, 2009

Chipu,

Icon should be a Painter IMO. And for sure, there will be an SvgPainter as well as an ImagePainter. In this regard the Icon interface in Swing 1.0 is pretty good except it API wise seem to have a mandatory rather than an 'optimal' size.

[JonathanGiles]

Auto-imported comment, original author: Olivier Allouch Comment posted on: January 26, 2009

I agree with all you said, Mikael (specially with the break of backward compatibility), but I think Thierry Lefort nailed the heart of the problem. The real issue is the API. That API must be designed with use-cases in mind. What do people want to do with a Table, with a List... ? What I'd love is to see a very light class hierarchy (like Flash has) and a lot of composition. Remember Amy Fowler's JNxxx component in the JDNC project ? I think it was a great idea. I say let's wait and see the new JavaFX components. Maybe we will be able to use/wrap/port them to Java.

Then let's hope properties will come in Java 8. Until then, the modularity is coming, which may solve our backward compatibility problem.

[JonathanGiles]

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

@Mikael Grev: I agree, Icon makes sense as a Painter.

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: January 26, 2009

Let's not overrun ourselves by trying to make the egg-laying-wool-milk-pig (a German invention - and no, I'm not German).

With all the changes that people are suggestings, one could very well be starting a project that will never produce anything useful. Just see the amount of time and effort that Kirill has to put into maintaining (basically) one component.

IMHO we should focus on Swing 2.0, and only that, so no real properties in Java.

Secondly IMHO it needs to be a rework of the components, but not the engine. So one should extend Swing JComponent but take it from there.

And there is no reason not to consider putting Swing 2.0 in JavaFX. If there interface between is good (which ATM it isn't), then that is a valid approach. One may disregard it after consideration, but not before hand.

Oh, and SVG icons is a good idea ;-)

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: January 26, 2009

About painters... How does that mix-'n-match with Look and feels? You still want to be able to have a way to buy a skin, so painters should not conflict with skins.

[JonathanGiles]

Auto-imported comment, original author: Dimitris Menounos Comment posted on: January 26, 2009

I am an idiot because I've added a touch of sarcasm to the discussion?

[JonathanGiles]

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

@Tbee: I agree that we keep it simple to start with. But as with any project, it is best to think twice, code once. What I mean is that whilst there is no code lets talk about what we would love to have in a Swing 2.0. Of course, everyone throwing ideas in is going to result in a scarily long list of things to do, but that's assuming we are by default doing everything, which of course we aren't.

The end result of a discussion is a huge list. Following this we need to prioritise and work out interrelationships between the items on the list. We pick out the 'easy kills' and the more difficult tasks.

I also tend to agree that Swing 2.0 builds on top of Swing 1.0, in the sense that we start by taking all Swing code, and building and refactoring from there. I would love to hear more thought from people regarding this.

I take your comment regarding JavaFX to hand, but with me being completely lacking in any understanding of JavaFX, it is easier for me to dismiss immediately :P Seriously though, if you think there is a possible link, then it has now been recorded in this discussion, so it will be considered more seriously in the coming days should Swing 2.0 go anywhere past this one post.

Cheers!

[JonathanGiles]

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

@Dimitris Menounos: Sarcasm does not translate well over the internet if you don't make it clear with emoticons or equivalent. So yes, you are either an idiot for stating what you did, or an idiot for not making your sarcasm clearer.

Please feel free to come back to the discussion if you have a proper opinion (I would love to know your thoughts in a clear, more objective manner)!

[JonathanGiles]

Auto-imported comment, original author: Aekold Comment posted on: January 26, 2009

I am almost agree about codebase for swing2 to be swing1. But It will not be good to do big copy-paste of code, it will be hard to find and clean all old code that is left for compatibility reasons. May be it will be much better at first just to wrap currently existing components and then to implement it all step by step, until only some core Swing1 parts will left.

Another question, you said about generics and varargs, but how will it help you? You are right, I am not working with Swing all day long, but I am fan of Swing and I am using it almost all my free time for my opensource projects. And I can feel differenct leaks in Swing, but I can never feel the leak of generics or varargs or enums... And of course i am interested in how are you using it and how can it help you?

[JonathanGiles]

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

@Aekold: Thanks for the comment. I do not know the best way to start with a Swing 2.0. I am certain that Swing contains a lot of useful code, and is sturdy having stood the test of time. I for no reason advocate throwing that away and starting Swing 2.0 from scratch. At the same time, I do not know how best to start a Swing 2.0.

My inclination is to take Swing 1.0 and slowly refactor it to meet the needs of Swing 2.0. This will require discussion and an understanding of use cases. But it also means that we are trimming the hedges rather than planting the trees, which is far easier, quicker, and more likely to succeed. I would note that the general feedback is to not care about backwards compatibility, which will certainly accelerate the development of Swing 2.0 if it is built atop Swing 1.0. If you disagree please let me know on your preferred approach to a Swing 2.0.

There are numerous examples in Swing where generics will be beneficial. For example, in comboxes you can ask to getSelectedItem(), etc, and because the component does not support generics, it returns an Object, rather than the type of the object that could be specified in a generic argument.

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: January 26, 2009

@Jonathan It's not about starting simple; all the stuff that could go into Swing 2 is complex enough. It's about scope; it's about Swing 2.0, not "properties in Java" or closures.

[JonathanGiles]

Auto-imported comment, original author: Thierry Lefort Comment posted on: January 26, 2009

The starting point must be the API not the swing legacy code. If your keeping the Swing 1.0 API then your stuck with the backward compatibility problems it has.

If you're re-thinking the API then you have to start by asking yourself who will be using it and how they will use it. So do you only want the Swing 1.0 developer to use it? Or do you want to broaden your audience?

Wait a minute ... doesn't it looks like exactly to what Sun is doing with JavaFX?

[JonathanGiles]

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

@Tbee: Absolutely agree about scope, you cleared that up perfectly. You'll note my initial post said the same thing about it not being about properties or closures. Swing 2.0 is not about healing the Java world, it's about patching up Swing to be more closely aligned to the needs of desktop Java developers. We need clarity of scope, and hopefully this discussion thread is a step in the right direction.

Lets keep this discussion going, and see what other people have to say. In a day or two I'll make another post to clarify the discussion and try to boil down the comments.

[JonathanGiles]

Auto-imported comment, original author: Mikael Grev Comment posted on: January 26, 2009

> Wait a minute … doesn’t it looks like exactly to what Sun is doing with JavaFX?

Except JavaFX isn't Java...

I'd say start from scratch. It won't be backwards compatible anyway. At least not in the sense that one can use them interchangeably. On the other hand Swing 2.0 (called SwingIT!) should be very very familiar to current Swing developers. When modularity comes SwingIT can just be used instead of Swing 1.0 for new projects.

[JonathanGiles]

Auto-imported comment, original author: CodeRight Comment posted on: January 26, 2009

What you are looking for is already here:

Jazz Desktop Application Framework http://jazz.coderight.nl

[JonathanGiles]

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

@Thierry Lefort: You make good points, and I do not have many of the answers. I hope others can fill in the blanks.

All I know is that Swing, as it currently stands, is pretty damn good. What it's missing is a cleaner and more powerful API. I do not want to program in JavaFX, the language does not appeal to me at this point. I also have lots of Swing code that I would love to see being moved to Swing 2.0, to gain the benefit of as many of the features discussed above.

Therefore, the big question that needs clarifying I believe is how does a project like Swing 2.0 start: Do we build it atop of a potentially broken Swing 1.0, or do we build it from some form of scratch? There are benefits and pitfalls to both sides.

At the end of the day, I want to be programming Swing. In my opinion, Swing 2.0 should attempt to be as backwards compatible with Swing 1.0 as possible, because the last thing anyone needs is another API to learn..

That is my opinion, please discuss and disagree. Unfortunately for me I really need to call it a night, so I'm off for now. I will open up the blog so that comments do not need authorisation so that newcomers to the blog can post straight away.

Cheers.

[JonathanGiles]

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

@Mikael Grev: I agree with your statement: Swing 2.0 should be a GUI language familiar to Swing developers. That is my primary endgoal.

Starting from scratch seems to be the prevailing sense of direction. The question then becomes how can we accelerate the development so that Swing 2.0 is a huge, huge project? Can we make use of what already exists in Swing to accelerate areas that possibly don't need as much focus?

[JonathanGiles]

Auto-imported comment, original author: Aekold Comment posted on: January 26, 2009

Current Swing have tons of code. Only looking inside JTable and JTree you have about 10000 lines of code. It looks for me that it is utopia where all this code can be cleaned. There are too much of code left for compatibility and other reasongs, that will be dead for Swing2. While debugging parts like this - sometimes it can take you few hours just to figure out what parts are used and what parts are not. I think that first step - to write some specification for the component. Implement all required methods to declare some component interface, and at first just to wrap existing component. Than all used parts may be copied from existing component. After it will be completed - you will have clean component with no compatibility or dead code. There is always another way - just to look how Qt (being a bit supreme to swing in desktop) moved from 3 to 4 and use their experience. It's a shame I don't know how they did it... About generics and other... I never thought about casting something is a bad thing in your application, and other things like this. It takes you few seconds, while creating some TableColumnFactory and implementing some AbstractTableModel to be able to add elements, or implementing something similar to code completion, or even just detecting doubleclick... It consumes lots of time, at least in the stage of creating new application. Generics, enums and other is just some piece of API you can learn and use, while customizing your components or making your GUI customisable takes all the time.

[JonathanGiles]

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

@CodeRight: Simple, Jazz costs €1500 per developer.

[JonathanGiles]

Auto-imported comment, original author: Thierry Lefort Comment posted on: January 26, 2009

Oh there we are ... JavaFX is not Java ... I knew it was a religious debate not about technology.

Sun should buy JIDE and license it as LGPL. There you have your Swing 2.0.

Current JIDE License is not so expensive you should give it a try. After all it is one of the best(if not THE best) Java based GUI toolkit ever.

http://www.jidesoft.com/

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: January 26, 2009

Man! What a lively discussion! And the US of A isn't even awake yet.

Considering that the intention is to break of backwards compatibility on components, IMHO it is not wise to refactor existing code. Swing 1.0 exists and should be untampered.

So my suggestion on starting Swing 2 (after collecting the features) would be a technical discussion on the basic API and structure of a component (how to do painters, layout, skins, etc).

Then write the J2Component (extending JComponent), and next a J2Label & J2TextField both extending J2Component and get a serious set of unit test going to drill out the features we wanted.

After that scrollable stuff (J2TextArea) with unittest, refactoring. And if we got the kinks out of those, then it may be time to consider compound components like tables, lists, etc.

[JonathanGiles]

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

@Thierry Lefort: I would tend to agree, JavaFX (the language) is not Java (the language). It's easy to prove: I can program Java (the language) but not JavaFX (the language).

This isn't a religious debate, it is about accepting that JavaFX has its focus, and Swing has its focus. They may overlap, but they are also different. I write my applications in Swing, because I know Java (the language).

A company I am involved with did buy a Jide license for me and I have used it extensively. It is a great component suite. It is not Swing 2.0, for the reason you state: it has to be purchased. In addition, it is used in conjunction with a Swing 1.0 application, and it is Swing that is failing the developer, not Jide.

Cheers!

[JonathanGiles]

Auto-imported comment, original author: bubak Comment posted on: January 26, 2009

For me is Swing 2 Groovy and its builders.

[JonathanGiles]

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

@Tbee: Thanks for the pragmatic advice. It will definitely be interesting to see what the US has to say about it :)

As I mentioned, unfortunately it is late here in New Zealand (getting on to midnight), so I need to head off. I hope you all stick around and keep the discussion going - we need to get a consensus on what a Swing 2.0 means to you.

Discussion is open (no prior approval needed anymore), so I imagine discussion will continue to be lively for the coming hours.

[JonathanGiles]

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

@bubak: Perhaps you're correct if you're a Groovy developer, but for the sake of this discussion, the focus really is on answering the question 'how can Java (the language) be improved to make developers GUIs easier'? The answer almost certainly revolves around taking a syntax and to a lesser degree an archiecture similar to that of Swing and improving the rough edges.

In summary, I do not want to learn a completely new API. I want to take my Swing knowledge and be more effective when developing GUIs. I want Java (the language) to work as effectively as it can, which means making use of new language features, etc.

[JonathanGiles]

Auto-imported comment, original author: Aekold Comment posted on: January 26, 2009

@Thierry Lefort I am totally agree with your points of Swing2, but also I am not a fan of JavaFX. It will be great to make it possible for both Java and JavaFX. It is just some experience with languages without strong types. Don't declare it is religion vs technology, I can say similar - JavaFX looks for me more politics than Java. Java is suffering from own backward compatibility, but it is suffering of rt.jar but not langspec.

[JonathanGiles]

Auto-imported comment, original author: lunatix Comment posted on: January 26, 2009

+Model Simplification. Model af swing should be massively simplified.

Wicket Model is a good exemple of where to go. It is not possible to have a model for each componant. in the end, you have too many class to know.

(Edited by Jonathan: I assume that '=Model simplication' should have read '+Model simplification'. Let me know if I'm wrong and I'll return it back to how it was).

[JonathanGiles]

Auto-imported comment, original author: Aekold Comment posted on: January 26, 2009

@Tbee JComponent is not the best way to start. It is better to implement few working components and then move everything they have in common to J2Component, but not start from what they MAY BE WILL USE. As for me specification should be more feature specific at first, like requirements. And then to write strong architecture to solve all requirements.