Calling schedule in a Timer's constructor

[Philipp]

Hello
I just wanted to know if it is acceptable (from a threading and
synchronization perspective) to schedule a task within a Timer's
constructor. Example:

public final class SaveTimer extends Timer {
private static final long period = 60000L;
public SaveTimer() {
scheduleAtFixedRate(new SaverTimerTask(), period, period); // OK?
}

private static class SaverTimerTask extends TimerTask {
public void run() {
// do the save here
}
}
}

Thanks Phil
PS: I'm using JVM 1.3, so the old memory model

 

[Giovanni Azua]

Hi Philipp,

[snip] if it is acceptable (from a threading and
synchronization perspective) to
public final class SaveTimer extends Timer {

By making SaveTimer final I think you have wisely removed all threats.

best regards,
Giovanni

 

[blue indigo]

Hi Philipp,

[snip] if it is acceptable (from a threading and
synchronization perspective) to
public final class SaveTimer extends Timer {

By making SaveTimer final I think you have wisely removed all threats.

Calling an overridable method from a constructor is evil. The key word is
"overridable". If the class (or just the method) is final, or the method
is static or private, the evil goes away.

As usual, Sun provides a what-not-to-do example in the core API:
java.util.Random's constructor calls setSeed(), which is overridable.

Besides making SaveTimer final, evil was also avoidable in this case by
making just the method final. The java.util.scheduleAtFixedRate() methods
are not final, but SaveTimer could contain an override for the one it uses
that is final and whose body is simply a call-super.

If it ever becomes necessary to extend SaveTimer, it's unlikely that
scheduleAtFixedRate will need to be overridable, so this becomes a viable
alternative.

On the other hand, the non-overridability of the timer automatically
setting itself up and running when constructed might be undesired then.

I'm not clear why the OP didn't simply instantiate a plain Timer somewhere
and call its scheduleAtFixedRate method with an appropriate anonymous
inner class and a period (maybe user-configurable, instead of hardwired to
once every minute).

I think the design has issues, but they are entirely unrelated to
the area of calling a method from a constructor.

 

[Daniel Pitts]

Hello
I just wanted to know if it is acceptable (from a threading and
synchronization perspective) to schedule a task within a Timer's
constructor. Example:

public final class SaveTimer extends Timer {
private static final long period = 60000L;
public SaveTimer() {
scheduleAtFixedRate(new SaverTimerTask(), period, period); // OK?
}

private static class SaverTimerTask extends TimerTask {
public void run() {
// do the save here
}
}
}

Thanks Phil
PS: I'm using JVM 1.3, so the old memory model

Why extend Timer at all?
Anyway, if you need to start the timer as part of the initialization of
the SaveTimer class, then I suggest using a static factory method:

public class SaveTimerTask extends TimerTask {
private SaveTimerTask() {
}

public static Timer createSaveTimer() {
Timer timer = new Timer();
createSaveTimer(timer);
return timer;
}

public static void createSaveTimer(Timer timer) {
timer.scheduleAtFixedRate(new SaveTimerTask());
}

}

 

[Lew]

Hello
I just wanted to know if it is acceptable (from a threading and
synchronization perspective) to schedule a task within a Timer's
constructor. Example:

public final class SaveTimer extends Timer {
  private static final long period = 60000L;
  public SaveTimer() {
    scheduleAtFixedRate(new SaverTimerTask(), period, period); // OK?
  }

  private static class SaverTimerTask extends TimerTask {
    public void run() {
      // do the save here
    }
  }

}

PS: I'm using JVM 1.3, so the old memory model

I would avoid this. The fact that it made you nervous should've
already been a clue.

The key is in the 'SaverTimerTask#run()' method and what it does,
which you do not show us. It is possible that it is safe to run the
task from the outer class constructor, but why do you need to? Why
not just restrict the constructor to construction and run the task
from a method?

Java 1.3 is the dead version of Java that precedes the dead version of
Java that precedes the dying version of Java, as I'm sure you're
aware. No doubt you have a really, really, really good reason to use
it.