ChatGPT解决这个技术问题 Extra ChatGPT

I understood, I think, that a "Bean" is a Java-class with properties and getters/setters.
As much as I understand, it is the equivalent of a C struct. Is that true?

Also, is there a real syntactic difference between a JavaBean and a regular class?
Is there any special definition or an Interface?

Basically, why is there a term for this?

Also what does the Serializable interface mean?

See places where Java Beans used?. It's a class following certain conventions.
For the sake of completeness, here is a link to the JavaBeans Specification.
Just a note. If you ever hear people throw around the term POJO, they often actually mean Bean. When you see POJOs they nearly always have setters & getters, are serializable, … In actuality a POJO does not require setters and getters, a serializable interface or anything else--it is simply a Plain Old Java Object with no specific requirements.
Definitely not a struct, but I'm glad you asked the question.

I
Ian Boyd

A JavaBean is just a standard. It is a regular Java class, except it follows certain conventions:

All properties are private (use getters/setters) A public no-argument constructor Implements Serializable.

That's it. It's just a convention. Lots of libraries depend on it though.

With respect to Serializable, from the API documentation:

Serializability of a class is enabled by the class implementing the java.io.Serializable interface. Classes that do not implement this interface will not have any of their state serialized or deserialized. All subtypes of a serializable class are themselves serializable. The serialization interface has no methods or fields and serves only to identify the semantics of being serializable.

In other words, serializable objects can be written to streams, and hence files, object databases, anything really.

Also, there is no syntactic difference between a JavaBean and another class -- a class is a JavaBean if it follows the standards.

There is a term for it, because the standard allows libraries to programmatically do things with class instances you define in a predefined way. For example, if a library wants to stream any object you pass into it, it knows it can because your object is serializable (assuming the library requires your objects be proper JavaBeans).


