Stupid Calendar Class

T

timasmith

AHHH...

I have extended Calendar and now it is complaining (depending on which
Java version I run) that

clash: compareTo(java.lang.Object) in MyCalendar and compareTo(T) in
java.lang.Comparable<java.util.Calendar> have the same erasure, yet
neither overrides the other

I only want my own version to override toString when controls are
populated with MyCalendar


public class MyCalendar extends Calendar {

private static final long serialVersionUID = 1L;
private String dateFormat = null;


public void setShortDateFormat() {
this.dateFormat = CalendarUtility.ShortDateFormat();
}

public void setLongFormat() {
this.dateFormat = CalendarUtility.LongFormat();
}

public DbCalendar() {
super();
}

public DbCalendar(TimeZone zone, Locale aLocale) {
super(zone, aLocale);
}

protected void computeTime() {
}

protected void computeFields() {
}

public void add(int field, int amount) {
this.add(field, amount);
}

public void roll(int field, boolean up) {
this.roll(field, up);
}

public int getMinimum(int field) {
return this.getMinimum(field);
}

public int getMaximum(int field) {
return this.getMaximum(field);
}

public int getGreatestMinimum(int field) {
return this.getGreatestMinimum(field);
}

public int getLeastMaximum(int field) {
return this.getLeastMaximum(field);
}

public int compareTo(Object arg0) {
return this.compareTo(arg0);
}

public String toString() {
Calendar c = Calendar.getInstance();
c.setTimeInMillis(this.getTimeInMillis());
if (dateFormat == null) {
return CalendarUtility.Format(c);
} else {
return CalendarUtility.Format(c, dateFormat);
}
}
}
 
O

Oliver Wong

AHHH...

I have extended Calendar and now it is complaining (depending on which
Java version I run) that

clash: compareTo(java.lang.Object) in MyCalendar and compareTo(T) in
java.lang.Comparable<java.util.Calendar> have the same erasure, yet
neither overrides the other

I only want my own version to override toString when controls are
populated with MyCalendar


public class MyCalendar extends Calendar {

private static final long serialVersionUID = 1L;
private String dateFormat = null;


public void setShortDateFormat() {
this.dateFormat = CalendarUtility.ShortDateFormat();
}

public void setLongFormat() {
this.dateFormat = CalendarUtility.LongFormat();
}

public DbCalendar() {
super();
}

public DbCalendar(TimeZone zone, Locale aLocale) {
super(zone, aLocale);
}

protected void computeTime() {
}

protected void computeFields() {
}

public void add(int field, int amount) {
this.add(field, amount);
}

public void roll(int field, boolean up) {
this.roll(field, up);
}

public int getMinimum(int field) {
return this.getMinimum(field);
}

public int getMaximum(int field) {
return this.getMaximum(field);
}

public int getGreatestMinimum(int field) {
return this.getGreatestMinimum(field);
}

public int getLeastMaximum(int field) {
return this.getLeastMaximum(field);
}

public int compareTo(Object arg0) {
return this.compareTo(arg0);
}

public String toString() {
Calendar c = Calendar.getInstance();
c.setTimeInMillis(this.getTimeInMillis());
if (dateFormat == null) {
return CalendarUtility.Format(c);
} else {
return CalendarUtility.Format(c, dateFormat);
}
}
}


Instead of overriding toString, use a Custom Renderer. See, for example,
http://java.sun.com/docs/books/tutorial/uiswing/components/combobox.html#renderer
(this is for JComboBox, so depending on which control you're talking about,
you may wish to use a different renderer).

Your code, as it is now, as some infinite-recursion problems. I think
instead of "this.compareTo(arg0)", for example, you mean
"super.compareto(arg0)".

- Oliver
 
V

Vova Reznik

You may extend real class GregorianCalendar
(implementation of Calendar)
and override toString only
 
J

John C. Bollinger

AHHH...

I have extended Calendar and now it is complaining (depending on which
Java version I run) that

clash: compareTo(java.lang.Object) in MyCalendar and compareTo(T) in
java.lang.Comparable<java.util.Calendar> have the same erasure, yet
neither overrides the other

I only want my own version to override toString when controls are
populated with MyCalendar

In Java 5, Calendar implements Comparable<Calendar>. That interface has
a method compareTo(Calendar), whose erasure is compareTo(Object). Your
class inherits Comparable<Calendar> from Calendar, but it also declares
a method compareTo(Object). MyCalendar.compareTo(Object) does not
override Calendar.compareTo(Calendar) because their argument types are
different, but the two methods have the same signature after type
erasure. If this were allowed then there would be cases in which the
compiler could not generate correct bytecode for MyCalendar's clients.
public class MyCalendar extends Calendar {
[...]

public int compareTo(Object arg0) {
return this.compareTo(arg0);
}

To compile in Java 5, that needs to be

public int compareTo(Calendar arg0) {
return this.compareTo(arg0);
}

Note, however, that
(1) The method implementation causes an unbounded recursion. You have
several other methods in the code you showed with the same problem.
(2) You would be better off to not override the method at all, because
there is no meaningful way you can modify the behavior of the
superclass's version without breaking the contract it defines.

[...]
 
K

Kent Paul Dolan

John C. Bollinger said:
(2) You would be better off to not override the method at all, because
there is no meaningful way you can modify the behavior of the
superclass's version without breaking the contract it defines.

Could you give more detail here?

what is that superclass's toString() method's contract,
and why can't the OP override that method without
breaking that contract?

xanthian.
 
J

John C. Bollinger

Kent said:
Could you give more detail here?

what is that superclass's toString() method's contract,
and why can't the OP override that method without
breaking that contract?

I was talking about compareTo(Calendar), the method that was causing the
OP trouble, not about toString(). Calendar.compareTo(Calendar)'s docs
specifically say that the the return value is determined by the time
represented by the argument and by the invocation target. Frankly, I'm
not sure why the OP had attempted to override compareTo() anyway, given
that the only stated purpose of the subclass was to customize the return
value of toString().
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,262
Messages
2,571,056
Members
48,769
Latest member
Clifft

Latest Threads

Top