f



Tips for backporting Java 1.6 classes into Java 1.5?

    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 


0
owong (6178)
9/21/2005 5:11:37 PM
comp.lang.java.programmer 52714 articles. 1 followers. Post Follow

5 Replies
699 Views

Similar Articles

[PageSpeed] 14

Oliver Wong wrote:
>     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!
0
9/21/2005 5:19:38 PM
Oliver Wong wrote:
> 
>     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
-- 
Unemployed English Java programmer
http://jroller.com/page/tackline/
0
usenet120 (1728)
9/21/2005 7:23:40 PM
"Thomas Hawtin" <usenet@tackline.plus.com> wrote in message 
news:4331b426$0$73597$ed2619ec@ptn-nntp-reader03.plus.net...
>
> 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 


0
owong (6178)
9/21/2005 7:53:41 PM
On Wed, 21 Sep 2005 17:11:37 GMT, "Oliver Wong" <owong@castortech.com>
wrote or quoted :

>    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.
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
0
look-on (4215)
9/21/2005 9:08:43 PM
"Oliver Wong" <owong@castortech.com> wrote in message 
news:dvgYe.269080$tt5.79726@edtnps90...
>    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 


0
owong (6178)
9/22/2005 3:19:01 PM
Reply: