Pourquoi j'ai choisi Spring Boot après J2EE

Pendant longtemps, mon quotidien de développeur web, c’était du J2EE « à l’ancienne » : des servlets, des JSP, des DAO écrits à la main, un web.xml et un Tomcat que je redémarrais dix fois par heure. Ça m’a énormément appris. Aujourd’hui, j’explore Spring Boot, et voici ce qui m’a convaincu de franchir le pas.

D’où je viens

Mon portfolio actuel est construit en JSP et Servlet. Chaque page suit le même schéma : un servlet reçoit la requête, appelle un DAO, place les données dans la requête, puis fait un forward vers une JSP. C’est simple à comprendre et ça m’a obligé à savoir ce qui se passe réellement : le cycle de vie d’un servlet, les filtres, les sessions, la connexion JDBC, l’encodage des caractères.

Mais cette pédagogie a un prix. Chaque nouvelle fonctionnalité demande beaucoup de code répétitif, et la moindre erreur de configuration peut coûter des heures : un mauvais chemin de forward, un identifiant de base de données incorrect, une page 404 qui cache en réalité une exception SQL.

Un servlet classique

@WebServlet("/projects")
public class ProjectsServlet extends HttpServlet {
    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        ProjectDAO dao = new ProjectDAO();
        req.setAttribute("projects", dao.getAll());
        req.getRequestDispatcher("/WEB-INF/views/projects.jsp").forward(req, resp);
    }
}

Il faut ensuite écrire le DAO, ouvrir la connexion, préparer la requête, parcourir le ResultSet, fermer les ressources… pour afficher une simple liste.

Ce que Spring Boot change

• L’auto-configuration. Je déclare une dépendance, Spring Boot configure le reste avec des valeurs raisonnables. Plus besoin de tout câbler à la main.
• Le serveur embarqué. Tomcat est inclus dans l’application. Je lance un simple main et le site tourne, sans installer ni configurer un serveur à part.
• L’injection de dépendances. Fini les new BlogDAO() partout. Spring fournit les objets dont j’ai besoin, ce qui rend le code plus propre et bien plus facile à tester.
• Spring Data JPA. Une interface suffit pour obtenir les opérations de base sur une table, sans écrire de JDBC.
• Un seul fichier de configuration. Le fichier application.properties centralise l’URL de la base, l’utilisateur, le port et le reste.

Le même exemple avec Spring Boot

@Controller
public class ProjectController {

    private final ProjectRepository repository;

    public ProjectController(ProjectRepository repository) {
        this.repository = repository;
    }

    @GetMapping("/projects")
    public String list(Model model) {
        model.addAttribute("projects", repository.findAll());
        return "projects";
    }
}

Le contrôleur est court, lisible, et la connexion à la base n’est plus mon problème : elle est gérée par le framework.

Ce que le J2EE m’a apporté et que je garde

Je ne regrette pas d’avoir commencé par les bases. Comprendre une requête HTTP, un filtre, une session ou un pool de connexions rend Spring beaucoup moins magique. Quand une erreur apparaît, je sais où regarder au lieu de deviner. Les frameworks changent, les fondamentaux restent.

Ce qui reste difficile

Spring Boot n’est pas une solution miracle. La courbe d’apprentissage existe : les annotations, la configuration automatique et les messages d’erreur parfois longs demandent de la patience. Pour un petit site comme un portfolio, JSP et Servlet restent parfaitement valables. Spring Boot devient vraiment intéressant dès qu’un projet grossit : API REST, sécurité, base de données plus riche, tests.

Mon conseil si tu hésites

• Maîtrise d’abord les servlets, le JDBC et le MVC. Tu en tireras un vrai bénéfice ensuite.
• Refais un petit projet que tu connais déjà avec Spring Boot pour comparer directement.
• Commence par une application simple : un contrôleur, un dépôt, une page.
• Lis les erreurs jusqu’au bout : la vraie cause est souvent à la fin de la trace.

Conclusion

Passer du J2EE à Spring Boot ne veut pas dire abandonner ce que j’ai appris, mais l’utiliser autrement. Je gagne du temps, je réduis le code répétitif et je me concentre sur ce qui compte : la fonctionnalité et l’expérience de l’utilisateur. Je continue à apprendre, et je partagerai la suite de mon parcours ici.