This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

What did the creators of Swing have against subclassing Swing components? (RANT!)  RSS feed

 
Kerry Shetline
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First of all, I must scream: Aaaaaarrrrrrgggggghhhhh!!!

I'm trying to move some AWT-based legacy code to Swing. The old code uses it's own mark-up format to do the same sorts of things you can do by setting a JLabel to "<html>blah blah blah...". Despite being old creaky AWT-base code, this mark-up system has two nice features you don't get with an HTML JLabel: Multiple clickable links within one single label, with distinguishable action commands for event handling for each link, and run-time image placement that works well with run-time created BufferedImage(s), placement doesn't require images to be pulled in from some URL.

Without these features, a whole lot more of our legacy code needs major rewriting to work in Swing.

I started looking down one path that involved using JEditorPane instead of JLabel, and HyperlinkListener, which gives me the listenable links I want. Then I started looking at writing my own URL protocol handler for dealing with IMG tags, and got that working enough to see that my own skeleton of a protocol handler was properly kicking in, but I got discouraged when I thought about having to somehow convert every in-memory BufferedImage into a PNG stream just to pipe images through this ridiculously round-about process.

The next thing I wanted to try was replacing the ImageView objects which ultimately get created for IMG tags in an HTML JLabel with my own ImageView subclass that could use my own BufferedImage images instead of URL-based images.

Object-oriented programming is supposed to save you from reinventing the wheel, and certainly an HTML rendering system that nicely handles changes in color and font and style, that handles word wrap for you, etc, is the kind if big, complicated wheel one does not want to have to reinvent.

In an ideal world, I should be able to take something like a JLabel that ALMOST does what I want, do a little subclassing and overriding and setting of parameters, and have something that does exactly what I want. I'd settle for a bit more subclassing and overriding, and getting almost what I want.

But I keep getting frustrated by behaviors buried deep within complex mazes of code flow that have no provisions for being modified or overridden except at the coarsest levels of granularity. Private or package-only variables and methods I can't access from my own subclasses. Classes that are declared final and can't be overridden at all.

In my efforts, I've ended up resorting to copying and pasting Swing code (the very thing object-oriented programming is supposed to help you avoid) just tweak what I can't tweak by setting a parameter, or by simply overriding a method. Even when I stoop to this copying and pasting, I often find variables, methods, or classes inaccessible by the pasted code. So I copy and paste the otherwise inaccessible stuff. And then that code has something I can't access, so I copy and pasted even more code... ad naseum.

I've created my own L&F, and created my own UI for JLabels. In order to successfully play with how View(s) are created, I could not effectively subclass javax.swing.plaf.basic.BasicHTML -- too much static and private crap -- it became a matter of copying and pasting practically the whole damn class and tweaking the copied code.

Having done that, I'm finding I can't effectively subclass ImageView either -- it will have to be copied and pasted and tweaked. Again, too much static private crap.

It's disgusting. It shouldn't be so much work, and I shouldn't have to rely on techniques that cut me off from future upgrades and improvements off the classes I'm "frankensteining" to get the results I want.

In a totally different area of dealing with this legacy code, having to do with creating a special class of editable text fields, I ran into very much the same sort of crap. And in other projects in other years, many of the same issues have cropped up.

I'm starting to feel like the creators of Swing were either clueless about making Swing more flexible, or were openly hostile to it. There's a lot which is clever and well-planned and flexible about Swing -- I don't want to make a blanket condemnation -- but too often lately I've been running into this other side of Swing, the parts of it.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm starting to feel like the creators of Swing were either clueless about making Swing more flexible, or were openly hostile to it. There's a lot which is clever and well-planned and flexible about Swing -- I don't want to make a blanket condemnation -- but too often lately I've been running into this other side of Swing, the [banghead] parts of it.

Condemn it to hell, I say. I seem to recall reading that the original version of Swing went from inception to implementation in 2 months time. Sun was in a hurry. Problem is they never fixed it. They just kept building on top of the mess that they made.

Swing is a pain in the butt. Powerful, but a pain. I have no words of encouragement. Just empathy.
 
