Stupid Java Tricks

I can’t really think of a good reason why you’d want t send object data to std out (System.out), but I recently had a project requirement that a parent process read the output from a child process. The child process output was complex, so I wondered if I could send it as object data instead of text. I was told, “You can’t do that”, which is when I knew that I would find a way. Turns out, it was easier than expected. As you’ve probably guessed, sending text would be faster. I didn’t time it against sending text, so I don’t know by how much. If you time it, let me know your results.

Continue Reading »

Before adding Drag and Drop capabilities to my JTable, I read Java Tip 97 and Java Tip 114 from JavaWorld. They were fairly helpful, but I ended up doing things a little differently. In implementing my Drag and Drop JTree, however, I was plagued by a persistent exception: “InvalidDnDOperationException: Drag and drop in progress.” I debugged my code for hours before finally finding the source of the error. Somewhere along the line I had called tree.setDragEnabled( true ), which is what caused the error. You will always get this error if you call setDragEnabled ( true ) while also creating a DragSource using your JTree. My completed Drag and Drop enabled JTree can be found here if anyone is interested in using it. It contains a lot of other methods related to my specific project that you’ll have to wade through and remove. But if you focus on the Drag and Drop related methods, you’ll get the gist of how it’s done.

I started working on a news aggregator application as my semester project last month, but it has turned into much more than the simple RSS reader is started out as. It now reads all versions of RSS, RDF and Atom. I’ve also updated the GUI to have a nicer look and feel. Here’s are some screen captures.

There’s still some work to be done before ComputerFest contest in February, but it’s coming along nicely. I’ll be offering it for beta testing when I get all of the minimum features added. If you’re interested, check back in the next week or so and I should have something posted for download.

I’ve recently been extending my Java RSS/Atom feed reader to support more versions of RSS. In doing so I’ve discovered that the version history of RSS is a lot more complicated than I’d thought. One would assume that the version history was linear from 0.9 through 2.0, but one would be wrong. Versions 0.9, 0.91, 0.92, and 0.93 all follow the same branch, but version 1.0 forks from this branch to form it’s own specification that uses the rdf namespace. And adding to the confusion, version 2.0 is a continuation of 0.93. (Here’s a good article with links to information about the history of RSS, the fork, and the Atom format.) As someone with no knowledge of this fork, I’ve looked through scores of RSS feeds, trying to reconcile the obvious differences in version formats. When I read about the fork, it finally made sense. Whew. But man, what a pain in the butt. I now have to write SAX parsers that read and validate all of these differeng standards. I guess it’s better than wriing an HTML parser!  

Robert Eckstein writes:

The latest beta version of the Java 2 Platform Standard Edition 6.0 version (Mustang) now lets you access the system tray in Java with the help of two separate classes in the java.awt package: SystemTray and TrayIcon. These classes give you the ability to add graphics, popup menus, and floating tip functionality to the system tray. If approved by the JSR 270 Expert Group through the Java Community Process, you can expect to find this feature in the final version of Mustang.

Article here I’ve also recently tried the built-in splash screen API that Mustang will ship with. Pretty nifty.

I recently wrote a news reader application (RSS only at the moment) that displays the messages using HTML. In doing so, I discovered the terrible state of the javax.swing.text.html.HTMLEditorKit. From the Javadoc:

The default support is provided by this class, which supports HTML version 3.2 (with some extensions), and is migrating toward version 4.0.

Continue Reading »

By default a left mouse click on a JTable row will select that row, but it’s not the same for the right mouse button. It takes bit more work to get a JTable to select a row based on right mouse clicks. You might be able to do it by subclassing JTable or ListSelectionModel, but there’s an easier way.
Continue Reading »

If you create an object that inherits directly from Object, you’ll notice a distinct lack of any methods to handle events. That’s because event dispatching was meant mainly for AWT and Swing components. But you can use a similar method of detecting state change in your non-GUI objects. The first thing you’ll need in your object is a list of listeners – something like this:

Continue Reading »

I was recently tasked with an assignment that required me to draw several randomly generated colored circles and a target to a playing field. The user can choose the circle that he/she thinks will hit the target first and then bet on it. To make the choice as simple as possible I wanted a way to add my colored circles to a JComboBox. However the default ListCellRenderer of JComoBox only renders text or Image objects, so I needed a way to convert each of my circles into an Image. After some searching I found that java.awt.image.BufferedImage had a method called getGraphics() that returns a Graphics object. Actually, it returns a Graphics2D object cast as a Graphics, so you have to cast to get a Graphics2D. You can use this Graphics object to draw directly to this BufferedImage and then Create an ImageIcon from there.
Continue Reading »

When I initially began reading about and using generics in Java, I heard the term “erasure”, but forgot it almost as soon as I’d read it. This is mostly because it didn’t really seem to affect my usage of generics at the time. Erasure is the process by which the compiler changes your parameterized generic code into plain old Objects. That’s right – generics are little more than syntactic sugar that give you a little added compile-time type checking. But behind the scenes it’s all being undone. So what effect does this have? Well, for one thing reflection will not work. You can’t check the specific type of something if it’s cast back into a non-parameterized type during compilation. So your ArrayList<Integer> will basically become an ArrayList<object>, which means that dynamic runtime checks and downcasts are still necessary. Sun did this mainly for backwards compatibility with previous versions of Java, which is understandable for the time being. Incidentally, version 2.0 of C# introduces generics for the first time and they chose to give them run-time representation from the beginning. Hopefully Sun will follow suit.