Recently in enterprise development, I came across a requirement to adjust and optimize a scheduled email-sending task. While the logic itself was straightforward, the debugging experience was not.

The Pain Points of Debugging Scheduled Tasks

Here's what made it tricky:

  • The development environment lacks a unified interface to manually trigger backend @Scheduled tasks from the frontend.
  • Debugging by modifying the cron expression means:
    • Restarting the entire project every time
    • Risking a flood of unintended emails
  • While test code can directly invoke methods, it's not always clean or convenient.

Let’s look at the scheduled task:

@Component
public class EmailScheduled {

    @Scheduled(cron = "0 0 23 * * * ?")
    public void emailSend() {
        // Actual email sending logic
    }        
}

A Simple Hack: Use afterPropertiesSet to Trigger the Task

The idea is simple: leverage the InitializingBean interface. Spring will automatically call afterPropertiesSet() when initializing a bean. So we can invoke emailSend() there to simulate a scheduled run.

@Component
public class EmailScheduled implements InitializingBean {

    @Scheduled(cron = "0 0 23 * * * ?")
    public void emailSend() {
        // Actual email sending logic
    } 

    @Override
    public void afterPropertiesSet() throws Exception {
        emailSend(); // Triggered once at startup
    }
}

Why This Helps

  • No cron modification
  • No project restart just to adjust time
  • No actual scheduling triggered — just one-time manual invocation
  • Perfect for short-term debugging during development

⚠️ A Word of Caution

This is not meant to be a long-term solution. Remember to remove or disable this hack before deploying to production. For a more robust setup, consider exposing your scheduled tasks through an admin/debug endpoint or using Spring Boot Actuator with proper security controls.