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

Uwe Schindler edited comment on LUCENE-1935 at 10/1/09 4:16 PM:
----------------------------------------------------------------

By the way, the covariant overload is optimized away by the compiler (not the 
JVM), if an anonymous or private (and therefore final) class is used. This is 
the code from the test:

{code}
private static class IntegerQueue extends PriorityQueue<Integer> {
    public IntegerQueue(int count) {
        super();
        initialize(count);
    }

    protected boolean lessThan(Integer a, Integer b) {
        return (a < b);
    }
}
{code}

Is compiled to the following code by Java 1.5 javac:

{code}
private static class TestPriorityQueue$IntegerQueue extends PriorityQueue {

    protected boolean lessThan(Object a, Object b) {
        return ((Integer)a).intValue() < ((Integer)b).intValue();
    }

    public TestPriorityQueue$IntegerQueue(int count) {
        initialize(count);
    }
}
{code}

So normal usage in Lucene would have no impact (would be the same as before). 
Only if you override a generified PQ with a lessThan method not final or 
somehow accessible, the compiler has to add the wrapper.

*edit:*

If you want to see, what I mean with "wrapper", look into 
[https://issues.apache.org/jira/secure/attachment/12418140/AttributeSource.jad] 
and there in getAttributeImplIterator(). The inline Iterator overrides next(), 
but the return type is generic -> compiler adds a "volatile" method (how JAD 
identifies it).

      was (Author: thetaphi):
    By the way, the covariant overload is optimized away by the compiler (not 
the JVM), if an anonymous or private (and therefore final) class is used. This 
is the code from the test:

{code}
private static class IntegerQueue extends PriorityQueue<Integer> {
    public IntegerQueue(int count) {
        super();
        initialize(count);
    }

    protected boolean lessThan(Integer a, Integer b) {
        return (a < b);
    }
}
{code}

Is compiled to the following code by Java 1.5 javac:

{code}
private static class TestPriorityQueue$IntegerQueue extends PriorityQueue {

    protected boolean lessThan(Object a, Object b) {
        return ((Integer)a).intValue() < ((Integer)b).intValue();
    }

    public TestPriorityQueue$IntegerQueue(int count) {
        initialize(count);
    }
}
{code}

So normal usage in Lucene would have no impact (would be the same as before). 
Only if you override a generified PQ with a lessThan method not final or 
somehow accessible, the compiler has to add the wrapper.
  
> Generify PriorityQueue
> ----------------------
>
>                 Key: LUCENE-1935
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1935
>             Project: Lucene - Java
>          Issue Type: Task
>          Components: Other
>    Affects Versions: 2.9
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 3.0
>
>         Attachments: LUCENE-1935.patch
>
>
> Priority Queue should use generics like all other Java 5 Collection API 
> classes. This very simple, but makes code more readable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to