Quantcast

Delete ListEvent Blocks

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Delete ListEvent Blocks

Fabian Zeindl
Hi,

 I have a performance problem and observed that when constraining the filter on a large list, the resulting DELETE events aren't grouped into proper blocks anymore. Instead I get thousands of deletions at index 0.

It this because ListEvent includes the deleted element now?

Regards
Fabian
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delete ListEvent Blocks

robeden
This is the problem: https://java.net/jira/browse/GLAZEDLISTS-576

I've worked around it in a couple horrible ways in places. Here's one:

See ImmediateDispatchingListener.canJoinEvent(...)

I've casually experimented with a better dispatching implementation which could deal with values better (in core GL) but don't have anything ready for primetime. Support for ListEvent.get*Value() methods is what broke blocking and unfortunately the fix isn't trivial.



On Wed, Jan 4, 2017 at 8:22 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

 I have a performance problem and observed that when constraining the filter on a large list, the resulting DELETE events aren't grouped into proper blocks anymore. Instead I get thousands of deletions at index 0.

It this because ListEvent includes the deleted element now?

Regards
Fabian
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delete ListEvent Blocks

mauromol
Please also see: https://java.net/jira/browse/GLAZEDLISTS-519

I still think that, given the challenges of implementing the get*Value() methods for all EvenLists and the issues it causes, doing a partial rollback and changing the approach to this problem would be the best choice, as I wrote here: https://java.net/jira/browse/GLAZEDLISTS-253?focusedCommentId=362782&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-362782

After all, we are in 2017 and GLAZEDLISTS-253 has not yet been completed, while issues like GLAZEDLISTS-519 and GLAZEDLISTS-576 are effective :-)

Mauro

Il 04/01/2017 18:28, Rob Eden ha scritto:
This is the problem: https://java.net/jira/browse/GLAZEDLISTS-576

I've worked around it in a couple horrible ways in places. Here's one:

See ImmediateDispatchingListener.canJoinEvent(...)

I've casually experimented with a better dispatching implementation which could deal with values better (in core GL) but don't have anything ready for primetime. Support for ListEvent.get*Value() methods is what broke blocking and unfortunately the fix isn't trivial.



On Wed, Jan 4, 2017 at 8:22 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

 I have a performance problem and observed that when constraining the filter on a large list, the resulting DELETE events aren't grouped into proper blocks anymore. Instead I get thousands of deletions at index 0.

It this because ListEvent includes the deleted element now?

Regards
Fabian


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delete ListEvent Blocks

Fabian Zeindl
Thanks for the replies.

I wrote a rather simple "ListEventCompressor" that simply combines the changes back into one,
it seems to work well so far. (Kotlin source: https://gist.github.com/fab1an/66baf6da26f8232b5b7e4da01306e062)

I think that the grouping of ListEvents is a far more important and central feature to GL than having the get* functions.

fabian

> On 4 Jan 2017, at 18:57 , Mauro Molinari <[hidden email]> wrote:
>
> Please also see: https://java.net/jira/browse/GLAZEDLISTS-519
>
> I still think that, given the challenges of implementing the get*Value() methods for all EvenLists and the issues it causes, doing a partial rollback and changing the approach to this problem would be the best choice, as I wrote here: https://java.net/jira/browse/GLAZEDLISTS-253?focusedCommentId=362782&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-362782
>
> After all, we are in 2017 and GLAZEDLISTS-253 has not yet been completed, while issues like GLAZEDLISTS-519 and GLAZEDLISTS-576 are effective :-)
>
> Mauro
>
> Il 04/01/2017 18:28, Rob Eden ha scritto:
>> This is the problem: https://java.net/jira/browse/GLAZEDLISTS-576
>>
>> I've worked around it in a couple horrible ways in places. Here's one:
>> https://bitbucket.org/robeden/glazedlists-vaadin-container/src/b93a6f986e41df3f74005b628f9e1af8ef4efa6f/src/main/java/com/starlight/vaadin/glazedlists/EventListContainerInvocationHandler.java?at=master&fileviewer=file-view-default
>>
>> See ImmediateDispatchingListener.canJoinEvent(...)
>>
>> I've casually experimented with a better dispatching implementation which could deal with values better (in core GL) but don't have anything ready for primetime. Support for ListEvent.get*Value() methods is what broke blocking and unfortunately the fix isn't trivial.
>>
>>
>>
>> On Wed, Jan 4, 2017 at 8:22 AM Fabian Zeindl <[hidden email]> wrote:
>> Hi,
>>
>>  I have a performance problem and observed that when constraining the filter on a large list, the resulting DELETE events aren't grouped into proper blocks anymore. Instead I get thousands of deletions at index 0.
>>
>> It this because ListEvent includes the deleted element now?
>>
>> Regards
>> Fabian
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delete ListEvent Blocks