Right on, in my opinion almost all documentation revolving around beans can't describe the term as concisely as you have. +1
Is it required for the members of a bean to also be beans? Seems like a reasonable requirement..
@worldsayshi - No, it's not required. For example a bean can contain a String; and String is not a bean. (String is immutable, so you cannot create it by calling an empty constructor and a setter.) It seems reasonable that a Serializable object should have Serializable members, unless it somehow serializes them from outside. So no, Java bean members do not need to have any aspect of Java beans. Although it is more simple if they are beans, too.
"All properties private" is not correct. Properties are inferred from the getters and setters (if there is a method X getFoo() -> the bean has a readable property called "foo"; if there is a method setFoo(X foo) -> the bean has a writeable property called "foo"). Properties can be backed by member fields (but don't have to be) which are usually private.
I hope for being a Java bean "a class must be Public". And is it really need that it should implement Serializable Interface??
P
Peter Mortensen

There's a term for it to make it sound special. The reality is nowhere near so mysterious.

Basically, a "Bean":

is a serializable object (that is, it implements java.io.Serializable, and does so correctly), that

has "properties" whose getters and setters are just methods with certain names (like, say, getFoo() is the getter for the "Foo" property), and

has a public zero-argument constructor (so it can be created at will and configured by setting its properties).

As for Serializable: That is nothing but a "marker interface" (an interface that doesn't declare any functions) that tells Java that the implementing class consents to (and implies that it is capable of) "serialization" -- a process that converts an instance into a stream of bytes. Those bytes can be stored in files, sent over a network connection, etc., and have enough information to allow a JVM (at least, one that knows about the object's type) to reconstruct the object later -- possibly in a different instance of the application, or even on a whole other machine!

Of course, in order to do that, the class has to abide by certain limitations. Chief among them is that all instance fields must be either primitive types (int, bool, etc.), instances of some class that is also serializable, or marked as transient so that Java won't try to include them. (This of course means that transient fields will not survive the trip over a stream. A class that has transient fields should be prepared to reinitialize them if necessary.)

A class that can not abide by those limitations should not implement Serializable (and, IIRC, the Java compiler won't even let it do so.)


This is probably a stupid question but, what could an instance field be besides a primitive type or an instance of a class?
@kingfrito_5005: It's going to be one or the other. But if it's an instance of a class, it matters whether that class is serializable or not. In order for a class to be serializable, its non-transient parts have to be of some serializable type.
probably forgot to mention that the constructor should have no arguments . has a public default constructor (so it can be created at will and configured by setting its properties).
@AmosKosgei: Didn't forget; it'd just be redundant. A default constructor by definition can be called with no arguments.
@Amos: As i look into it, though, it seems "default constructor" means something slightly different in Java from in C++. :P Replaced "default" with "0-arg".
P
Peter Mortensen

JavaBeans are Java classes which adhere to an extremely simple coding convention. All you have to do is to

implement the java.io.Serializable interface - to save the state of an object use a public empty argument constructor - to instantiate the object provide public getter/setter methods - to get and set the values of private variables (properties).


p
piet.t

Properties of JavaBeans

A JavaBean is a Java object that satisfies certain programming conventions:

The JavaBean class must implement either Serializable or Externalizable The JavaBean class must have a no-arg constructor All JavaBean properties must have public setter and getter methods All JavaBean instance variables should be private

Example of JavaBeans

@Entity
public class Employee implements Serializable{

   @Id
   private int id;
   private String name;   
   private int salary;  

   public Employee() {}

   public Employee(String name, int salary) {
      this.name = name;
      this.salary = salary;
   }
   public int getId() {
      return id;
   }
   public void setId( int id ) {
      this.id = id;
   }
   public String getName() {
      return name;
   }
   public void setName( String name ) {
      this.name = name;
   }
   public int getSalary() {
      return salary;
   }
   public void setSalary( int salary ) {
      this.salary = salary;
   }
}

Are the annotations necessary or part of a Java Bean?
@giannischristofakis No, the annotations are not necessary. The annotations are used part of the Spring Framework, which uses Java Beans extensively.
Why does it need to have a no-arg constructor?
@Renato this is very simple. think about spring that must instantiate automatically your bean with arg-constructor ... what will it pass as arguments? ;)
A
Anjum....

Explanation with an example.

1. import java.io.Serializable

As for the Serialization, see the documentation.

2. private fields

Fields should be private for prevent outer classes to easily modify those fields. Instead of directly accesing to those fields, usuagly getter/setter methods are used.

3. Constructor

A public constructor without any argument.

4. getter/setter

Getter and setter methods for accessing and modifying private fields.

/** 1. import java.io.Serializable */
public class User implements java.io.Serializable {
    /** 2. private fields */
    private int id;
    private String name;

    /** 3. Constructor */
    public User() {
    }
    public User(int id, String name) {
        this.id = id;
        this.name = name;
    }

    /** 4. getter/setter */
    // getter
    public int getId() {
        return id;
    }
    public String getName() {
        return name;
    }
    // setter
    public void setId(int id) {
        this.id = id;
    }
    public void setName(String name) {
        this.name = name;
    }
}

i guess for setId(int id) body you meant to say this.id = id; instead of this.id = is;
P
Peter Mortensen

Java Beans are used for a less code and more work approach...

Java Beans are used throughout Java EE as a universal contract for runtime discovery and access. For example, JavaServer Pages (JSP) uses Java Beans as data transfer objects between pages or between servlets and JSPs. Java EE's JavaBeans Activation Framework uses Java Beans for integrating support for MIME data types into Java EE. The Java EE Management API uses JavaBeans as the foundation for the instrumentation of resources to be managed in a Java EE environment.

About Serialization:

In object serialization an object can be represented as a sequence of bytes that includes the object's data as well as information about the object's type and the types of data stored in the object.

After a serialized object has been written into a file, it can be read from the file and deserialized that is, the type information and bytes that represent the object and its data can be used to recreate the object in memory.


P
Peter Mortensen

You will find serialization useful when deploying your project across multiple servers since beans will be persisted and transferred across them.


Could you please provide more information about deploying project across multiple servers? thank you
say a cluster with a couple of servers, for Websphere this link stackoverflow.com/questions/3193345/… might help.
P
Peter Mortensen

Just a little background/update on the bean concept. Many other answers actually have the what but not so much why of them.

They were invented early on in Java as part of building GUIs. They followed patterns that were easy for tools to pull apart letting them create a properties panel so you could edit the attributes of the Bean. In general, the Bean properties represented a control on the screen (Think x,y,width,height,text,..)

You can also think of it as a strongly typed data structure.

Over time these became useful for lots of tools that used the same type of access (For example, Hibernate to persist data structures to the database)

As the tools evolved, they moved more towards annotations and away from pulling apart the setter/getter names. Now most systems don't require beans, they can take any plain old Java object with annotated properties to tell them how to manipulate them.

Now I see beans as annotated property balls--they are really only useful for the annotations they carry.

Beans themselves are not a healthy pattern. They destroy encapsulation by their nature since they expose all their properties to external manipulation and as they are used there is a tendency (by no means a requirement) to create code to manipulate the bean externally instead of creating code inside the bean (violates "don't ask an object for its values, ask an object to do something for you"). Using annotated POJOs with minimal getters and no setters is much more OO restoring encapsulation and with the possibility of immutability.

By the way, as all this stuff was happening someone extended the concept to something called Enterprise Java Beans. These are... different. and they are complicated enough that many people felt they didn't understand the entire Bean concept and stopped using the term. This is, I think, why you generally hear beans referred to as POJOs (since every Java object is a POJO this is technically OK, but when you hear someone say POJO they are most often thinking about something that follows the bean pattern)


Right on - violates "don't ask an object for it's values, ask an object to do something for you")
P
Peter Mortensen

