• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

comparable interface help?

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, I'm making a program comparing heights using a compareTo() method and using comparable interface for the first time. I keep getting the error message "Height is not abstract and does not override abstract method compareTo(Height) in Comparable" and I just don't know why! Here's my code, and I would love help!


thanks!
 
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The problem is that Java is case-sensitive. Comparable has a method compareTo that you need to implement, but you've implemented a method CompareTo.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Taylor Thibodeaux wrote:Hi, I'm making a program comparing heights using a compareTo() method and using comparable interface for the first time. I keep getting the error message "Height is not abstract and does not override abstract method compareTo(Height) in Comparable" and I just don't know why! Here's my code, and I would love help!


thanks!



Java is case sensitive -- and the name of your method versus the case of the name of the method required by the Comparable interface, don't match.

Henry
 
Taylor Thibodeaux
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh wow. Such a simple and overlooked fix. Thanks to both of you for the lightning fast reply! I was starting to get worried.
 
Taylor Thibodeaux
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One more small problem, sorry heheh. I made a separate "Sorting" class that gets input from a txt file and outputs it onto another. In this class, it stores the height values in an array list. When I look at the new text file it generates, all the values are 0, even though the original text file had distinct single digit height numbers. I'm not even sure why an exception is not being thrown that was written in the original height class when both values are zero either. The feet and inches variables are correctly using the values, but its not making a height object correctly, and im not sure why.
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The constructor that starts at line 25 never assigns any values.

Also, not a compiler error, but isn't 12 inches equal to 1 foot? So shouldn't the check be i >= 12 instead of i > 12?
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
By the way, you can simplify your compareTo method. It doesn't have to return 1 or -1 depending on the order, it just needs to return a position or negative integer. So this bit:
can be replaced by this:

And you can do something similar with the feet. In fact, given the constraint on inches you can actually just write the entire method as:
 
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, you might want to make that
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If these are heights of people, it's seriously unlikely to matter .

Taylor - what Stephan's getting at (I assume) is that if the value of feet gets very large, feet*12 could possibly get too large to fit into an int variable. In that case you'll get an "overflow", and unexpected results. Converting it to a long first, and then only converting the final value back to an int, will avoid that problem in some cases. But not all (e.g. feet very large and h.feet very small), so if there was any danger of overflow that I'd actually go back to comparing them separately.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Taylor Thibodeaux wrote:Oh wow. Such a simple and overlooked fix. Thanks to both of you for the lightning fast reply! I was starting to get worried.


Note: The @Override annotation exists exactly to catch errors such as this one. If you would have used it, the compiler would have given you an error: "The method CompareTo does not override a superclass method".

 
Stephan van Hulst
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Matthew Brown wrote:If these are heights of people, it's seriously unlikely to matter .

Taylor - what Stephan's getting at (I assume) is that if the value of feet gets very large, feet*12 could possibly get too large to fit into an int variable. In that case you'll get an "overflow", and unexpected results. Converting it to a long first, and then only converting the final value back to an int, will avoid that problem in some cases. But not all (e.g. feet very large and h.feet very small), so if there was any danger of overflow that I'd actually go back to comparing them separately.



Actually, it will work for all cases, because feet is cast to long, and afterwards the rest of the operands will be promoted to long automatically.

But yeah, people are unlikely to get that tall. It's not a good reason not to write robust code, though :P
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Actually, it will work for all cases, because feet is cast to long, and afterwards the rest of the operands will be promoted to long automatically.



I know. But what if the final result is too big to be cast back to an int accurately? E.g. feet = Integer.MAX_VALUE, and all the other values are zero?
 
Stephan van Hulst
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Woops. Let's make that:
reply
    Bookmark Topic Watch Topic
  • New Topic