robeden
In reply to this post by mauromol
Thanks, Mauro. Those links are very helpful.

Personally, I (theoretically) agree with reverting the changes as there has been a huge performance impact. However, one thing that was difficult to determine was the full impact of pulling the partial implementation. There is quite a bit of usage of the get*Value() methods, particularly in sorting, if memory serves.

In earlier experiments I was attempting to swap out the BlockSequence implementation used in the ListEventAssembler. I think doing something like that might allow for faster/lower feature implementations versus slower/more full-featured implementations. The problem that causes is handling the absence of the values in ListEvents in a graceful way. Without knowing the full impact of removing them (which I hadn't gotten around to analyzing yet), that's difficult to plan.

I have an experimental (and broken!) implementation here, if you're curious: https://github.com/robeden/glazedlists/tree/LinkedNodeBlockSequence
The main problem is that I hadn't realized that delivery indices had to be ordered. Once I found that I got sidetracked and haven't gotten back to it yet.

On Wed, Jan 4, 2017 at 11:57 AM Mauro Molinari <[hidden email]> wrote:
Please also see: https://java.net/jira/browse/GLAZEDLISTS-519

I still think that, given the challenges of implementing the get*Value() methods for all EvenLists and the issues it causes, doing a partial rollback and changing the approach to this problem would be the best choice, as I wrote here: https://java.net/jira/browse/GLAZEDLISTS-253?focusedCommentId=362782&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-362782

After all, we are in 2017 and GLAZEDLISTS-253 has not yet been completed, while issues like GLAZEDLISTS-519 and GLAZEDLISTS-576 are effective :-)


Mauro


Il 04/01/2017 18:28, Rob Eden ha scritto:
This is the problem: https://java.net/jira/browse/GLAZEDLISTS-576

I've worked around it in a couple horrible ways in places. Here's one:

See ImmediateDispatchingListener.canJoinEvent(...)

I've casually experimented with a better dispatching implementation which could deal with values better (in core GL) but don't have anything ready for primetime. Support for ListEvent.get*Value() methods is what broke blocking and unfortunately the fix isn't trivial.



On Wed, Jan 4, 2017 at 8:22 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

 I have a performance problem and observed that when constraining the filter on a large list, the resulting DELETE events aren't grouped into proper blocks anymore. Instead I get thousands of deletions at index 0.

It this because ListEvent includes the deleted element now?

Regards
Fabian


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delete ListEvent Blocks

Fabian Zeindl
Would it be possible to provide the values in grouped changes as an Iterable?

