Java is not just a programming language, but in a broader context it represents an ecosystem. Yes, it appeared first as a programming language but eventually it has encompassed so many ideas into it, that to say Java is just a programming language is an understatement. In this article, we will try to understand this ecosystem and will understand the different jargons. Java has fostered such an open environment that for every set of problems there are huge number of choices, and which has many times brought more complexity in the life of a developer and posed huge challenges in front of Project managers in making technology decisions.
Not long ago, the story goes that James Gosling and his team as part of Green project wrote a language called Oak which was targeted for Hand held devices. The idea never took off but Oak found a new name Java, and a new ecosystem and there was no looking back.
Java the name though is a trademark copyrighted with Sun Microsystems (Now Oracle), but the technology is driven in public domain. And in this public domain, there is again a standards and a non standard stream. The Standards stream is responsible for defining the specifications which drives the future of language. The standards stream is governed by Java Community Process (JCP). There is an equal and at occasions a more powerful movement in non standards area which has come up with frameworks that directly compete with technologies in the standards. Let's first understand the standards stream and than we will see how the non standards stream work. Please remember that non standard does not means that you have to deal with a different programming language. The basic constructs of language remain the same.
In the standards area, Java comes in three flavor, which are as follows:
- JavaSE (Java Standard Edition)
- JavaEE (Java Enterprise Edition)
- JavaME (Java Mobile Edition)
JavaSE
JavaSE stands for Java Standard edition. It was earlier known as J2SE, but that name is deprecated now. The current version of JavaSE is 6.0. But it's not uncommon to find the earlier versions of Java in vogue especially in many production systems. Again in JavaSE there are two parts, which are:
JRE (Java Runtime Environment): JRE represents the environment on which the program executes at runtime. The platform independence of Java basically comes from JRE. The JRE is written against a specification governed by JCP, so it behaves in the same way, though the implementation of JRE is different for each platform. Another important reason of Java being platform independence is that the Java class files are compiled in an interpreted language. So it's the same class file which is given to JRE in Linux or in Windows. The JRE on the fly compiles it into native code and runs it. In languages like C++, the files are compiled directly into the native code, so one has to create the executables for each platform separately. So in a nutshell, JRE is the execution environment at runtime.
JDK (Java Development Kit): If you want to run just the program developed by others, than JRE is good enough. However if you want to develop Java programs than you need JDK. JDK again is a set of api's and contains tools which help in developing applications.
JavaEE
JavaEE was earlier known as J2EE, however that name is deprecated now. JavaSE is good enough for making desktop applications. However to build applications which are client server and highly scalable in nature, you need good support for environment. Yes, it's possible to write such an application on your own using JavaSE but than you will be spending a lot of time to handle concerns like threading, transactions, security, network level programming rather than concentrating on writing business logic. To solve the infrastructural need of application programmers, JavaEE defines a set of specifications which help in dealing with infrastructural issues. Again please understand that JavaEE is a specification and there are vendors who provide the implementation. Tied to the concept of JavaEE is the existence of numerous servers provided by vendors and complying to the specification. Each of these vendors have to pass a set of rigorous compatibility test to certify as JavaEE server. Many of these servers go beyond the JavaEE standards and provide vendor specific features. Till you are complying to the JavaEE standards, you can take your application to any server and it is guaranteed to run. However if you start using the server specific features, than the portability is compromised. All the JavaEE server do run on the JRE and built using JDK. The JRE is always there and the servers provide the managed environment to provide enterprise level functionalities. Some of the popular names in server space are JBoss, glassfish, Websphere, Weblogic and many more. Tomcat is also very famous but it's not a full fledged JavaEE server but just a servlet container.
JavaME
JavaME was earlier known as J2ME, however that name is deprecated now. JavaME stands for Java Mobile edition. It provides tools and platforms to build mobile applications. JavaME could not get the wider support in the industry as compared to JavaSE and JavaEE. The more popular mobile frameworks in the native area are iOS for Apple, Android for Android enable devices. Android is also written on top of Java. Apart from that other cross platform frameworks are phonegap and titanium appaccelerator.
The discussion till now is spanned around the standards. Before we move further into the non standards domain, let's understand what standards offer. In JavaSE, the basic constructs of programs are specified. It comprises of tools, language keywords and api's which help in building applications. Like any programming language Java has set of keywords. If you want to venture into the Java language, you would want to look into the following features:
- Keywords of Java
- Support for OO concept in Java
- Type system
- Basic Language constructs (Loops, controls etc)
- Exception Handling
Also the following api's are basic to language and it's better to be comfortable with them:
- Collection
- Threading
- IO Libraries
Now we will focus our discussion on JavaEE domain as this is where the community is seems to be more active. There are non standards and very popular solutions competing to JavaSE but the real action is in the JavaEE space. Before we move into the non standard domain, let's understand how Standards has approached the problem.
Java in its first incarnation after being unsuccessful, was targeted for the Internet programming. The two important technology in this regards that appeared first were Applet and Servlet. Applet is a Java program which can be downloaded on the client side from server and runs on JRE at client side. It became very popular when it first came and many web applications provided applet to provide rich Internet experience. However soon Applet started to go out of fashion, because to run it the machine has to first download the JRE, if it is not present and you need to have right version of JRE. It was fine in Intranet, but not suitable for Internet considering the size of JRE. Now applets are gone out of fashion. It was a good technology but came at wrong time. Now we have similar concepts in terms of Rich Internet Applications as bandwidth supports downloading the plugins to run those components.
The other technology which became very popular and still is, Servlet. Servlet are server side components and in Http world basically understand how to process Http request and generate Http response. However Servlet posed a mismatch for web applications. Handling GUI Html elements in Servlet became pain and the processing was very low level. To solve this problem, JSP(Java Server Pages) were introduced. Java server pages solved the mismatch for web designers. The page designing and GUI element handling got delegated to JSP and the business logic processing became the job of Servlet. However it was still a lot of work to work with low level processing of Http Request and Response. And here entered the frameworks in community space. When people realized that they have to do a lot of infrastructure work to handle request and response at low level, people started making frameworks for these kind of works. These classes of framework broadly came in the category of MVC architecture. These frameworks basically provide a high level view of Http request and response by processing them at framework level and building domain objects and returning it to Business processing code. This helped Application programmers to concentrate on the business logic. These frameworks provided many more features beyond this to handle tasks like validation, internationalization and localization etc. At one point in history around 2002-03 period, a new MVC framework was popping every day. The only real survivor in this space is Struts. The other popular MVC framework is Spring MVC but it leverages Spring concept (We will discuss Spring shortly).
Meanwhile, the standards JCP process was working on this problem and wanted to provide developers a much better solution. In this effort, Java Server faces (JSF) was introduced. JSF provided a high level of abstraction to Web application developers. In JSF, the approach is to provide Components and Event based programming model. As an application developer, one decides to use components on the GUI side and bind them to the object attributes and methods. For example a value entered in an input box is bound to a particular attribute of an object and on clicking on a button on the GUI side results in a method call of a certain object. In JSF there are again a set of components provided by standards but there is a huge choice in the none standard space again. Some of the popular libraries in non standard space is Rich faces, IceFaces. One of main reasons of non standard libraries is the non existent support for AJAX. This has been rectified in JSF2.0 Also with this component and event based programming model, there are competing frameworks in non standard space which are also quite popular. The popular names in this space are Wicket and Tapestry.
Now let's focus on the business layer and data access layer. A similar story exist on the business layer and data access layer code. The business layer and data access code require certain infrastructural features like Transaction. Also there are other important issues like scalability, security , threading. To handle this kind of issues, the standards came up with EJB specification. The original incarnation was 1.0 which later on matured to EJB2.1. EJB2.1 in the beginning became very popular, but soon detracted many users because of its complex programming model. EJB2.1 tried to solve two kind of problems. In the business layer, it provided Session beans which capture the business logic and Entity beans which handled the data access part. To solve the overtly complex programming model of EJB's, in the non standard space two technologies made big wave. Spring as business components but very simple programming model and Hibernate handling the data access layer. In fact, Spring-Hibernate combination became one of the most preferred application stack for many applications and still is. Spring introduced the concept of IOC and POJO programming model and Hibernate introduced ORM. These concepts has been incorporated in the new incarnation of EJB3.1. It will be interesting to see how the future will span now. Hibernate has anyway adopted the standards route by posing them as JPA and Entity beans provider. Hibernate still provides more control on certain behavior which are out of standards. Spring being taken by VMware has taken the competition to new level. A very interesting space to watch.
Another interesting area in Java space is handling of webservices. Before we venture further in Webservices, let's understand the XML handling space. XML has again revolutionized the world when it first appeared. It is a way of defining your own markup language. Java provided again it's own set of api's to process XML. SAX and DOM are two very popular parsers and StAX parser is also now included as part of standards. Again there are set of api's and the implementation are provided by vendor. These parsers provide a raw view of XML and again Java being OO poses a little mismatch. To solve this, standards has come with JAXB specification. JAXB provides an object mapping to XML so that the transformation of XML to objects and vice versa can be done by the framework. A similar tool which is popular in community space is Castor.
Now let's look into web services. To provide better development of web services, Java introduced JAX-RPC specification. It again turned out to be a complex programming model and was not well defined and provided many open ends. This led to vendors to provide proprietary ways to handle the open issues. It hampered the portability. Again to solve this in the non standard space, people came with Axis which became very popular. The standards again took note of it and came up with a much more simpler model named as JAX-WS. JAX-WS provide a simple annotation driven programming model.
No comments:
Post a Comment