This is the second post in the Java EE Fundamentals series
In the previous post, we looked at Java EE and what it means. We did mention that Java EE is made up of various components grouped into APIs under a program called the Java Specification Request (JSR).
In this post, we are going to take a deeper look at what a JSR is. At its core, a Java Specification Request is a formal, open standard document proposal that is made by an individual or organization to the Java Community Process, that contains proposed changes, additions and improvements to the Java technology platform.
A number of very important points could be gleaned from the above definition. First is that a JSR is a formal document. What this means is that a JSR or a request for adding to the Java technology group must take a certain predefined format. A format defined by the JCP.
Secondly is that a JSR is an open standard document. What this means again, is that a JSR is a document that conforms to certain laid down rules and regulations regarding its distribution and contribution to it. It also means that whatever is contained in the JSR is easily accessible to anyone interested in assessing it.
Flowing thirdly from our definition of a Java Specification Request is that a JSR can be made by either an individual or organization. Essentially any member of the JCP can make a JSR. JCP membership is opened to the general public; free for individuals as well. So what this also means is that one cannot make a request to the JCP without being a member of the organization.
Then finally, a JSR is a document that proposed changes, additions and improvements to the Java technology platform. This means that every JSR is an addition of new features or bug fixes or general improvements, in one way or the other, to the Java technology stack.
Every major API available on Java EE is actually a JSR specification that has gone through the process of being approved by the JCP. All JSRs have a process they have to go through to be approved by the JCP.
Once a JSR is approved by the JCP, it becomes a part of the Java stack and can be safely used in production. The JSR process ensures that only well tested technologies are made a part of the Java stack, preventing unnecessary bloat to the platform in the form of adding fad technologies.
The JSR process also ensures that APIs are careful crafted in such a way to preserve backward compatibility. If there is one thing Java is know for, it’s backward compatibility, and the JSR process ensures this very important Java feature is maintained.
As a JSR is just an abstract specification, it needs some form of implementation to be any useful. That is where the concept of reference implementation comes in. Let’s look at that our the next installment of this Java EE fundamentals series.