> On 4 Jan 2017, at 22:09 , Rob Eden <[hidden email]> wrote:
>
> Thanks, Mauro. Those links are very helpful.
>
> Personally, I (theoretically) agree with reverting the changes as there has been a huge performance impact. However, one thing that was difficult to determine was the full impact of pulling the partial implementation. There is quite a bit of usage of the get*Value() methods, particularly in sorting, if memory serves.
>
> In earlier experiments I was attempting to swap out the BlockSequence implementation used in the ListEventAssembler. I think doing something like that might allow for faster/lower feature implementations versus slower/more full-featured implementations. The problem that causes is handling the absence of the values in ListEvents in a graceful way. Without knowing the full impact of removing them (which I hadn't gotten around to analyzing yet), that's difficult to plan.
>
> I have an experimental (and broken!) implementation here, if you're curious: https://github.com/robeden/glazedlists/tree/LinkedNodeBlockSequence
> The main problem is that I hadn't realized that delivery indices had to be ordered. Once I found that I got sidetracked and haven't gotten back to it yet.
>
> On Wed, Jan 4, 2017 at 11:57 AM Mauro Molinari <[hidden email]> wrote:
> Please also see: https://java.net/jira/browse/GLAZEDLISTS-519
>
> I still think that, given the challenges of implementing the get*Value() methods for all EvenLists and the issues it causes, doing a partial rollback and changing the approach to this problem would be the best choice, as I wrote here: https://java.net/jira/browse/GLAZEDLISTS-253?focusedCommentId=362782&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-362782
>
> After all, we are in 2017 and GLAZEDLISTS-253 has not yet been completed, while issues like GLAZEDLISTS-519 and GLAZEDLISTS-576 are effective :-)
>
>
> Mauro
>
>
> Il 04/01/2017 18:28, Rob Eden ha scritto:
>> This is the problem: https://java.net/jira/browse/GLAZEDLISTS-576
>>
>> I've worked around it in a couple horrible ways in places. Here's one:
>> https://bitbucket.org/robeden/glazedlists-vaadin-container/src/b93a6f986e41df3f74005b628f9e1af8ef4efa6f/src/main/java/com/starlight/vaadin/glazedlists/EventListContainerInvocationHandler.java?at=master&fileviewer=file-view-default
>>
>> See ImmediateDispatchingListener.canJoinEvent(...)
>>
>> I've casually experimented with a better dispatching implementation which could deal with values better (in core GL) but don't have anything ready for primetime. Support for ListEvent.get*Value() methods is what broke blocking and unfortunately the fix isn't trivial.
>>
>>
>>
>> On Wed, Jan 4, 2017 at 8:22 AM Fabian Zeindl <[hidden email]> wrote:
>> Hi,
>>
>>  I have a performance problem and observed that when constraining the filter on a large list, the resulting DELETE events aren't grouped into proper blocks anymore. Instead I get thousands of deletions at index 0.
>>
>> It this because ListEvent includes the deleted element now?
>>
>> Regards
>> Fabian
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delete ListEvent Blocks

robeden
Yes, that would probably be a good design. I'd love to play with it, but my todo list is a bit long at the moment. I'll play with it as soon as I can, but feel free to beat me to the punch if you have time.

Side thought: From a performance standpoint, something I was considering what allowing the list pipeline to signal up the chain what features were needed. For example, tracking of old values could be skipped until something down the chain requested it. So, if a list type needs that information to function, it could signal the source which could enable up the chain if needed. This would obviously be a significant rework though.

On Thu, Jan 5, 2017 at 12:54 AM Fabian Zeindl <[hidden email]> wrote:
Would it be possible to provide the values in grouped changes as an Iterable?