Brian Cole
Author
Ranch Hand
Posts: 949
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with a lot of what you say. There is indeed too much static and
private stuff in the PLAF and View classes, for example.

That said, you should be able to implement label-like components in Swing
with hyperlink and BufferedImage support without having to write a custom
EditorKit and/or L&F.

I don't know all your requirements, of course, but it just doesn't sound
like it should be that hard. (Need they support line-wrapping? And just
how special are these editable text fields?)
[ July 23, 2008: Message edited by: Brian Cole ]
 
Paul Clapham
Sheriff
Posts: 22472
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I ran into the same sort of problems. Naively I expected that I could override the getText() method of JButton, so when the JButton wanted to display itself it would call my overridden getText() and it would get the appropriate text. But no, it didn't work that way. It stores the text internally in a private location and getText() is only there to be called by the unwashed masses.

Likewise when I was working with the javax.swing.undo package, I ran into the same problem that it was storing data internally in a variable, and if that wasn't the behaviour I wanted then I couldn't override methods to get the behaviour I did want. The Swing code was still going directly to the variable. Like you I had to troll through the source to see what it was doing before I could work around that.

And don't get me started on all of the secret system properties. I would ask a question on a forum and someone would say "Just set the swing-no-border-on-tuesday system property to true".
 
Kerry Shetline
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Brian Cole:
I don't know all your requirements, of course, but it just doesn't sound
like it should be that hard. (Need they support line-wrapping? And just
how special are these editable text fields?)

These widgets don't have to be editable, but they do need word wrap, styles, links, and images all mixed up in a pretty free-form way.
 
Ted Smyth
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Paul Clapham:
And don't get me started on all of the secret system properties. I would ask a question on a forum and someone would say "Just set the swing-no-border-on-tuesday system property to true".


Pure gold right there, if i may say so.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gregg Bolinger:
[b]
Swing is a pain in the butt. Powerful, but a pain. I have no words of encouragement. Just empathy.


+1!
 
Rob Spoor
Sheriff
Posts: 21087
85
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yet sometimes it can be so easy, like my extension of JTable (and TableModel, AbstractTableModel and DefaultTableModel) that can have cell renderers and editors for each cell separately instead of per column.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rob Prime:
Yet sometimes it can be so easy, like my extension of JTable (and TableModel, AbstractTableModel and DefaultTableModel) that can have cell renderers and editors for each cell separately instead of per column.


'easy' is relative.
 
Suraj Chandran
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Swing is a pain in the butt. Powerful, but a pain. I have no words of encouragement. Just empathy.


-1...or -0.5 atleast

I don't think Swing is that big a pain. The problem here is that for GUI programming people are used to rely on RAD frameworks like Visual Basic where you really don't need to write a single line of code at all. The advantage of Swing is that it exposes to you so much flexibility and extendibility that you just can write any component you imagine. But ofcourse, no framework is perfect....But the point here is that do you want me to count the number of issues in other GUI frameworks....trust me the list is huge...leave alone most of them are platform specific....

Cheers,
Suraj
 
G Estes
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Suraj, I agree with you. Swing in an of itself is not that difficult to work with. It is the "GUI Builders" that try to over-simplify things that cause issues. Swing is not a VisualBasic type thing, but it is not that difficult to use if you take the time to learn it from the ground up. My "Rant" is that there are people using drag and drop tools calling themselves "Swing Developers", when they are nothing of the sort.

Sorry for any toes I just stepped on...but come on folks, take time to learn a bit...
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Suraj and Gil,
I think both of you are missing the point of what the original post is about. Nowhere is there a complaint that Swing is hard to use (which is what both of you are talking about). I don't see any hint that a GUI builder is being used - to the contrary, it sounds like manually crafting code is what's being talked about.

The point is that many Swing classes are hard (or impossible) to subclass, which makes extending Swing unnecessarily hard.
 
Rob Spoor
Sheriff
Posts: 21087
85
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well that is true. Usually when I need some kind of control I just subclass JPanel and add everything to that. Much easier.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!