CS 541 Meeting -*- Outline -*- * JavaBeans references: C. Szyperski, Component Software, (Addison-Wesley, 1998) MindQuest Publishing Inc., Introduction to VisualAge for Java & Programming JavaBean (CD-ROM, 1998) ** component architectures ------------------------------------------ COMPONENT ARCHITECTURES: A NEW FIELD FOR LANGUAGE DESIGN def: a *software component* is Examples: button slider graph Note: components are like not objects Architecture must define way to: ------------------------------------------ ... a unit of composition with contractually specified interfaces and explicit context dependencies. It can be used independently by third parties. A binary unit that can be composed without changing the source code classes and resources ... - define contracts (interface types) - discover interfaces of components - state context dependencies - have instances interact e.g. by events Q: What's the difference between components and class libraries? class libraries are less specific, source code, more customizable ** Java's component architecture *** overview ------------------------------------------ JAVABEANS: COMPONENTS FOR JAVA Terms: a *bean* is a *bean instance* is Target: components that can be When are they used? at design-time, customize and produce bean instance at run-time bean instance performs its jobs ------------------------------------------ ... a component (classes and resources) ... an object made from a bean (customized), contains many objects ... visually manipulated and customized small to medium sized like OLE controls or non-container ActiveX controls often for graphic components e.g., button, slide, graph doesn't have to be a visual object just needs a way to customize it visually (an icon) so it works with Application Builders like VisualAge or Visual Cafe ------------------------------------------ ASPECTS OF THE BEAN ARCHITECTURE Events: beans can be sources or listeners Properties: like fields accessed through methods get, set changes can trigger events or be constrained GUI or Application builder: tool that composes beans (visually) Reflection and Introspection: ways for tools to find out about beans Customization: setting properties of a bean Container: code that glues beans together Persistence: saving customized and connected beans ------------------------------------------ *** events ------------------------------------------ WHY EVENTS? Why can't we connect beans by method calls? Example: slider and button beans pressing the button should reset slider Why not: public void pressButton { slider.reset(); } ------------------------------------------ main reason is 3rd party composition the button class doesn't know the objects that might need to receive the reset event. ------------------------------------------ EVENTS How events work: 0. "source" defines interface interface UserSleepsListener extends java.util.EventListener { void userSleeps(UserSleepsEvent e); } 1. listener object is created class MySleepListener implements UserSleepsListener { MySleepListener() { /* ... */ } void userSleeps(UserSleepsEvent e) { // do something ... } } UserSleepsListener myLstnr = new MySleepListener(); 2. listener registers with source src.addUserSleepsListener(myLstnr); 3. source is mutated src.looksLikeYawning(); 4. source's method notifies listeners 5. Notifcation leads to call: myLstnr.userSleeps(event); ------------------------------------------ 4 happens by creating an event object, and calling a method in each of the registered listeners. 5. happens directly in this case, but often in practice there is another indirection through an "adaptor" ------------------------------------------ CLASSES TO SUPPORT ENVENTS java.util.EventObject events themselves java.beans.PropertyChangeSupport holds set of listeners (registration) can notify them (fire events) java.beans.PropertyEditorSupport java.beans.VetoableChangeSupport java.beans.EventSetDescriptor holds set of listeners ------------------------------------------ ------------------------------------------ SEMANTIC PROBLEMS WITH EVENTS Multicast: many listeners, all get notified Unicast: at most one listener What if the set of listeners changes while they are being notified? What if a listener throws an exception? What if listener itself generates an event? What if source holds a lock? ------------------------------------------ *** properties ------------------------------------------ PROPERTIES Simple properties: Like fields, access through 2 methods public Color getBackground(); public void setBackground(Color c); Indexed properties: array-valued properties access through 4 methods public Color[] getSpectrum(); public void setSpectrum(Color[] c); public Color getSpectrum(int i); public void setSpectrum(int i, Color c); ------------------------------------------ ------------------------------------------ DISCOVERING PROPERTIES Application builder finds properties by: a. looking for BeanInfo class named BeanInfo b. and looking for methods named get set ------------------------------------------ Q: How can it do this? ------------------------------------------ CUSTOMIZATION Application builder makes a "property sheet" containing the properties of a bean [------------------------] [ BackgroundColor: white ] [------------------------] ------------------------------------------ There are standard and custom visual editors Standard ones work for built-in types (int, boolean, ...) ------------------------------------------ BOUND PROPERTIES def: a *bindable property* is one that allows listeners to receive PropertyChangeEvents syntax: a settable property in a class that has methods: public void addPropertyChangeListener( PropertyChangeListener l) public void removePropertyChangeListener( PropertyChangeListener l) can be the target of a binding package java.beans; public interface PropertyChangeListener { void propertyChange( PropertyChageEvent e); } ------------------------------------------ bindable properties become bound when connected to listeners by an application builder. ------------------------------------------ CONSTRAINED PROPERTIES def: A *constrainable property* is one that allows listeners to decide if a property change is permitted. syntax: a settable property in a class that has methods public void addVetoableChangeListener( VetoableChangeListener l) public void removeVetoableChangeListener( VetoableChangeListener l) ------------------------------------------ Q: What should the VetoableChangeListener interface be? return boolean, or (in Java) throws an exception to veto Q: What should happen when one listener vetoes the change? revert to old value, then fire another event, ignoring vetoes! ** summary Q: How is JavaBeans like or unlike a programming language? currently it's got a bunch of conventions, little in the way of syntax but could it be otherwise for domain specific programming? Q: Would it benefit from being more of a language? e.g., looping? Better type checking? Optimizations?