> On 4 Jan 2017, at 22:09 , Rob Eden <[hidden email]> wrote:
>
> Thanks, Mauro. Those links are very helpful.
>
> Personally, I (theoretically) agree with reverting the changes as there has been a huge performance impact. However, one thing that was difficult to determine was the full impact of pulling the partial implementation. There is quite a bit of usage of the get*Value() methods, particularly in sorting, if memory serves.
>
> In earlier experiments I was attempting to swap out the BlockSequence implementation used in the ListEventAssembler. I think doing something like that might allow for faster/lower feature implementations versus slower/more full-featured implementations. The problem that causes is handling the absence of the values in ListEvents in a graceful way. Without knowing the full impact of removing them (which I hadn't gotten around to analyzing yet), that's difficult to plan.
>
> I have an experimental (and broken!) implementation here, if you're curious: https://github.com/robeden/glazedlists/tree/LinkedNodeBlockSequence
> The main problem is that I hadn't realized that delivery indices had to be ordered. Once I found that I got sidetracked and haven't gotten back to it yet.
>
> On Wed, Jan 4, 2017 at 11:57 AM Mauro Molinari <[hidden email]> wrote:
> Please also see: https://java.net/jira/browse/GLAZEDLISTS-519
>
> I still think that, given the challenges of implementing the get*Value() methods for all EvenLists and the issues it causes, doing a partial rollback and changing the approach to this problem would be the best choice, as I wrote here: https://java.net/jira/browse/GLAZEDLISTS-253?focusedCommentId=362782&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-362782
>
> After all, we are in 2017 and GLAZEDLISTS-253 has not yet been completed, while issues like GLAZEDLISTS-519 and GLAZEDLISTS-576 are effective :-)
>
>
> Mauro
>
>
> Il 04/01/2017 18:28, Rob Eden ha scritto:
>> This is the problem: https://java.net/jira/browse/GLAZEDLISTS-576
>>
>> I've worked around it in a couple horrible ways in places. Here's one:
>> https://bitbucket.org/robeden/glazedlists-vaadin-container/src/b93a6f986e41df3f74005b628f9e1af8ef4efa6f/src/main/java/com/starlight/vaadin/glazedlists/EventListContainerInvocationHandler.java?at=master&fileviewer=file-view-default
>>
>> See ImmediateDispatchingListener.canJoinEvent(...)
>>
>> I've casually experimented with a better dispatching implementation which could deal with values better (in core GL) but don't have anything ready for primetime. Support for ListEvent.get*Value() methods is what broke blocking and unfortunately the fix isn't trivial.
>>
>>
>>
>> On Wed, Jan 4, 2017 at 8:22 AM Fabian Zeindl <[hidden email]> wrote:
>> Hi,
>>
>>  I have a performance problem and observed that when constraining the filter on a large list, the resulting DELETE events aren't grouped into proper blocks anymore. Instead I get thousands of deletions at index 0.
>>
>> It this because ListEvent includes the deleted element now?
>>
>> Regards
>> Fabian
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delete ListEvent Blocks

Fabian Zeindl
I can look at things here and there, but don't have time to work on this either at the moment.

I think that the best course of action would be to pull the partial implementation, for the reasons that mauro gave.

If it doesn't get too complicated, the signalling up the chain is an interesting idea. Maybe it doesn't even have to be public API for now, but could be tailored to fix the lists that rely on the get*Value functions right now.

Could you give an overview of the problems, like where the get*Value is being used in sorting and relied upon?

