Encapsulation of Java Beans

Before we can put a bean into a visual build tool that activates the bean, it must be placed in the standard bean container, which contains the Bean class and a jar (Java Archive,java file) file that represents the manifest file "This is a bean." The manifest file is a simple text file that follows the event structure. For Bangbean, the manifest file is as follows:

manifest-version:1.0

Name:bangbean/bangbean.class
Java-bean:true

The first line indicates the version of the manifest file structure, which was published by Sun Company A long time ago. The second line (blank line ignored) names the file as Bangbean.class. The third line means "This file is a bean." Without the third line, the program Builder does not recognize the class as a bean.
The only hard part is that we have to be sure that the path in the "Name:" field is correct. If we review Bangbean.java, we will see it in Package Bangbean (because the subdirectory that holds the classpath is called "Bangbean"), and the name must include encapsulated information in the manifest file. In addition, we must place the manifest file in the root directory of our encapsulated path, which in this case means placing the file in the Bangbean subdirectory. After that, we must call the jar from the same directory as the manifest file, as follows:
Jar CFM Bangbean.jar BANGBEAN.MF Bangbean
This example assumes that we want to produce a file named Bangbean.jar and we put the list in a file called BANGBEAN.MF.
We might think, "What happens to the other classes that come when I compile Bangbean.java?" "Oh, they'll be aborted in the Bangbean subdirectory, and we'll notice that the last argument on the jar command line above is the Bangbean subdirectory." When we give the JAR subdirectory name, it encapsulates the entire subdirectory into the jar file (in this case, including the Bangbean.java source code file--for our own bean we may not be able to choose to include the source file.) In addition, if we change our mind and unpack the packaged jar file, we will find that our manifest file is not inside, but the jar creates its own manifest file (partly according to our file), called MAINFEST.MF, and places it in the Meta-inf subdirectory (representing " Meta-information "). If we open this manifest file, we will also notice that the jar adds digital signature information to each file, which is structured as follows:
Digest-algorithms:sha MD5
sha-digest:pdpeag9naecx8aftqpi4udsx/o0=
md5-digest:o4ncs1he3smnzlp2hj6qeg==
In general, we don't have to worry about these, if we're going to make some changes, we can modify our original manifest file and call the jar again to think that our bean created a new jar file. We can also add them to the jar file simply by adding additional bean information to our manifest file.
It is worth noting that we may need to place each bean into its own subdirectory, because when we create a jar file, the jar application directory name is allocated and the jar places any files in the subdirectory into the jar file. We can see that frog and Bangbean are in their own subdirectories.
Once we put our beans right into a jar file, we can bring it to a programming environment where the beans can be activated. With this approach, we can alternate between one tool and another, but Sun provides the Java beans with free and efficient testing tools called "Beanbox" in their "Bean Development Kit,bean Development Tools" (BDK). (We can download it from www.javasoft.com.) Before we start Beanbox, place our bean into beanbox, and copy the jar file to the bdk "jars" subdirectory.