A Tech Trip: March 2017

This is more of a dump of the reading material I went through alongwith my scribbled notes to understand how we development evolved in the Java ecosystem.

In the start there was darkness

Only HTML pages exist

then came the requirement to generate them dynamically - (server side generation of HTML started)

That's when SERVLETs came into picture - HTML code in Java

Servlets were processed by a web server container like Tomcat

It soon became unmanageable.

JSP came for the rescue. - Java code in HTML -

To reduce the amount of boilerplate java code in JSP, its language evolved. More complex constructs arrived

Standard Action - One level object hierarchy supported - attributes embedded within an object attribute of a bigger object wasn't accessible

Expression Language - Multi-level hierarchy supported - Iteration over collections wasn't possible

Tag Library - Looping over collections made possible - handled 99% of usecases

Custom Tags - for the remaining 1% of the requirements, developers were allowed to define their own custom tags

Bean - any simple class with setters and getters.

Not really. There is more to being a bean than just having accessors/mutators. Please refer to the JavaBean specification.

Servlet - A class inherited from HttpServlet which receives the http requests and generate the response of forward the request to another servlet or jsp page.

No, servlets need not extend HttpServlet. They need only implement javax.servlet.Servlet. HttpServlet is only one implementation of a servlet.

EJB - a class(object) which exists on a j2ee server and can be accessed remote(from another JVM).

The term "J2EE server" is ambiguous; more specifically, Enterpise Java Beans (EJBs) are reusable, distributed software components that are executed within an EJB container.

In page-driven applications, each page not only contains the business logic required to generate the dynamic content, but also the control logic to determine application flow. Control logic became difficult to maintain because there was no central location or design paradigm to help you understand how a user passed from one page to the next. And as business requirements evolved to include features like authentication and authorization, page code became convoluted with additional logic that usually had to be duplicated across pages, even if it was irrelevant to the page being constructed. On a site with 1,000 pages, all with authorization mechanisms, who wants to update all 1,000 pages when those authorization mechanisms change?

The arrival of MVC architecture - Understanding 101

http://www.javaworld.com/article/2076557/java-web-development/understanding-javaserver-pages-model-2-architecture.html

The core business value in adopting Spring is the separation between code and configuration, which leads to a more manageable application.

Webserver comes bundled up with Spring ()

you can choose Jetty / Tomcat

Source:

The evolution of Servlets and JSP

Jetty vs Tomcat Performance Comparison

Forum question on servlet beans - not authoritative but gives pointers

How Spring sprang up and was different from earlier ways of doing things

Understanding Java version releases - http://www.tecmint.com/what-is-java-a-brief-history-about-java/

How and when IBM entered the Java scene - the internationalisation angle