#8 HashList Patch

closed-fixed
None
1
2010-07-08
2010-06-18
James Kosin
No

This patch fixes an issue with put() conflicting with put() for Hash.
@Override is not sufficiant even though the error suggests that an override would work.

The problem is one cannot override the other because of the conflict in the return type. And the two parameters are almost identical... although the one for Hash is a List<V> parameter for V to the template.
When the compiler tries to compile this, especially with NetBeans 6.9 an error is generated.

This fixes that by renaming put() to add() and adjusting the other classes that use the HashList appropriately.

Tested by James Kosin

Discussion

  • Joern Kottmann
    Joern Kottmann
    2010-06-18

    Just compiled it with a sun java 1.6 compiler, eclipse can also compile it with the compiler set to java 1.5 and 1.6.

    Which compiler do you use exactly ? Is netbeans just calling the compiler in the jdk ? Which java version do you use ? And what is the error the compiler outputs exactly ?

    Jörn

     
  • James Kosin
    James Kosin
    2010-06-19

    I'm using NetBeans 6.9 on a 64-bit machine running Windows 7 and using the 64-bit JDK 1.6.0_20 and the JRE 64/32-bit for the same.

    The error message is below about the issue.... I've searched the problem and it happens on rare occations with some systems. It appears to be a generic error about using this type of problem. What happens seems to be if both or the entire project is compiled as a whole then the error sometimes shows up. Other tines it is like this where the @Override may be needed and sometimes the @Override is not sufficiant to fix the problem. Some have been able to fix the issue by compiling the modules separately and not as a whole project. Others have had simple mistakes like forgetting to fill the template enirely or forgetting <? extends V> type verbage.
    The message below, I sent to Jason Baldridge who posted the HashList to CVS.

    Message body follows:

    Jason,

    I updated to NetBeans 6.9 and have now gotten the following error.
    I've searched the support forums; however, this error is a bit obscure in
    nature and could be caused by a whole list of possibilites.
    Do you have experience on what the error is? and why? and how to fix?

    Thanks,
    James ... see below:

    ---
    name clash: put(K,V) in opennlp.tools.util.HashList and put(K,V) in
    java.util.HashMap have the same erasure, yet neither overrides the
    other
    ---

    --
    This message has been sent to you, a registered SourceForge.net user,
    by another site user, through the SourceForge.net site. This message
    has been delivered to your SourceForge.net mail alias. You may reply
    to this message using the "Reply" feature of your email client, or
    using the messaging facility of SourceForge.net at:
    https://sourceforge.net/sendmessage.php?touser=2556622

     
  • James Kosin
    James Kosin
    2010-06-19

    Here is some madness about generics (my template explaination)

    http://blog.jayway.com/2007/02/01/essential-java-generics/

    Any other information ???
    I'm willing to go with what I have now that fixes the issue for me. The error I get is with the IDE moreso than with the compiler... but, this should be fixed anyway; because we potentially have a bad construct with the implementation of the HashList if not fixed.

    James

     
  • James Kosin
    James Kosin
    2010-06-19

    Another interesting tidbit for this topic. Apperently, generics aren't as straight forward as they may seem.

    http://www.phpsolvent.com/wordpress/?p=2216

    James.

     
  • James Kosin
    James Kosin
    2010-06-19

    Another interesting tidbit for this topic. Apperently, generics aren't as straight forward as they may seem.

    http://www.phpsolvent.com/wordpress/?p=2216

    James.

     
  • James Kosin
    James Kosin
    2010-06-19

    Okay, it isn't the java compiler; but, NetBeans IDE that is complaining about the construct.
    And from the information I've been able to find.... it appears to be correct in that there is an issue with the construct.

    What appears to be happening is:
    public class HashList<K, V> extends HashMap<K, List<V>> {

    is causing two constructs...
    In HashMap and the extended classes, put() gets defined as:
    public V put(K key, V value) {
    translated to:
    public List<V> put(K key, List<V> value) {

    The function in HashList's put() gets interpreted as:
    public List<V> put(K key, V value) {

    And this function does not override the parent class properly to be interpreted as an override. It also ends up confusing the interpreter since the child class is attempting to provide an override with generics....

    Yuck. I'll have to do more homework on this.
    Thanks,
    James

     
  • James Kosin
    James Kosin
    2010-06-19

    • priority: 5 --> 1
     
  • James Kosin
    James Kosin
    2010-06-26

    The bug is making its way through the filters of passing from one entity to another right now.
    Someone else also submitted another sample that fails; however, compiles and works with java.

     
  • James Kosin
    James Kosin
    2010-06-28

    Well, I finally got word. We will have to rename the function since it is currently a bug in the compiler that it actually should not be doing. See the references below.

    http://bugs.sun.com/view_bug.do?bug_id=6182950

    I'll let you guys fight over the name if you want. I only chose add() since it made it unique... however, putEntry() may also work.

    James

     
  • James Kosin
    James Kosin
    2010-06-28

    Originial patch submitted

     
    Attachments
  • Joern Kottmann
    Joern Kottmann
    2010-06-30

    I think in our case the compiler bug does not apply.
    Through this bug its possible to define two methods where the signature only differs in the return type. In our case the methods also have different parameters.

    So the put method correctly overloads, the put method defined in the Map interface. Isn't that right ?

    Jörn

     
  • James Kosin
    James Kosin
    2010-06-30

    Jorn,

    Actually not. The parameters for the HashList are K and V, then the parameters to HashMap end up translating to K and List<V>... which makes them different. Java doesn't allow that type of function (ie: same name with different parameters). If you follow the bug report I submitted someone also generated the same errors with this case of the same function name generating the error.
    It turns out NetBeans uses the latest javac to check the code which fixes the bug in the compiler for allowing this. The sun bug report outlines documentation of the proper operation that is suppose to be followed.

    James.

     
  • Joern Kottmann
    Joern Kottmann
    2010-07-08

    Yes after looking a little further into this issue I think you are right.
    Thanks for pointing that out and doing all the research.

    We overload put(V) with a put(K) and that seems to be illegal, because when V and K have the same type its unclear which method should be called.

    Jörn

     
  • Joern Kottmann
    Joern Kottmann
    2010-07-08

    Adding generics to HashList actually broke the class as explained by James in the comments. Instead of having a different method for inserting elements into the hash list it seems better to just remove the generics from it.

    A future re-write/re-factoring of the HashList should address this issue and maybe also choose a more compact representation.

    Jörn

     
  • Joern Kottmann
    Joern Kottmann
    2010-07-08

    • assigned_to: nobody --> joernkottmann
    • status: open --> closed-fixed