This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
It is a known fact that the feature that seperates a Java Bean from a Java Object is introsection. I would like to know when you have to use ONLY Java Beans? ex.Java mail api uses a Java bean to determine the mime type of the attachment and invoke the appropriate editor.Why we need a Java Bean for this? hope i have made myself clear. Thanks in advance william
Originally posted by william kane: It is a known fact that the feature that seperates a Java Bean from a Java Object is introsection.
I have no idea what you mean by that . Perhaps you mean that tools that manipulate JavaBeans use introspection to get the job done. However, java Objects other than JavaBeans can certainly use introspection and reflection. Your question is a bit vague. Are you talking about JavaBeans - as in visual components that can be manipulated by a BeanBox (using introspection). Or are you talking about Entreprise JavaBeans - which is a component based architecture for distributed systems? Two completely different topics. Since JavaMail uses a server-side component model and is part of the J2EE API, I will assume that you are talking about this. The reason that one uses a component model is to identify and define a set of interfaces and classes, and how to use them to encapsulate a set of functionality. If you can get this done then you can use that component for a specific purpose in whatever application that you need it for. Reusability. It is the goal - not a requirement. Of course if you need to integrate with something that is expecting components - like a Component Transaction Monitor (such as a Corba tool), you MUST fit their definition of a Component, so you MUST use only EJBs.
"JavaRanch, where the deer and the Certified play" - David O'Meara
Joined: Nov 21, 2000
Cindy, Thanx for your reply. Yes i was taling abt Java Beans and not EJB. And yes i was refering to the the advantage derived by JavaBeans by liveraging on the introspection used by the bean containers to achive runtime changes. The use of JavaBean components in visual components is evident,what i wanted to know is "what is the distictive characteristic of java beans in a non visual interface context that edges it over a normal java object?" or What advantage do i derive when i use a java bean instead of a Java Object in a non visual component context? Hope i made myself clear william
Joined: Sep 29, 2000
First - realize the 99.9% of the time that someone is talking about a "non-visual JavaBean" they are refering to EJBs. However for that other small percent the advantages include: - Reusability. - Being able to manipulate the Bean in a consistant predictable manner. - Some jsps rely on the consistant predicatable manipulation to use the "useBean" functionality allowing the jsp to set the required properties to make the Bean work correctly. - Some tools use "artificial" visual widgets to represent the non-visual functionality of a JavaBean. For instance - if you have a JavaBean that adjusts the percent yeild to price of an investment, and you want to manipulate that JavaBean that does not have it's own inherant "look", the tool might have some artificial widget that represents the actual JavaBean and allows you to do visual design against a non-visual component.
You can instrospect any class, regardless of whether it follows the "bean blueprint" or not. The reason that JavaBeans are usually thought of with regards to instropsection is that they follow a deterministic pattern that makes introspecting them in a meaningful fashion possible. For example: without the blueprint, an accessor for a property could be named anything; getMyProprty(), myProperty(), whatIsTheValueOfMyProperty() and so on. By following a blueprint, an instrospector can know that the accessor for MyProperty is getMyProperty() and that its mutator is setMyProperty(). Beyond the pattern for accessor and mutator naming, there are also other requirements for JavaBeans: serialization, no-arg constructors, and so on. So, short answer to your question is "maybe". But just because you have a few setA() and setB() methods in your class won't automatically make it a bean. hth, bear [ April 29, 2002: Message edited by: Bear Bibeault ]
I can't tell. -A JavaBean must be serializable. Is yours? You will need to import import java.io.ObjectOutputStream and import java.io.ObjectInputStream to support this -A JavaBean must have some properties. I would guess that you are intending yours to have a field named A (???) -A JavaBean uses getters and setters like you have shown. However they must be public and the properties private. -A JavaBean must have some visual representation. I can't tell if yours does or not. You need to either inherit that "look" from a super class - or create it yourself. If so you need a Graphics. -You need a constructor to create that "look" when you create a new instance of your JavaBean. -"Most" JavaBeans have a preferredSize and a minimumSize along with the methods to manipulate those. - A JavaBean uses events to communicate with other JavaBeans. I mean, what good is it to have a JavaBean if it does not DO anything. Either you must inherit this ability or you must provide it yourself. Does this class do that? -You will need to import the java.awt.events.* stuff - did you do that? Also the java.awt.* and java.awt.Graphics and probably java.awt.Font; - A JavaBean should probably have a Label - because most components on a GUI need a label. (This is another "property" and would need its own getters and setters) Try reading this JavaBeans 101 Part 1 JavaBeans 101 Part 2 JavaBeans 101 Part 3 [ April 29, 2002: Message edited by: Cindy Glass ]