Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Calling schedule in a Timer's constructor

Reply
Thread Tools

Calling schedule in a Timer's constructor

 
 
Philipp
Guest
Posts: n/a
 
      02-23-2009
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
 
Reply With Quote
 
 
 
 
Giovanni Azua
Guest
Posts: n/a
 
      02-23-2009
Hi Philipp,

"Philipp" <(E-Mail Removed)> wrote
> [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


 
Reply With Quote
 
 
 
 
blue indigo
Guest
Posts: n/a
 
      02-23-2009
On Mon, 23 Feb 2009 10:05:59 +0100, Giovanni Azua wrote:

> Hi Philipp,
>
> "Philipp" <(E-Mail Removed)> wrote
>> [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.

--
blue indigo
UA Telecom since 1987
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      02-23-2009
Philipp wrote:
> 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());
}

}
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      02-23-2009
On Feb 23, 3:37*am, Philipp <(E-Mail Removed)> wrote:
> 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.

--
Lew
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
A constructor calling another constructor (default constructor)? Generic Usenet Account C++ 10 11-28-2007 04:12 AM
Calling another constructor from a constructor Asfand Yar Qazi C++ 6 05-17-2004 03:16 PM
java like constructor calling constructor lallous C++ 5 01-23-2004 11:52 PM
calling a constructor within a constructor Brett Irving C++ 3 06-29-2003 10:43 AM
why it's not possible calling constructor from constructor? Giulio C++ 9 06-25-2003 03:56 PM



Advertisments