Tips for backporting Java 1.6 classes into Java 1.5?

Thread view:

Oliver Wong - 21 Sep 2005 18:11 GMT

I'm writing a Swing app, and I wanted a way to filter certain rows out
of a JTable. I search Sun's API to see if they had any facilities for doing
this, and I while I couldn't find such an API for 1.5, there is one for 1.6:
javax.swing.RowFilter
(http://download.java.net/jdk6/docs/api/javax/swing/RowFilter.html)

So I have a bit of a dilemma here. I don't want to have to "wait" for
1.6 to come out. I don't want to actually use a beta version of 1.6 (forcing
my clients to do the same). But I don't want to implement this functionality
myself, only to have to re-architecture my app when 1.6 does come out and we
want to switch to the official API.

The solution I've come up with is to write a class which implements the
same interface as Sun's javax.swing.RowFilter class, with the hope that the
interface won't change significantly when 1.6 is finally released. Then,
hopefully, when 1.6 does come out, the changes require to switch from my
implementation to Sun's implementation should be relatively minor (the
method signatures will be the same, and hopefully my interpretation of the
semantics will be close enough to the actual semantics that no bugs will
surface).

Is this the right approach, or is there a better way?

- Oliver

Reply to this Message

Jeff Schwab - 21 Sep 2005 18:19 GMT

> I'm writing a Swing app, and I wanted a way to filter certain rows out
> of a JTable. I search Sun's API to see if they had any facilities for doing
[quoted text clipped - 18 lines]
>
> Is this the right approach, or is there a better way?

Sounds good to me. Way to think ahead!

Reply to this Message

Thomas Hawtin - 21 Sep 2005 20:23 GMT

> The solution I've come up with is to write a class which implements the
> same interface as Sun's javax.swing.RowFilter class, with the hope that the
[quoted text clipped - 4 lines]
> semantics will be close enough to the actual semantics that no bugs will
> surface).

Have you seen SwingX? 1.5 version of the 1.6 code. It's not final
release, but it's a good start. And under LGPL.

https://swingx.dev.java.net/

Tom Hawtin

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

Oliver Wong - 21 Sep 2005 20:53 GMT

> Have you seen SwingX? 1.5 version of the 1.6 code. It's not final release,
> but it's a good start. And under LGPL.
>
> https://swingx.dev.java.net/

The project looks great, though I found the site difficult to navigate
(e.g. where's the JavaDocs?!)

My application is being deployed via WebStart, and I've had some people
complain about the filesize (I had to include a JAR from JFreeChart), so
I'll probably avoid including the SwingX JAR (if indeed such a thing exists,
it wasn't clear from my brief perusal of the site). I might however take a
look at their source code as inspiration for my own implementation (my
project's under GPL). Thank you!

- Oliver

Reply to this Message

Roedy Green - 21 Sep 2005 22:08 GMT

> The solution I've come up with is to write a class which implements the
>same interface as Sun's javax.swing.RowFilter class, with the hope that the
>interface won't change significantly when 1.6 is finally released.

I think what you are planning to do sounds reasonable. If on the other
hand, if you were going to write large amounts of code using this, you
would use an adaptor class that would plug into your code now, and
Sun's later.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Reply to this Message

Oliver Wong - 22 Sep 2005 16:19 GMT

> The solution I've come up with is to write a class which implements the
> same interface as Sun's javax.swing.RowFilter class, with the hope that
[quoted text clipped - 4 lines]
> of the semantics will be close enough to the actual semantics that no bugs
> will surface).

So I tried actually implementing this last night, and it turned out to
be a real nightmare. The way you actually apply these RowFilter objects is
put them inside of a javax.swing.RowSorter and then call JTable's
setRowSorter() method. So that means I'd have to implement RowSorter as
well, and then implement the changes to JTable. I think when the changes
required cascaded into 8 different classes was when I gave up. Boo for such
tight class-interdepencies.

So now it looks like the next least painful solution is to create a new
TableModel which takes as an argument an existing TableModel, and then
selectively filters out certain rows. Sun's javax.swing.RowFilter itself
doesn't depend on too many other classes, so maybe I can still use that API,
and pass instances of them to my new FilteringTableModel.

- Oliver

Reply to this Message

Tips for backporting Java 1.6 classes into Java 1.5?

Free Magazines