Wrong List API implementation for TreeList

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Wrong List API implementation for TreeList

Dirk Fauth
Hi,

I was trying to work on a TreeList as with any other List implementation. There is one thing that doesn't match and makes the compiler and the runtime behaviour inconsistent. This seems to be related to Generics.

If you remove an element out of a TreeList with TreeList<MyClass>.remove(index) the compiler tells that an instance of MyClass will be returned. This is what I'll expect from a List implementation.
At runtime, this breaks with a ClassCastException because remove(index) will return an instance of TreeList.Node.

I do a workaround for this by putting the result to an instance of Object and do a manual cast to TreeList.Node and then calling TreeList.Node.getElement(). But this is a very dirty hack.

I'm working with GlazedLists 1.8.0 and haven't checked against the 1.9.0 developer preview.

BTW, is there a release date for 1.9.0. I'm a committer to Nebula NatTable and we are making heavy use of GlazedLists. In 1.8.0 there is also an issue with updating TreeList.Format, which doesn't work without a manual workaround. (http://java.net/jira/browse/GLAZEDLISTS-521). We are curious if this will be fixed with 1.9.0.

Thanks for your help in advance. Looking forward to any answers on this.

Greez,
Dirk
Reply | Threaded
Open this post in threaded view
|

Re: Wrong List API implementation for TreeList

hbrands
Administrator
Hi Dirk,

thanks for reporting this TreeList issue, it's tracked here http://java.net/jira/browse/GLAZEDLISTS-557
and is fixed for version 1.9.
You still have to be careful though, please have a look at the issue comment.
Removing elements directly on a TreeList can have surprising results, see examples here:
http://java.net/projects/glazedlists/sources/svn/diff/trunk/test/ca/odell/glazedlists/TreeListTest.java?rev1=2347&rev2=2348

I think the primary use case the authors had in mind is modifying the source list, where TreeList reacts to accordingly.
Modifying TreeList directly is possible, but not thoroughly tested. TreeList is still "Developer Preview".

The roadmap for 1.9 is available here:
http://java.net/jira/browse/GLAZEDLISTS/fixforversion/14295#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
There are a few issues left in the implementation of the grouping functionality, which are not trivial to fix.
When those are done, I plan to do the release.
GLAZEDLISTS-521 is currently not scheduled for 1.9.
Generally, tested patches or other contributions are appreciated and help to shape the next release(s).

BTW, when upgrading to 1.9, please have a look at the upgrade guide here:
http://www.glazedlists.com/documentation/upgrade-from-18-to-19

Thanks,
Holger

2012/11/13 Dirk Fauth <[hidden email]>
Hi,

I was trying to work on a TreeList as with any other List implementation.
There is one thing that doesn't match and makes the compiler and the runtime
behaviour inconsistent. This seems to be related to Generics.

If you remove an element out of a TreeList with
TreeList<MyClass>.remove(index) the compiler tells that an instance of
MyClass will be returned. This is what I'll expect from a List
implementation.
At runtime, this breaks with a ClassCastException because remove(index) will
return an instance of TreeList.Node.

I do a workaround for this by putting the result to an instance of Object
and do a manual cast to TreeList.Node and then calling
TreeList.Node.getElement(). But this is a very dirty hack.

I'm working with GlazedLists 1.8.0 and haven't checked against the 1.9.0
developer preview.

BTW, is there a release date for 1.9.0. I'm a committer to Nebula NatTable
and we are making heavy use of GlazedLists. In 1.8.0 there is also an issue
with updating TreeList.Format, which doesn't work without a manual
workaround. (http://java.net/jira/browse/GLAZEDLISTS-521). We are curious if
this will be fixed with 1.9.0.

Thanks for your help in advance. Looking forward to any answers on this.

Greez,
Dirk



--
View this message in context: http://glazedlists.1045722.n5.nabble.com/Wrong-List-API-implementation-for-TreeList-tp5709779.html
Sent from the GlazedLists - Issues mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Wrong List API implementation for TreeList

Dirk Fauth
Hi Holger,

thank you very much for your response. These are the informations I was looking for. :)
And thanks for fixing the bug I reported.

In NatTable we are using TreeList for implementing tree tables. And it works quite well. We will have a closer look at the use cases you mentioned.

I've found the manual workaround for GLAZEDLISTS-521 in some forum. It looks like this:

    /**
     * Method to update the tree list after filter or TreeList.Format changed.
     * Need this workaround to update the tree list for presentation because of
     * http://java.net/jira/browse/GLAZEDLISTS-521
     */
    protected void updateTree() {
        this.rowObjectsGlazedList.getReadWriteLock().writeLock().lock();
        try {
            for (int i = 0; i < this.rowObjectsGlazedList.size(); i++) {
                this.rowObjectsGlazedList.set(i,
                        this.rowObjectsGlazedList.get(i));
            }
        } finally {
            this.rowObjectsGlazedList.getReadWriteLock().writeLock().unlock();
        }
    }

But that's really some workaround and not a suitable solution. Haven't looked that much into detail to propose a real solution.

We also had some workaround implementation for ThresholdMatcherEditor in NatTable. We had to remove it by moving to Eclipse. I'm not sure if this bug is already fixed/addressed in GlazedLists and I'm not sure if this fix was contributed back to you. I'll attach the file so you can have a look. You'll find some description within the comments.
I don't know who did this in the NatTable team. It wasn't me so I can't answer any questions on that. But if you have any questions I would try to contact our project lead to get in contact with you.

Greez,
Dirk


On Sun, Nov 18, 2012 at 6:02 PM, hbrands [via GlazedLists] <[hidden email]> wrote:
Hi Dirk,

thanks for reporting this TreeList issue, it's tracked here http://java.net/jira/browse/GLAZEDLISTS-557
and is fixed for version 1.9.
You still have to be careful though, please have a look at the issue comment.
Removing elements directly on a TreeList can have surprising results, see examples here:
http://java.net/projects/glazedlists/sources/svn/diff/trunk/test/ca/odell/glazedlists/TreeListTest.java?rev1=2347&rev2=2348

I think the primary use case the authors had in mind is modifying the source list, where TreeList reacts to accordingly.
Modifying TreeList directly is possible, but not thoroughly tested. TreeList is still "Developer Preview".

The roadmap for 1.9 is available here:
http://java.net/jira/browse/GLAZEDLISTS/fixforversion/14295#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
There are a few issues left in the implementation of the grouping functionality, which are not trivial to fix.
When those are done, I plan to do the release.
GLAZEDLISTS-521 is currently not scheduled for 1.9.
Generally, tested patches or other contributions are appreciated and help to shape the next release(s).

BTW, when upgrading to 1.9, please have a look at the upgrade guide here:
http://www.glazedlists.com/documentation/upgrade-from-18-to-19

Thanks,
Holger

2012/11/13 Dirk Fauth <[hidden email]>
Hi,

I was trying to work on a TreeList as with any other List implementation.
There is one thing that doesn't match and makes the compiler and the runtime
behaviour inconsistent. This seems to be related to Generics.

If you remove an element out of a TreeList with
TreeList<MyClass>.remove(index) the compiler tells that an instance of
MyClass will be returned. This is what I'll expect from a List
implementation.
At runtime, this breaks with a ClassCastException because remove(index) will
return an instance of TreeList.Node.

I do a workaround for this by putting the result to an instance of Object
and do a manual cast to TreeList.Node and then calling
TreeList.Node.getElement(). But this is a very dirty hack.

I'm working with GlazedLists 1.8.0 and haven't checked against the 1.9.0
developer preview.

BTW, is there a release date for 1.9.0. I'm a committer to Nebula NatTable
and we are making heavy use of GlazedLists. In 1.8.0 there is also an issue
with updating TreeList.Format, which doesn't work without a manual
workaround. (http://java.net/jira/browse/GLAZEDLISTS-521). We are curious if
this will be fixed with 1.9.0.

Thanks for your help in advance. Looking forward to any answers on this.

Greez,
Dirk



--
View this message in context: http://glazedlists.1045722.n5.nabble.com/Wrong-List-API-implementation-for-TreeList-tp5709779.html
Sent from the GlazedLists - Issues mailing list archive at Nabble.com.




If you reply to this email, your message will be added to the discussion below:
http://glazedlists.1045722.n5.nabble.com/Wrong-List-API-implementation-for-TreeList-tp5709779p5709783.html
To unsubscribe from Wrong List API implementation for TreeList, click here.
NAML


ThresholdMatcherEditor.java (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wrong List API implementation for TreeList

hbrands
Administrator
Hi Dirk,

with regard to the ThresholdMatcherEditor problem I found this:
http://glazedlists.1045722.n5.nabble.com/Bug-in-ThresholdMatcherEditor-tt3420049.html

I think it should be fixed in 1.9 with the changes for issue
http://java.net/jira/browse/GLAZEDLISTS-515

But to be sure, you would have to retest it...

Holger

2012/11/19 Dirk Fauth <[hidden email]>
<snip>
We also had some workaround implementation for ThresholdMatcherEditor in NatTable. We had to remove it by moving to Eclipse. I'm not sure if this bug is already fixed/addressed in GlazedLists and I'm not sure if this fix was contributed back to you. I'll attach the file so you can have a look. You'll find some description within the comments.
I don't know who did this in the NatTable team. It wasn't me so I can't answer any questions on that. But if you have any questions I would try to contact our project lead to get in contact with you.

Greez,
Dirk


On Sun, Nov 18, 2012 at 6:02 PM, hbrands [via GlazedLists] <[hidden email]> wrote:
Hi Dirk,

thanks for reporting this TreeList issue, it's tracked here http://java.net/jira/browse/GLAZEDLISTS-557
and is fixed for version 1.9.
You still have to be careful though, please have a look at the issue comment.
Removing elements directly on a TreeList can have surprising results, see examples here:
http://java.net/projects/glazedlists/sources/svn/diff/trunk/test/ca/odell/glazedlists/TreeListTest.java?rev1=2347&rev2=2348

I think the primary use case the authors had in mind is modifying the source list, where TreeList reacts to accordingly.
Modifying TreeList directly is possible, but not thoroughly tested. TreeList is still "Developer Preview".

The roadmap for 1.9 is available here:
http://java.net/jira/browse/GLAZEDLISTS/fixforversion/14295#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
There are a few issues left in the implementation of the grouping functionality, which are not trivial to fix.
When those are done, I plan to do the release.
GLAZEDLISTS-521 is currently not scheduled for 1.9.
Generally, tested patches or other contributions are appreciated and help to shape the next release(s).

BTW, when upgrading to 1.9, please have a look at the upgrade guide here:
http://www.glazedlists.com/documentation/upgrade-from-18-to-19

Thanks,
Holger

2012/11/13 Dirk Fauth <[hidden email]>

Hi,

I was trying to work on a TreeList as with any other List implementation.
There is one thing that doesn't match and makes the compiler and the runtime
behaviour inconsistent. This seems to be related to Generics.

If you remove an element out of a TreeList with
TreeList<MyClass>.remove(index) the compiler tells that an instance of
MyClass will be returned. This is what I'll expect from a List
implementation.
At runtime, this breaks with a ClassCastException because remove(index) will
return an instance of TreeList.Node.

I do a workaround for this by putting the result to an instance of Object
and do a manual cast to TreeList.Node and then calling
TreeList.Node.getElement(). But this is a very dirty hack.

I'm working with GlazedLists 1.8.0 and haven't checked against the 1.9.0
developer preview.

BTW, is there a release date for 1.9.0. I'm a committer to Nebula NatTable
and we are making heavy use of GlazedLists. In 1.8.0 there is also an issue
with updating TreeList.Format, which doesn't work without a manual
workaround. (http://java.net/jira/browse/GLAZEDLISTS-521). We are curious if
this will be fixed with 1.9.0.

Thanks for your help in advance. Looking forward to any answers on this.

Greez,
Dirk



--
View this message in context: http://glazedlists.1045722.n5.nabble.com/Wrong-List-API-implementation-for-TreeList-tp5709779.html
Sent from the GlazedLists - Issues mailing list archive at Nabble.com.




If you reply to this email, your message will be added to the discussion below:
http://glazedlists.1045722.n5.nabble.com/Wrong-List-API-implementation-for-TreeList-tp5709779p5709783.html
To unsubscribe from Wrong List API implementation for TreeList, click here.
NAML


ThresholdMatcherEditor.java (15K) Download Attachment


View this message in context: Re: Wrong List API implementation for TreeList

Sent from the GlazedLists - Issues mailing list archive at Nabble.com.