where getYear() returns an int it doesn't compile because of this:
JukeBoxTester.java:84: int cannot be dereferenced return disc1.getYear().compareTo(disc2.getYear()); ^ 1 error
The integer class has a compareTo method so I really have no idea what is going on.
Anyone have any idea (I'm sure it's simple )?
As always, Thanks ahead of time.
Teaching yourself anything is always the cheapest way, but it definitely takes a lot of time and effort.<br /> <br />Thank you javaranch <a href="http://"http://faq.javaranch.com/view?HowToAskQuestionsOnJavaRanch"" target="_blank" rel="nofollow">Learn How to Ask Your Question</a> and be nice
The Integer class has a compareTo method, but you are comparing primitive int values. Either you must wrap the two int values as Integer values, or you have to implement the compareTo method in your class to compare primitive int values.
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
Originally posted by Craig Tyler: if getTitle returns an int, it's returning a primitive, not an object. Thus, you cannot use compareTo as primitives don't have methods.
However, you could do the following:
With this, you call compareTo on an object and disc2.getYear() gets autowrapped into an Integer (1.5 only. Otherwise, you have to wrap it yourself)
EDIT: The following would also be legal:
[ January 29, 2006: Message edited by: Craig Tyler ]
I think this is not the best way to implement the compareTo() method when comparing primitive values. (I think you have a handle on the difference between Objects and primitives now.) A common way to do this is by subtracting the two values:
Notice that this will fulfill the contract of the compareTo() method:
if disc1.getYear() == disc2.getYear() then the return value is zero if disc1.getYear() < disc2.getYear() then the return value is negative if disc1.getYear() > disc2.getYear() then the return value is positive
This also avoids the overhead of creating extra objects. Besides, I'm willing to bet that this is exactly how Integer.compareTo() is implemented anyway.
Ya it is, or at least that's the way I read it. Thanks, I'm sure that'll work too and I think it looks nicer
Ya, it all came down to the fact that for some reason I never realized that a small I integer, as in an int, wasn't the same as a uppercase I Integer, and in a new Integer(). It should have been clear to me, but it clearly wasn't [ January 31, 2006: Message edited by: Nicholas Carrier ]