Using Calender.getInstance() for getting system time, how can I autoupdate?

[Jay Orsaw]

Hello all!

I've been looking for a way to auto-update the time. I was thinking of maybe just comparing the current time to the original time and just keep updating every second, but I'm not sure if that's the best way to approach this....

Also, since I'm using JavaFX, I was thinking of maybe using the "Animation class" but not too sure if that's needed either....

Any help or insight to figuring this out is much appreciated...

Thanks!

~JO

[Jeff Verdegan]

You could use a java.util.Timer and java.util.TimerTask to update the time once per second.

[Jay Orsaw]

Jeff Verdegan wrote:You could use a java.util.Timer and java.util.TimerTask to update the time once per second.

Just found my way to the Timer class, a min ago :p. Thanks a lot Jeff, I will check it out!


EDIT: Ooooo Interestingly enough I found this tidbit of info inside the "Timer" class

Java 5.0 introduced the java.util.concurrent package and one of the concurrency utilities therein is the ScheduledThreadPoolExecutor which is a thread pool for repeatedly executing tasks at a given rate or delay. It is effectively a more versatile replacement for the Timer/TimerTask combination, as it allows multiple service threads, accepts various time units, and doesn't require subclassing TimerTask (just implement Runnable). Configuring ScheduledThreadPoolExecutor with one thread makes it equivalent to Timer.

It seems like it's "main" purpose is to be able to unload "multiple" things at a certain interval, at once, but still says that it's a better replacement than the Timer/TimerTak combo? Thoughts on this?

[Jeff Verdegan]

I think for something as simple as what you're doing, it might be simpler to use Timer and TimerTask, but the java.util.concurrent approach isn't particularly complex either.

And it might be that the newer solution will give you more consistent timing. I don't have any specific reason to believe that's the case, but if they were going to put effort in that direction, it would go toward the newer class.

My advice is to pick one, get it working, then replace it with the other one, so that you get a feel for both.

[Jay Orsaw]

Okay, so I tried using the ScheduledThreadPoolExecutor, and it worked great! The only issue is that I'm having trouble updating the calender.

NOTE: Lambda expressions are used as "->" so runnable and run have been removed. I am also using JavaFX

ublic class Timer extends Application
{
  //  Timer t = new Timer();
    Calendar rightNow =  Calendar.getInstance();
    @Override
    public void start(Stage primaryStage)
    {
        Button btn = new Button();
        
         ScheduledThreadPoolExecutor stpe = new ScheduledThreadPoolExecutor(1);
		System.out.println(stpe.getCorePoolSize());
		
                stpe.scheduleAtFixedRate(() -> {
                               btn.setText("" + rightNow.getTime());
                               System.out.println(rightNow.getTime());
   //rightNow = Calendar.getInstance();
                },0, 1,TimeUnit.SECONDS);
                
        btn.setOnAction((ActionEvent event) -> {
          //  rightNow = Calendar.getInstance();
        });
        
        StackPane root = new StackPane();
        root.getChildren().add(btn);
        
        Scene scene = new Scene(root, 300, 250);
        
        primaryStage.setTitle("Hello World!");
        primaryStage.setScene(scene);
        primaryStage.show();
    }

Basically if I run it normally it will just return the instance at that one second, and wont update with rightNow.getTime() and will just pop out the same time constantly.

If I try to set

   rightNow = Calendar.getInstance();

inside the setFixedRate it wont run the scheduler, and if I click the button after I've seen it update the instance a few times, it will then stop right away.

Why exactly is my ScheduledThreadPoolExecutor breaking when I'm getting my instance? Is there another way I should go about this maybe?

[Pat Farrell]

I see this as having a philosophical loop. How do you update the time every second, when you don't know what a second is? If you could set an interrupt every second, seems to me that you are already done.

And, of course, you are NOT suposed to to update the Calender.getInstance(), instead you should get a new instance every second.

[Jay Orsaw]

Pat Farrell wrote:I see this as having a philosophical loop. How do you update the time every second, when you don't know what a second is? If you could set an interrupt every second, seems to me that you are already done.


And, of course, you are NOT suposed to to update the Calender.getInstance(), instead you should get a new instance every second.

I also made a cross post here

https://forums.oracle.com/forums/thread.jspa?threadID=2516151&tstart=0


I passed out before I could say it, but yeah I tried rightNow.add(Calender.SECOND,1); and if put inside the loop crashes, if outside will add a second and that's all... rightNow.set(Calender.SECOND,10); also works, but only outside the loop.

At first I thought the Instance wasn't working correctly, but it seems it's my Scheduled loop.

I also tried just doing Calender rightNow = Calender.getInstance(); inside the look, that would keep creating new instances right?

It seems that anything having to do with "rightNow" in the loop crashes it. I'm not too sure why.

EDIT: So it seems that I needed to run it on the FXThread.... but isn't doing

stpe.scheduleAtFixedRate(() -> {
   Platform.runLater( () -> {
     rightNow = Calendar.getInstance();      
     btn.setText("" + rightNow.getTime());
     System.out.println(rightNow.getTime());
   }
},0, 1,TimeUnit.SECONDS);

updating the instance, or is this creating a new one each time?


Also is it weird that the first time I ran it, the 1st "second" marker was the same as the 2nd "second" marker, "i.e., 5:33:03 happened twice" then it went to :04,05, etc... The second time I ran it, it was fine... Thoughts?

[Pat Farrell]

Jay Orsaw wrote:I also tried just doing Calender rightNow = Calender.getInstance(); inside the look, that would keep creating new instances right?

Yes, it creates a new Calendar instance, but that is a cheap constructor. Calendar's data structure is not much more than a Date, its the member functions that are less insane than Date's.

[Jay Orsaw]

Pat Farrell wrote:

Jay Orsaw wrote:I also tried just doing Calender rightNow = Calender.getInstance(); inside the look, that would keep creating new instances right?

Yes, it creates a new Calendar instance, but that is a cheap constructor. Calendar's data structure is not much more than a Date, its the member functions that are less insane than Date's.

Yeah, everytime I was looking at "Date" it said "depreciated to Calender" so i worked with that :p.