Tips for backporting Java 1.6 classes into Java 1.5?

[Oliver Wong]

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

 

[Jeff Schwab]

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?

Sounds good to me. Way to think ahead!

 

[Thomas Hawtin]

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).

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

 

[Oliver Wong]

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

 

[Roedy Green]

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.

 

[Oliver Wong]

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).

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