[jira] Created: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

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

[jira] Created: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org
PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
------------------------------------------------------------------------------------------------------------------------

                 Key: LUCENE-2953
                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
             Project: Lucene - Java
          Issue Type: Bug
            Reporter: Hoss Man


as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LUCENE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man updated LUCENE-2953:
-----------------------------

    Attachment: LUCENE-2953.patch

patch to TestPriorityQueue demonstrating bug

> PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2953
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003852#comment-13003852 ]

Dawid Weiss commented on LUCENE-2953:
-------------------------------------

There seems to be no consensus on how to deal with generic arrays. Even the JDK has two different implementations -- one in ArrayDeque (uses T[]), the other in ArrayList (uses Object[]). Creating an array of a given component type is (can be?) more costly than keeping an array Object[] because it needs to be done via call to Array.newArray (haven't checked though). Theoretically having a concrete-type array should speed up iterators (because no additional casts are needed), but I don't think this is the case.

In fact, I just wrote a simple Caliper benchmark that compares these (attached), my results show the runtime times is nearly identical (probably within stddev).:

{noformat}
 0% Scenario{vm=java, trial=0, benchmark=Generic, size=1000000} 8985430.93 ns; σ=257329.28 ns @ 10 trials
33% Scenario{vm=java, trial=0, benchmark=GenericSubclass, size=1000000} 8989486.27 ns; σ=207151.20 ns @ 10 trials
67% Scenario{vm=java, trial=0, benchmark=Object, size=1000000} 8767324.34 ns; σ=218235.97 ns @ 10 trials

      benchmark   ms linear runtime
        Generic 8.99 =============================
GenericSubclass 8.99 ==============================
         Object 8.77 =============================

vm: java
trial: 0
size: 1000000
{noformat}

> PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2953
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LUCENE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dawid Weiss updated LUCENE-2953:
--------------------------------

    Attachment: BenchmarkArrayAccess.java

A Google Caliper benchmark comparing iteration over a class with a generic T[] (real T[] type), its concrete-type subclass and a class using Object[] and (T) casts for accessing array elements.

> PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2953
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: BenchmarkArrayAccess.java, LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003868#comment-13003868 ]

Uwe Schindler commented on LUCENE-2953:
---------------------------------------

The easy and most simply way to handle this is osing Object[] like in ArrayList.

The problem with then always casting from Object to T is thousands of unchecked warnings in PriorityQueue. I would propose the following:
In general the final T[] heap variable should be private to the PQ and used only there. For performance yonik wanted the heap[] protected and that caused the issue. As long as the heap[] array is private it can never be accessed incorrectly.

So my proposal is to internally use the T[] as a private field and simply use another Object[] thats protected (pointing to the same array). This would fix the problem. The most correct idea would be to add a setHeapSlot(int, T o) and T getHeapSlot(int) method and hiding the T[] heap completely, but I know, Yonik will disagree :-)

There is some other problem: the heap array should be final, but it cannot, because of the stupid initialize() method. I would like to remove this method and simply move the code to PQ's ctor. I don't understand why the initialize() method is there, which is a problem: Every guide on Java programming tells you to never call protected overrideable methods from ctors, as this can break easily. If the heap[] is final, the problem of having two references to the same object is not a problem anymore.

> PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2953
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: BenchmarkArrayAccess.java, LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003873#comment-13003873 ]

Dawid Weiss commented on LUCENE-2953:
-------------------------------------

> The problem with then always casting from Object to T is thousands of unchecked warnings in PriorityQueue.

You could erase the type in internal methods of PriorityQueue and use Object instead of T then.

> So my proposal is to internally use the T[] as a private field and simply use another Object[] thats protected (pointing to the same array).

Or a protected getter method that would do the cast (why bother with having two fields):
{noformat}
protected Object[] getStorageArray() { return (Object[]) heap; }
{noformat}
If Yonik wants access to that array I'm sure he copies it to a local var. prior to doing any intensive loops...

> PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2953
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: BenchmarkArrayAccess.java, LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003876#comment-13003876 ]

Uwe Schindler commented on LUCENE-2953:
---------------------------------------

bq. Or a protected getter method that would do the cast (why bother with having two fields)

Good idea, I am currently fixing the whole stuff (I was the one who added the generics in Lucene 3.0). But I am now also removing initialize(int), this construct is very broken. In trunk we can break backwards for this.

> PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2953
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: BenchmarkArrayAccess.java, LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003878#comment-13003878 ]

Dawid Weiss commented on LUCENE-2953:
-------------------------------------

I remember using pq at some point for other things and hating that initialize method, so I'm all for it.

> PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2953
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: BenchmarkArrayAccess.java, LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LUCENE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler updated LUCENE-2953:
----------------------------------

    Attachment: LUCENE-2953.patch

Here my patch, that also removes initialize(int), which is bad design.

For 3.x we can simply leave out this change and only make the heap variable private and expose as Object[] using a getter method.

> PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2953
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: BenchmarkArrayAccess.java, LUCENE-2953.patch, LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003882#comment-13003882 ]

Uwe Schindler commented on LUCENE-2953:
---------------------------------------

bq. I remember using pq at some point for other things and hating that initialize method, so I'm all for it.

The inititalize method was only there for one single reason in Lucene (a hack). The getSentinelObject() method was used in HitQueue in a very special way: it should return null for some special case. To enable this special case, a boolean field was used. But the ctor had to populate that field before the prepoulating was done, and thats impossible. I changed that by adding a boolean ctor to the PQ base class to enable/disable pre-populating like HitQueue did before.

> PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2953
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: BenchmarkArrayAccess.java, LUCENE-2953.patch, LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Issue Comment Edited: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003882#comment-13003882 ]

Uwe Schindler edited comment on LUCENE-2953 at 3/8/11 9:58 AM:
---------------------------------------------------------------

bq. I remember using pq at some point for other things and hating that initialize method, so I'm all for it.

The inititalize method was only there for one single reason in Lucene (a hack): The getSentinelObject() method was used in HitQueue like that: it should return null for some special corner case. To enable this special case, a boolean field was used. But the ctor had to populate that field before the prepoulating in super() was done, and thats impossible. I changed that by adding a boolean ctor to the PQ base class to enable/disable pre-populating like HitQueue did before.

      was (Author: thetaphi):
    bq. I remember using pq at some point for other things and hating that initialize method, so I'm all for it.

The inititalize method was only there for one single reason in Lucene (a hack). The getSentinelObject() method was used in HitQueue in a very special way: it should return null for some special case. To enable this special case, a boolean field was used. But the ctor had to populate that field before the prepoulating was done, and thats impossible. I changed that by adding a boolean ctor to the PQ base class to enable/disable pre-populating like HitQueue did before.
 

> PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2953
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: BenchmarkArrayAccess.java, LUCENE-2953.patch, LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LUCENE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler updated LUCENE-2953:
----------------------------------

    Fix Version/s: 4.0
                   3.2
         Assignee: Uwe Schindler

> PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2953
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Hoss Man
>            Assignee: Uwe Schindler
>             Fix For: 3.2, 4.0
>
>         Attachments: BenchmarkArrayAccess.java, LUCENE-2953.patch, LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004431#comment-13004431 ]

Uwe Schindler commented on LUCENE-2953:
---------------------------------------

Committed trunk revision: 1079707

I will backport the getHeapArray() method to 3.2, but for now this is not a problem, as Solr's class is not yet generified in 3.x.

> PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2953
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Hoss Man
>            Assignee: Uwe Schindler
>             Fix For: 3.2, 4.0
>
>         Attachments: BenchmarkArrayAccess.java, LUCENE-2953.patch, LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Resolved: (LUCENE-2953) PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LUCENE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler resolved LUCENE-2953.
-----------------------------------

       Resolution: Fixed
    Lucene Fields: [New, Patch Available]  (was: [New])

Committed 3.x revision: 1079711 (only private heap and getter, initialize unchanged for backwards compatibility).

If we want to backport also the initialize() changes to 3.x (as PQ is a @lucene.internal class), we should reopen this issue.

> PriorityQueue is inheriently broken if subclass attempts to use "heap" w/generic T bound to anything other then "Object"
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2953
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2953
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Hoss Man
>            Assignee: Uwe Schindler
>             Fix For: 3.2, 4.0
>
>         Attachments: BenchmarkArrayAccess.java, LUCENE-2953.patch, LUCENE-2953.patch
>
>
> as discovered in SOLR-2410 the fact that the protected "heap" variable in PriorityQueue is initialized using an Object[] makes it impossible for subclasses of PriorityQueue to exist and access the "heap" array unless they bind the generic to Object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]