![[Logo]](/templates/default/mobile/images/mobile-moose.gif)
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.
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.