And who is the current maintainer by the way, who decides which pull-requests to accept?
(Part of the reason I'm asking is that I spent some time converting the project to gradle and modularising the tests so that they work well with IntelliJ IDEA, and I would like to include that, if possible :) )


> On 6 Jan 2017, at 00:44 , Rob Eden <[hidden email]> wrote:
>
> Yes, that would probably be a good design. I'd love to play with it, but my todo list is a bit long at the moment. I'll play with it as soon as I can, but feel free to beat me to the punch if you have time.
>
> Side thought: From a performance standpoint, something I was considering what allowing the list pipeline to signal up the chain what features were needed. For example, tracking of old values could be skipped until something down the chain requested it. So, if a list type needs that information to function, it could signal the source which could enable up the chain if needed. This would obviously be a significant rework though.
>
> On Thu, Jan 5, 2017 at 12:54 AM Fabian Zeindl <[hidden email]> wrote:
> Would it be possible to provide the values in grouped changes as an Iterable?
>
> > On 4 Jan 2017, at 22:09 , Rob Eden <[hidden email]> wrote:
> >
> > Thanks, Mauro. Those links are very helpful.
> >
> > Personally, I (theoretically) agree with reverting the changes as there has been a huge performance impact. However, one thing that was difficult to determine was the full impact of pulling the partial implementation. There is quite a bit of usage of the get*Value() methods, particularly in sorting, if memory serves.
> >
> > In earlier experiments I was attempting to swap out the BlockSequence implementation used in the ListEventAssembler. I think doing something like that might allow for faster/lower feature implementations versus slower/more full-featured implementations. The problem that causes is handling the absence of the values in ListEvents in a graceful way. Without knowing the full impact of removing them (which I hadn't gotten around to analyzing yet), that's difficult to plan.
> >
> > I have an experimental (and broken!) implementation here, if you're curious: https://github.com/robeden/glazedlists/tree/LinkedNodeBlockSequence
> > The main problem is that I hadn't realized that delivery indices had to be ordered. Once I found that I got sidetracked and haven't gotten back to it yet.
> >
> > On Wed, Jan 4, 2017 at 11:57 AM Mauro Molinari <[hidden email]> wrote:
> > Please also see: https://java.net/jira/browse/GLAZEDLISTS-519
> >
> > I still think that, given the challenges of implementing the get*Value() methods for all EvenLists and the issues it causes, doing a partial rollback and changing the approach to this problem would be the best choice, as I wrote here: https://java.net/jira/browse/GLAZEDLISTS-253?focusedCommentId=362782&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-362782
> >
> > After all, we are in 2017 and GLAZEDLISTS-253 has not yet been completed, while issues like GLAZEDLISTS-519 and GLAZEDLISTS-576 are effective :-)
> >
> >
> > Mauro
> >
> >
> > Il 04/01/2017 18:28, Rob Eden ha scritto:
> >> This is the problem: https://java.net/jira/browse/GLAZEDLISTS-576
> >>
> >> I've worked around it in a couple horrible ways in places. Here's one:
> >> https://bitbucket.org/robeden/glazedlists-vaadin-container/src/b93a6f986e41df3f74005b628f9e1af8ef4efa6f/src/main/java/com/starlight/vaadin/glazedlists/EventListContainerInvocationHandler.java?at=master&fileviewer=file-view-default
> >>
> >> See ImmediateDispatchingListener.canJoinEvent(...)
> >>
> >> I've casually experimented with a better dispatching implementation which could deal with values better (in core GL) but don't have anything ready for primetime. Support for ListEvent.get*Value() methods is what broke blocking and unfortunately the fix isn't trivial.
> >>
> >>
> >>
> >> On Wed, Jan 4, 2017 at 8:22 AM Fabian Zeindl <[hidden email]> wrote:
> >> Hi,
> >>
> >>  I have a performance problem and observed that when constraining the filter on a large list, the resulting DELETE events aren't grouped into proper blocks anymore. Instead I get thousands of deletions at index 0.
> >>
> >> It this because ListEvent includes the deleted element now?
> >>
> >> Regards
> >> Fabian
> >
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delete ListEvent Blocks

robeden
I think that the best course of action would be to pull the partial implementation, for the reasons that mauro gave.

Could you give an overview of the problems, like where the get*Value is being used in sorting and relied upon?

This will be the trick. I don't know that anyone would know all the possible interactions at this point.


And who is the current maintainer by the way, who decides which pull-requests to accept?
(Part of the reason I'm asking is that I spent some time converting the project to gradle and modularising the tests so that they work well with IntelliJ IDEA, and I would like to include that, if possible :) )

There are several of us that have the ability to commit (myself included). Holger has been lead for quite a while and since he expressed hesitation at switching to gradle, I'm deferring to him on that topic. Maybe poke him on the dev list?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delete ListEvent Blocks

Fabian Zeindl

> On 6 Jan 2017, at 16:06 , Rob Eden <[hidden email]> wrote:
>
> This will be the trick. I don't know that anyone would know all the possible interactions at this point.

The usages that my IDE shows me don't seem to be that many.
I think mainly SortedList uses it in a complicated way, like you said.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delete ListEvent Blocks

hbrands
Administrator
In reply to this post by robeden
Hey guys,

I'm still alive ;-)
Sorry for being mostly dormant with respect to Glazed Lists in 2016,
but our newborn cute little daughter got most of our attention. ;-)

I think Jesse, James, Rob and I were the last core committers.
But currently, only Rob and I are more or less active.

With respect to switching to Gradle:
I wanted to give other contributors the chance to express their preference.
But we got no more votes, so if Rob and Fabian favour Gradle I'm ok with that.

But first, let's get version 1.10 done and released with the old build.
I didn't finish the issue migration yet, but I'll get my hands dirty soon again and want to complete it for 1.10.

After the 1.10 release we can concentrate on and plan the project structure changes,
for example I'd like to move the Issue Browser and other sample code to a new Github project like glazedlists-samples.
I'd aim for a 1.11 release following not long after the 1.10 release with a focus on renewing the build system.
(Remember, on April 28, 2017 java.net goes down and we should grab our dependencies from Maven Central by then)
Let's discuss these things on the dev list.

I hope this makes sense for you.

Holger



2017-01-06 16:06 GMT+01:00 Rob Eden <[hidden email]>:
I think that the best course of action would be to pull the partial implementation, for the reasons that mauro gave.

Could you give an overview of the problems, like where the get*Value is being used in sorting and relied upon?

This will be the trick. I don't know that anyone would know all the possible interactions at this point.


And who is the current maintainer by the way, who decides which pull-requests to accept?
(Part of the reason I'm asking is that I spent some time converting the project to gradle and modularising the tests so that they work well with IntelliJ IDEA, and I would like to include that, if possible :) )

There are several of us that have the ability to commit (myself included). Holger has been lead for quite a while and since he expressed hesitation at switching to gradle, I'm deferring to him on that topic. Maybe poke him on the dev list?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delete ListEvent Blocks

Fabian Zeindl
Hi Holger,

 congratulation about your newborn!

Regarding the switch to gradle: Thing is, t's not really finished. Dependency-download, compiling, building modularised jars and testing works,
but I didn't include some features the old build-system had, like writing the OSGI-bundle or uploading to maven, because I wasn't sure whether they are still needed.

About 1.10: I spend today looking into the various bugs in Grouper.java and also found a couple of new ones. I have a fix for some of them, but not for others.

I tried fixing everything, but I think it's impossible with the current implementation. Maybe I misunderstand something essential about the algorithm, but I do believe that it's rather buggy when it comes to batched events. Variables not containing what they say they contain, groups switching from the right-side to the right-side, two different meaning of NO_GROUP and so on.

I'm thinking about rewriting the listUpdated method to use just one pass, but would like to know why it's even written in two passes, whether there's something fundamental I overlooked in terms of performance.

fabian

> On 7 Jan 2017, at 22:14 , Holger Brands <[hidden email]> wrote:
>
> Hey guys,
>
> I'm still alive ;-)
> Sorry for being mostly dormant with respect to Glazed Lists in 2016,
> but our newborn cute little daughter got most of our attention. ;-)
>
> I think Jesse, James, Rob and I were the last core committers.
> But currently, only Rob and I are more or less active.
>
> With respect to switching to Gradle:
> I wanted to give other contributors the chance to express their preference.
> But we got no more votes, so if Rob and Fabian favour Gradle I'm ok with that.
>
> But first, let's get version 1.10 done and released with the old build.
> I didn't finish the issue migration yet, but I'll get my hands dirty soon again and want to complete it for 1.10.
>
> After the 1.10 release we can concentrate on and plan the project structure changes,
> for example I'd like to move the Issue Browser and other sample code to a new Github project like glazedlists-samples.
> I'd aim for a 1.11 release following not long after the 1.10 release with a focus on renewing the build system.
> (Remember, on April 28, 2017 java.net goes down and we should grab our dependencies from Maven Central by then)
> Let's discuss these things on the dev list.
>
> I hope this makes sense for you.
>
> Holger
>
>
>
> 2017-01-06 16:06 GMT+01:00 Rob Eden <[hidden email]>:
> I think that the best course of action would be to pull the partial implementation, for the reasons that mauro gave.
>
> Could you give an overview of the problems, like where the get*Value is being used in sorting and relied upon?
>
> This will be the trick. I don't know that anyone would know all the possible interactions at this point.
>
>
> And who is the current maintainer by the way, who decides which pull-requests to accept?
> (Part of the reason I'm asking is that I spent some time converting the project to gradle and modularising the tests so that they work well with IntelliJ IDEA, and I would like to include that, if possible :) )
>
> There are several of us that have the ability to commit (myself included). Holger has been lead for quite a while and since he expressed hesitation at switching to gradle, I'm deferring to him on that topic. Maybe poke him on the dev list?
>

Loading...