Learn Java with Top Tutors

In Java Servlets, ServletConfig is a configuration object unique to a single servlet instance, whereas ServletContext is a global object shared across the entire web application. Both interfaces are part of the javax.servlet (or jakarta.servlet) package and help manage initialization parameters without hardcoding them into Java source files.

Why banks use Java + servlets for netbanking:

1. Mature & stable — 25+ years battle-tested, low-risk for financial systems
2. Strong transactions — JTA/JDBC handle ACID transactions well (critical for fund transfers)
3. Security ecosystem — Spring Security, JAAS, long track record trusted by regulators
4. Compliance-friendly — built-in audit logging, session/access control aligns with PCI-DSS/RBI norms
5. Legacy integration — core banking systems (COBOL/Java/mainframes) integrate easily via Java
6. Fits the use case — netbanking is mostly request-response, not high-concurrency streaming, so blocking servlet model works fine
7. Talent pool — huge, stable Java/Spring developer base
8. Enterprise vendor support — WebLogic/WebSphere/JBoss are built around servlets

Caveat: newer fintechs/neobanks use reactive stacks (WebFlux, Node.js, Go) for high-scale real-time needs — but traditional banks stick with servlets for stability + compliance, not raw performance.

No. Servlets are the traditional foundation (Spring MVC, JAX-RS/Jersey, Struts all run inside a servlet container like Tomcat, using blocking thread-per-request).

But reactive/non-blocking frameworks skip servlets entirely, running on Netty instead: Spring WebFlux, Vert.x, Micronaut (Netty mode), Quarkus (reactive), Play. These use event-loop I/O for better concurrency at scale.

Servlet-based = traditional blocking stack. Non-servlet = reactive stack (Netty-based), used when you need high concurrency without a thread per request.

Servlets are the core of Java web development: a Java class that handles HTTP requests while the container (Tomcat, Jetty) manages the low-level plumbing. I'd use them directly for filters, file handling, or tiny services. Otherwise Spring MVC's DispatcherServlet already sits on top of them, so understanding servlets mainly helps with debugging.

JSP lets you write HTML with embedded Java instead of printing HTML from servlets. It suits server-rendered pages and older enterprise apps, but it's mostly legacy now. Thymeleaf or FreeMarker are better choices today.

REST is an architectural style (not a technology) that exposes resources over HTTP, usually as JSON, and stays stateless. It's the right fit when the frontend is separate (React, Angular, mobile) or when microservices need to talk to each other. It's easy to scale and works with any client.

Alternatives:

• Instead of servlets/JSP: Spring Boot, plus Thymeleaf or a JavaScript frontend.
• Instead of REST: GraphQL for flexible client queries, gRPC for fast internal service calls, WebSockets/SSE for real-time features, and Kafka/RabbitMQ for async communication.
• Other stacks: Node.js, Django/FastAPI, Go.

Java Servlets are primarily used to collect user requests from a web browser, process backend business logic, and dynamically generate web content (like HTML, JSON, or XML) to send back as a response. They act as a foundational server-side layer that allows Java applications to communicate seamlessly with web clients over the HTTP protocol.