6.1 What are JavaBeans

Already in the late 90s, the Java language began to be actively used for large server applications, where the number of classes is measured in tens and hundreds of thousands. That's when the idea to standardize the look of Java objects came up.

The whole Java language was not touched, so as not to deprive it of flexibility. Well, backwards compatibility and all that. Then they developed a number of criteria for new generation Java objects and called such objects Java Beans. Java is named after a popular brand of coffee, so Java Beans literally translates to "coffee beans".

The most important criteria were:

  • Access to the internal fields of the class goes through the getProperty().
  • Writing data to class fields goes through the setProperty(value).
  • The class must have a public parameterless constructor .
  • The class must be serializable.
  • The class must have the equals(), hashCode()and methods overridden toString().
Java university

This approach made the applications less coherent. Always clear:

  • how to create an object - there is a public default constructor;
  • how to get/set the property value;
  • how to transfer/save an object (we use serialization);
  • how to compare objects (using equals() and hashCode());
  • how to display information about the object in the log (use toString).

Now it is actually the industry standard, but it was once a new trend. It seems that everyone already writes like this, although if you remember HttpClient and its Builders, you can see that the new standard is hard for someone.

Such objects are widely used where their main semantic load is data storage. For example, in GUIs, databases, and JSP pages.

6.2 JSPs and JavaBeans

One of the reasons for the JSP was that it could be outsourced to front-end developers. And what? You have a person who understands HTML, let him write JSP. Java programmers write their part, front-end developers write theirs - everything is fine.

And everything was fine until the front-end developers had to understand the written Java code embedded in the JSP. Or, even worse, write such code yourself.

Java programmers were not happy with this either. Well, pray tell, which layout designers are backend developers? Yes, they can not write anything except scripts. Yes, and the whole programming paradigm says that mixing different languages ​​​​in one file is a bad form.

Then the idea came up that they say to give front-end developers the opportunity to work with Java objects, as with HTML code. Each HTML tag is also an object with its own fields, why not work with Java objects in a similar way?

No sooner said than done. Added special tags and away we go.

Object creation:

<jsp:useBean id="Name" class="Object type" scope="session"/>

This command created an object with the type objectand put it in session under the name Name.

Objects could be stored in one of four stores: application (global), session, request, and page. It was also possible to set a property of such objects:

<jsp:setProperty name="Name" property="propName" value="string constant"/>

You could get the property of such objects like this:

<jsp:getProperty name="Name" property="propName"/>

An example of using tags:

<body>
    <center>
        <h2>Using JavaBeans in JSP</h2>
        <jsp:useBean id = "test" class = "com.example.TestBean" />
        <jsp:setProperty name = "test" property = "message" value = "Hello JSP..." />
        <p> What-to do important</p>
        <jsp:getProperty name = "test" property = "message" />
    </center>
   </body>