JavaBeans is a standard, and its basic syntax requirements have been clearly explained by the other answers.

However, IMO, it is more than a simple syntax standard. The real meaning or intended usage of JavaBeans is, together with various tool supports around the standard, to facilitate code reuse and component-based software engineering, i.e. enable developers to build applications by assembling existing components (classes) and without having to write any code (or only have to write a little glue code). Unfortunately this technology is way under-estimated and under-utilized by the industry, which can be told from the answers in this thread.

If you read Oracle's tutorial on JavaBeans, you can get a better understanding in that.


Useful post and link. When I think of beans I do indeed think thing of "Visual Builder" type stuff, as illustrated in the Oracle article. I wonder whether there are many other frameworks which use them in a big way...
Instead of word junk like to facilitate code reuse and component-based software engineering, i.e. enable developers to build applications by assembling existing components (classes) and without having to write any code (or only have to write a little glue code). you could have given an example as what you mean by "acilitate code reuse"
P
Peter Mortensen

As per the Wikipedia:

The class must have a public default constructor (with no arguments). This allows easy instantiation within editing and activation frameworks. The class properties must be accessible using get, set, is (can be used for boolean properties instead of get), and other methods (so-called accessor methods and mutator methods) according to a standard naming convention. This allows easy automated inspection and updating of bean state within frameworks, many of which include custom editors for various types of properties. Setters can have one or more than one argument. The class should be serializable. (This allows applications and frameworks to reliably save, store, and restore the bean's state in a manner independent of the VM and of the platform.)

For more information follow this link.


Wasn't this already covered by previous answers?
I'm quite sure OP (and most of us) are here for an explanation rather than copy-paste text
The most useful answer.. I was looking for the why next to each condition.. I think I'll stop scrolling here.. thank you
P
Peter Mortensen

Regarding the second part of your question, serialization is a persistence mechanism used to store objects as a sequence of signed bytes. Put less formally, it stores the state of an object so you can retrieve it later, by deserialization.


r
rps

A bean is a Java class with method names that follow the JavaBean guidelines (also called design patterns) for properties, methods, and events . Thus, any public method of the bean class that is not part of a property definition is a bean method. Minimally, a Java class, even with either a property as the sole member (of course, accompanying public getter and setter required), a public method as the sole member or just one public event listener registration method is a Java bean. Furthermore, the property can either be read-only property (has a getter method but no setter) or write-only property (has a setter method only). The Java bean needs to be a public class to be visible to any beanbox tool or container. The container must be able to instantiate it; thus, it should have a public constructor too. The JavaBeans specification doesn’t require a bean to have a public zero-args constructor, explicit or default, for a container to instantiate it. If you could provide a file (with extension .ser) containing a serialized instance, a beanbox tool could use that file to instantiate a prototype bean. Otherwise, the bean would need a public zero-args constructor, either explicit or default.

Once the bean is instantiated, the JavaBean API ( java.beans.*) can introspect it and call methods on it. If no class implementing the interface BeanInfo or extending a BeanInfo implementation , SimpleBeanInfo class, is available, the introspection involves using reflection (implicit introspection) to study the methods supported by a target bean and then apply simple design patterns(the guidelines) to deduce from those methods what properties, events, and public methods are supported. If a class implementing the interface BeanInfo (for a bean Foo, it must be named FooBeanInfo) is available, the API bypasses implicit introspection and uses public methods (getPropertyDescriptor(), getMethodDescriptors(), getEventSetDescriptors() ) of this class to get the information. If a class extending SimpleBeanInfo is available, depending on which of the SimpleBeanInfo public methods (getPropertyDescriptor(), getMethodDescriptors(), getEventSetDescriptors() ) are overridden, it will use those overridden methods(s) to get information; for a method that is not overridden, it’ll default to the corresponding implicit introspection. A bean needs to be instantiated anyway even if no implicit introspection is carried on it. Thus, the requirement of a public zero-args constructor. But, of course, the Serializable or Externalizable interface isn’t necessary for it to be recognized. However the Java Bean specification says, ‘We’d also like it to be “trivial” for the common case of a tiny Bean that simply wants to have its internal state saved and doesn’t want to think about it.’ So, all beans must implement Serializable or Externalizable interface.

Overall, JavaBeans specification isn’t hard and fast about what constitutes a bean. "Writing JavaBeans components is surprisingly easy. You don't need a special tool and you don't have to implement any interfaces. Writing beans is simply a matter of following certain coding conventions. All you have to do is make your class look like a bean — tools that use beans will be able to recognize and use your bean." Trivially, even the following class is a Java bean,

public class Trivial implements java.io.Serializable {}

The beans, as described below, are Java EE versions of the Java SE version (JavaBeans) described above. These descriptions illustrate further the underlying ideas as explained above.

Spring Beans

Say, a bean constructor has some parameters. Suppose some are simple types. The container might not know what values to assign to them; even if it does, the resulting instance might not be reusable. It may make sense only if the user can configure (specify values) by say annotations or xml configuration files as in Spring beans. And suppose some parameters are class or interface types. Again, the container might not know what values to assign to it. It may make sense only if the user can configure (specify specific objects) by say annotations or xml configuration files. However, even in Spring (via xml configuration files), assigning specific objects (with string names) to constructor arguments ( attribute or element of constructor arguments)is not typesafe;it is basically like resource injection. Making references to other Spring beans(called collaborators; via element in a constructor argument element) is basically dependency injection and thus typesafe. Obviously, a dependency(collaborator bean) might have a constructor with injected parameters; those injected dependency(ies) might have a constructor with parameters and so on. In this scenario, ultimately, you would need some bean classes (e.g, MyBean.class) that the container can instantiate by simply calling new MyBean() before it can construct the other collaborating beans via dependency injection on constructors—thus, the requirement for the beans to have public zero-args constructor. Suppose, if a container doesn’t support dependency injection and/or doesn’t allow assigning simple-type values to constructor via some annotations or xml config files as in Spring, bean constructors shouldn’t have parameters. Even a Spring beans application would need some beans to have public zero-args constructor (e.g., in a scenario where your Spring application has no bean with just simple types as constructor arguments).

JSF Managed Beans

JSF managed beans run in a web container. They can be configured either with @ManagedBean annotation or with an application configuration resource file managed-bean.xml. However, it supports injection via resource injection (not typesafe) only; not fit for injection on constructors. The JSF spec requires that managed beans must have a public zero-argument constructors . Further it says, “As of version 2.3 of this specification, use of the managed bean facility as specified in this section is strongly discouraged. A better and more cohesively integrated solution for solving the same problem is to use Contexts and Dependency Injection (CDI), as specified in JSR-365." In other words, CDI managed beans to be used, which offers typesafe dependency injection on constructors akin to Spring beans. The CDI specification adopts the Managed Beans specification, which applies to all containers of the JEE platform, not just web tier. Thus, the web container needs to implement CDI specification.

Managed Beans

Here is an extract from the Managed Bean specification “ Managed Beans are container-managed objects with minimal requirements, otherwise known under the acronym “POJOs” (Plain Old Java Objects)…they can be seen as a Java EE platform-enhanced version of the JavaBeans component model found on the Java SE platform…. It won’t be missed by the reader that Managed Beans have a precursor in the homonymous facility found in the JavaServer Faces (JSF) technology…Managed Beans as defined in this specification represent a generalization of those found in JSF; in particular, Managed Beans can be used anywhere in a Java EE application, not just in web modules. For example, in the basic component model, Managed Beans must provide a no-argument constructor, but a specification that builds on Managed Beans, such as CDI (JSR-299), can relax that requirement and allow Managed Beans to provide constructors with more complex signatures, as long as they follow some well-defined rules...A Managed Bean must not be: a final class, an abstract class, a non-static inner class. A Managed Bean may not be serializable unlike a regular JavaBean component.” Thus, the specification for Managed Beans, otherwise known as POJOs or POJO beans, allows extension as in CDI.

CDI Beans

The CDI specification re-defines managed beans as: When running in Java EE, A top-level Java class is a managed bean if it meets requirements:

• It is not an inner class. • It is a non-abstract class, or is annotated @Decorator. • It does not implement javax.enterprise.inject.spi.Extension. • It is not annotated @Vetoed or in a package annotated @Vetoed. • It has an appropriate constructor, either: the class has a constructor with no parameters, or the class declares a constructor annotated @Inject.

All Java classes that meet these conditions are managed beans and thus no special declaration is required to define a managed bean. Or

if it is defined to be a managed bean by any other Java EE specification and if

• It is not annotated with an EJB component-defining annotation or declared as an EJB bean class in ejb-jar.xml.

Unlike Spring beans it doesn’t support constructors with simple-types, which might be possible if it supported configuration with xml config files like in Spring or any annotations.

EJBs

EJBs run in an EJB container. Its specification says: “A session bean component is a Managed Bean." “The class must have a public constructor that takes no arguments,” it says for both session bean and message-driven bean. Further, it says, “The session bean class is not required to implement the SessionBean interface or the Serializable interface.” For the same reason as JSF beans, that EJB3 dependency injection is basically resource injection, JSF beans do not support constructors with arguments, that is, via dependency injection. However, if the EJB container implements CDI, “ Optionally: The class may have an additional constructor annotated with the Inject annotation, “ it says for both session bean and message-driven bean because, “An EJB packaged into a CDI bean archive and not annotated with javax.enterprise.inject.Vetoed annotation, is considered a CDI-enabled bean.”


Walls of text. Can you break them down? Perhaps also add subsection titles.
What is this even intended to be?
Hi @Farid Lack of sub-sectioning, as pointed out by Peter Mortensen here in comment, might have inhibited some readability/comprehensibility. Otherwise, I had read most answers here before posting my answer and tried to write a better one. You may read it now and would be glad to hear your specific comments.
This answer deserves more upvotes. Not only does it clarify some misunderstanding on JavaBeans (e.g. public zero-args constructor is just convention rather than the only option allowed by the spec), but it compares JavaBeans with many other commonly seen beans to provide a wider context. Well summarized.
P
Peter Mortensen

A Java Bean is a Java class (conceptual) that should follow the following conventions:

It should have a no-argument constructor. It should be serializable. It should provide methods to set and get the values of the properties, known as getter and setter methods.

It is a reusable software component. It can encapsulate many objects into one object so that same object can be accessed from multiples places and is a step towards easy maintenance of code.


I like the phrase "reusable software component" when talking about java beans - because java beans in general do absolutely nothing.
@Rodney P. Barbati: Yes, but it looks plagiarised to me (though a search was unsuccessful). In at least 2016, 2017, and 2018, the OP left out most articles (see other posts, e.g. this example from 2018), but in this post, most articles are included. Or in other words, the writing style in this post does not fit the writing style of the OP's other posts ca. 2016.
P
Peter Mortensen

They are serializable, have a zero-argument constructor, and allow access to properties using getter and setter methods. The name "Bean" was given to encompass this standard, which aims to create reusable software components for Java. According to Wikipedia.

The objects that form the backbone of your application and that are managed by the Spring IoC container are called beans. A bean is an object that is instantiated, assembled, and otherwise managed by a Spring IoC container. Otherwise, a bean is simply one of many objects in your application. According to Spring IoC.


P
Peter Mortensen

A Java Bean is any Java class that satisfies the following three criteria:

It should implement the serializable interface (a Marker interface). The constructor should be public and have no arguments (what other people call a "no-arg constructor"). It should have getter and setters.

Good to note the serialVersionUID field is important for maintaining object state.

The below code qualifies as a bean:

public class DataDog implements java.io.Serializable {

private static final long serialVersionUID = -3774654564564563L;

private int id;
private String nameOfDog;

// The constructor should NOT have arguments
public DataDog () {}


/** 4. getter/setter */

// Getter(s)
public int getId() {
    return id;
}

public String getNameOfDog() {
    return nameOfDog;
}


// Setter(s)
public void setId(int id) {
    this.id = id;
}

public void setNameOfDog(String nameOfDog) {
    this.nameOfDog = nameOfDog;
}}

i
igonejack

If you are familiar with C/Golang, you never heard C bean or Go bean because they have struct keyword, that developers can easily define structure types without writing complicated OOP keywords.

type User struct {
  Name string
  Age int
}

var user User

user.Name = "name"
user.Age = 18

var bytes, err = json.Marshal(user)

It's Java's mistake that lack of struct types, and developers find this bad shortage.

Then Java Bean is invented as just another boring rule to make class pretending struct, peace your editor or compiler won't be crying or yelling about your unsafe access to class members.


What are you crying about? What difference would class and struct make/be? Wouldn't the JVM implementation be the same?, something like a v-table?
v
vleo

It was repeated 6 or 7 times above that there is a no-argument constructor requirement for JavaBeans.

This is WRONG, there is no such requirement, especially in the context of Java Spring.

There is also no mention of that requirement in version (1.01) of the specification that describes the JavaBeanns APIs (https://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/). Even more - this specification mentions 'null constructor' only 2 times in the following contexts: "Each customizer should have a null constructor." "Each PropertyEditor should have a null constructor."

So, it does not seem like the authors of the spec don't know or are not willing to use the term "null constructor", still no mention of it for the JavaBeans proper.


Yes all the comments are horrifically wrong. Java Beans can even be immutable through @java.beans.ConstructorProperties. The original spec is so outdated it doesn't even make since. The only real "standard" is what is defined in java.beans.Introspector. The only logic that class really does is check if there are methods that have is/get/set.
After diving deep down the rabbit hole that is JavaBeans myself, I absolutely agree with this answer. JavaBeans are deeply misunderstood concept in the Java community. The original JavaBeans spec makes no mention of a nullary constructor. Only that fields can be accessed through appropriately named getters/setters. This misinterpretation seems to extend into most frameworks as well. Most frameworks specify that they only work with JavaBean objects, when in reality they mean that the objects they work with must adhere to the getter/setting naming conventions set forth by the JavaBeans spec.
P
Peter Mortensen

To understand JavaBean you need to notice the following:

JavaBean is conceptual stuff and can not represent a class of specific things

JavaBean is a development tool can be visualized in the operation of reusable software components

JavaBean is based on the Sun JavaBeans specification and can be reusable components. Its biggest feature is the re-usability.


P
Peter Mortensen

POJO (plain old Java object): POJOs are ordinary Java objects, with no restriction other than those forced by the Java Language.

Serialization: It is used to save state of an object and send it across a network. It converts the state of an object into a byte stream. We can recreate a Java object from the byte stream by process called deserialization.

Make your class implement java.io.Serializable interface. And use writeObject() method of ObjectOutputStream class to achive Serialization.

JavaBean class: It is a special POJO which have some restriction (or convention).

Implement serialization Have public no-arg constructor All properties private with public getters & setter methods.

Many frameworks - like Spring - use JavaBean objects.


k
keshari abeysinghe

Beans The objects that form the backbone of your application and that are managed by the Spring IoC container are called beans. A bean is an object that is instantiated, assembled, and otherwise managed by a Spring IoC container. These beans are created with the configuration metadata that you supply to the container.


J
JAdel

If you want to understand Java-Beans, you first have to understand software-components.

Software components

A software-component is a part of an application that runs a specific operation. A software component can also be part of a service.

A component is:

Coupled (has dependencies)

Statefull (it saves the states of instance variables)

Not standarised, it is designed for a specific use case (main difference between Java-EE Beans)

Runs in client machine

Java Beans (Enterprise Beans)

Standarised components that run in a Java EE-server

Including different business logics to complete a specific service

Simplify development of complex multilayer distributed systems

Java Beans are more of a concept to manage big systems. Thats why they need standarization.

https://i.stack.imgur.com/8sCeX.gif

Source


f
forsberg

In practice, Beans are just objects which are handy to use. Serializing them means to be able easily to persist them (store in a form that is easily recovered).

Typical uses of Beans in real world:

simple reusable objects POJO (Plain Old Java Objects)

visual objects

Spring uses Beans for objects to handle (for instance, User object that needs to be serialized in session)

EJB (Enterprise Java Beans), more complex objects, like JSF Beans (JSF is old quite outdated technology) or JSP Beans

So in fact, Beans are just a convention / standard to expect something from a Java object that it would behave (serialization) and give some ways to change it (setters for properties) in a certain way.

How to use them, is just your invention, but most common cases I enlisted above.


P
Peter Mortensen

A Java Bean is a component or the basic building block in the JavaBeans architecture. The JavaBeans architecture is a component architecture that benefits from reusability and interoperability of a component-based approach.

A valid component architecture should allow programs to be assembled from software building blocks (Beans in this case), perhaps provided by different vendors and also make it possible for an architect / developer to select a component (Bean), understand its capabilities, and incorporate it into an application.

Since classes/objects are the basic building blocks of an OOP language like Java, they are the natural contenders for being the Bean in the JavaBeans architecture.

The process of converting a plain Java class to a Java bean is actually nothing more than making it a reusable and interoperable component. This would translate into a Java class having abilities like:

controlling the properties, events, and methods of a class that are exposed to another application. (You can have a BeanInfo class that reports only those properties, events and methods that the external application needs.) persistence (being serialisable or externizable - this would also imply having no-argument constructors, using transient for fields) ability to register for events and also to generate events (e.g., making use of bound and constraint properties) customizers (to customise the Bean via GUIs or by providing documentation)

In order for a Java class to be termed a Java bean it is not necessary that they need to possess all the above abilities. Instead, it implies to implement a subset of the above relevant to the context (e.g., a bean in a certain framework may not need customizers, some other bean may not need bound and constrained properties, etc.)

Almost all leading frameworks and libraries in Java adhere to the JavaBeans architecture implicitly, in order to reap the above benefits.


E
Esther

Spring @Bean annotation indicates that a method produces a bean to be managed by the Spring container.

More reference: https://www.concretepage.com/spring-5/spring-bean-annotation