A few months ago, we began an incredible journey into the world of Java through a compelling retrospective written in collaboration with Danilo Ventura, Senior Software Engineer at Bitrock. We can move on in our narrative by depicting what happened in the early 2000s.
From Java Server Pages to eXtensible markup language
We saw that Java servlets allowed higher degrees of interactivity and dynamicity in web design. Yet, a significant limitation still existed. Servers could only produce static HTML pages, with no variable elements. Inside a Servlet you had to write all the code of each html page putting together variable data (for example coming from a DB) and static data.
To simplify the process, in 1999 Sun Microsystems released the first version of a new revolutionary technology: Java Server Pages (JSP). With JSP pages it was possible to insert in a HTML page, scripting section parts in java language, creating a “JSP page”. JSP was translated into Servlet and then compiled. With Java Server Pages and servlets led to the birth of server-side pages. This means that pages were no longer static (steady and immutable as website creators thought them): on the contrary, they were dynamically generated on the server side, using the JSP as a template with dynamic contents inside.
We’ve come to the early 2000s: during these years, the first Java frameworks to write web applications emerge. The most relevant ones we must mention are Velocity (a template engine, rather than a framework), Struts and then Struts2. Tools like these were the first attempts to apply the M.V.C. pattern in web application development. Struts and Struts2 were based on XML (“eXtensible markup language”), which was designed to be a human and machine-readable markup language for handling data transport. XML was born as an exchange format for data but it was also (ab)used as a configuration language.
The Enterprise Java Beans and the Web 1.0 age
The evolution of distributed applications still lacked and it could be achieved only thanks to another Java technology: Enterprise Java Beans (EJB). We can now describe EJB as an architecture for setting up program components, written in the Java programming language, that run in the server parts of a computer network that uses the client/server model.
EJB was a very powerful, complex and also widely used technology. Enterprise Java Beans were based on application servers: we are no longer talking about simple servers or servlet engines. In order to execute EJB, developers required application servers that had an entire substrate (called EJB Container) thanks to which, whenever the application was deployed, a wide array of runtime components was generated, creating an actual ecosystem that allows the application to interact with server resources. Many Software houses, at that time, had its own product of EJB Application Server: WebSphere from IBM, Weblogic from BEA Systems (later acquired by Oracle), and, of course, were present open source products too such as JBoss, Apache TomEE and GlassFish.
Developing applications for this technology was rather complicated, IT since professionals had to deal not only with code writing operations, but also with repetitive actions: launching programs, packaging the application in a certain way, having the correct library dependencies for the projects and so on. All these tasks were done manually: as you can imagine, the chance of error was particularly high. Moreover, it was a huge waste of time (that could be dedicated to development) for developers to generate all these packages that would be deployed on application servers.
This led to the creation of new tools able to solve these needs, starting from Ant. Ant was a very innovative tool since, always through XML, it was possible to write procedures to be executed inside the Java world. Through an Ant script in XML, you could run a sequence of operations, such as copying and filing out files, moving some parts to a specific folder, creating a Java archive from that folder and moving it elsewhere. It was thus possible to automate a number of tasks.
Ant arrived in 2002, followed by Maven in 2004 (which is still used nowadays). Last but not least, Gradle appeared around 2012. Maven, now, allows a java developer to manage all dependencies and the lifecycle of its application in a standard way. All these tools, by solving a series of issues, have been essential to guarantee Java survival, otherwise it would have gone extinct.
In the early 2000s – the Web 1.0 age – there were some alternatives to Java. Some examples? PHP, C#, and Microsoft .NET (the Microsoft technology for building Web Applications in Windows environments).
This was also the glorious time of other technologies that were presumed to have an explosive success. Starting from Adobe Flash. At the time, if you didn’t have a Flash animation on your website, you were basically considered a loser! For this reason, Adobe launched this technology that allowed programmers to create, thanks to a language mainly based on Javascript and XML, a code that was executed from the browsers through a proper HTML tag that was generated.
Java 5
2004 was a breakthrough year, marked by the arrival of a version of Java that is still considered game-changing for many aspects: Java 5. Java 5 showed some new features, i.e. generics (taken from C language), annotations, enumerations, varargs, static imports. Sun Microsystem’s programmers and the Java communities, indeed, realized that in those years evolutions were fast-paced and, if they wanted to remain competitive and make Java a modern language, they would have to introduce additional features.
Not being a static language and continuously evolving through time, was the trump card that made Java survive in the long run. Through the implementation of new features, developers’ needs have always been responded to. Java, as a matter of fact, is open-source: all Java developers can download the sources and can manifest within the community which features they would like to be implemented. Even then, the developer community, when talking about the implementation of new features, put it up to the vote.
In those years service-based architectures also began to evolve and companies started realizing that the mainframe was likely to fade away soon. However, there was the need within companies to maintain data sharing available through services.
At this stage, we begin to have problems and questions, like for instance, how do we exchange data? Which language do we use to make different technologies interact with each other? How do we restructure data? Then XML becomes established as an exchange language allowing to structure and to control data.
The first service-oriented architecture (SOA) arose based on a SOAP protocol able to exchange data among multiple technologies and in different formats. Between 2006 – 2009, new solutions, for more complex situations, were implemented, such as, for instance, enterprise service bus (ESB), that resolves in a brilliant way the point to point communication problem for different software technologies.
Java is part of this revolution and is no longer just a language for web application, but is evolving to follow the new requirements of the server world.
You can also read the first, third and forth parts. Follow us on LinkedIn and stay tuned for upcoming interesting technology articles on our blog!
Thanks to Danilo Ventura for the valuable contribution to this article series.
