This describes "JavaBeans" and how to use them. A Java "bean" is essentially a class that adopts a kind of contract regarding the names and nature of its methods. This contract allows the class to be easily handled when it comes to adjusting its properties dynamically or through property sheets, serializing (i.e. saving the class to a file and re-loading it), event handling, and many other situations. See also this official guide.

Properties are single data values that have get and set methods. Beans contain several properties. The JavaBeans specification consists of design patterns that allow beans to be made easily portable. While a single property might use ChangeEvents to notify listeners when a value has changed, a bean may use PropertyChangeEvents to notify listeners of changes to a specific property. This event contains additional information about the old and new values of a property.

The basic requirements for a Java "bean" are:

• must be a public class
• must implement the Serializable interface;
• must have a public no-argument constructor.

Introspection allows properties and event handling routines that are specified by particular code templates to be "discovered" by external classes. In particular, the Netbeans GUI builder can "detect" the bean properties and allow for customization. For properties of the standard types (boolean, short, int, long, float, double, String, Color), property editing is automatically supported within the GUI's property sheet. The code generated by the builder first calls the no-argument constructor, and then calls various set methods for the properties that have been customized.

Code Patterns

Besides the no-argument constructor, JavaBeans use several other code patterns.

Properties

To allow introspection, properties should conform to get/set patterns:

public C getXyz(); public void setXyz(C newValue);

Indexed properties, typically arrays, support indexed get/set patterns also:

C[] getXyz() void setXyz(C[] array) C getXyz(int index) void setXyz(int index, C element)

Events

Similarly, event handling should conform to add/remove patterns:

public void addXyzListener(XyzListener l) public void removeXyzListener(XyzListener l)

Bound Properties

Bound properties fire PropertyChangeEvents when their value changes. This event includes (i) the String name of the property, (ii) the old value, and (iii) the new value. Any registered PropertyChangeListeners may respond to the change accordingly. The java.beans.PropertyChangeSupport class contains the necessary event handling. A typical set method differs for bound properties, as in the following example:

public void setTitle( String title ) { if ( ! this.title.equals(title) ) { String old = this.title; this.title = title; firePropertyChange( "title", old, title ); } }

Constrained Properties

Constrained properties fire VetoableChangeEvents when their value changes.

Persistence

Persistence refers to the ability to save and reload classes. JavaBean code patterns allow for automated persistence through the use of the XMLEncoder class. For full details, see http://java.sun.com/products/jfc/tsc/articles/persistence4/.

Automatic Persistence

The underlying procedure in saving and reloading is using the existing properties of a class, as defined via the above bean patterns, to store the class. Only attributes that are accessible through properties are stored, so the properties MUST reflect the entire state of the object. In summary, for automatic persistence to work:

• The class must have a no argument constructor.
• The entire state of the class must be reflected in its properties (get/set methods).

Here is an example of a class that uses bean patterns to store the file, together with the output:

/** This is the class definition for the object we wish to save. */ public class Dog { String name; // the state variables float weight; public Dog() { this("Spot", 20); } // the public no-argument constructor (required) public Dog(String name, float weight) { this.name = name; this.weight = weight; } // the bean properties public void setName(String name) { this.name = name; } public String getName() { return name; } public void setWeight(float weight) { this.weight = weight; } public float getWeight() { return weight; } } /** This is how to create and use the XMLEncoder */ public static void main(String[] args) { // create an object to save Dog dog = new Dog(); dog.name="Spotty"; // create the encoder and print the object XMLEncoder e = new XMLEncoder(System.out); e.writeObject(dog); e.close(); }

<?xml version="1.0" encoding="UTF-8"?> <java version="1.5.0_21" class="java.beans.XMLDecoder"> <object class="Dog"> <void property="name"> <string>Spotty</string> </void> </object> </java>

Some comments:

• It is easy to write to a file instead of System.out. One can use for example new FileOutputStream("dog.xml").
• Notice that only the name property is written to the file. That's because the weight is still the default value. If one changes the weight to be something other than 20, then it will show up in the xml. So if we had written instead Dog dog = new Dog{"Curly", 15}; the XML output would contain both the name and weight properties.

Decoding

The decoding process is similarly easy. The code below illustrates this. Note that this code acts as a sort of test to ensure that whatever is written to a file also reads in properly.

XMLEncoder e; XMLDecoder ed; Dog dog = new Dog(); dog.name = "Spotty"; try { e = new XMLEncoder(new FileOutputStream("test1.xml")); ed = new XMLDecoder(new FileInputStream("test1.xml")); System.out.println(dog); e.writeObject(dog); e.close(); dog = (Dog) ed.readObject(); ed.close(); System.out.println(dog); } catch (FileNotFoundException ex) { Logger.getLogger(Dog.class.getName()).log(Level.SEVERE, null, ex); }

Persistence with Collections and Arrays

Persistence with Java's Lists and arrays does not require much extra, but the resulting XML looks different. Here is another example below. Note particularly how the Vector's add method is being encoded directly.

public static class DogPack { Vector<Dog> dogs; public DogPack() { dogs = new Vector<Dog>(); } public Vector<Dog> getDogs() { return dogs; } public void setDogs(Vector<Dog> dogs) { this.dogs = dogs; } @Override public String toString() { return dogs.toString(); } } public static void main(String[] args) { Dog dog = new Dog(); dog.name="Spotty"; DogPack pack = new DogPack(); pack.dogs.add(new Dog("Curly", 15)); pack.dogs.add(dog); XMLEncoder e = new XMLEncoder(System.out); e.writeObject(pack); e.close(); }

<?xml version="1.0" encoding="UTF-8"?> <java version="1.5.0_21" class="java.beans.XMLDecoder"> <object class="testpersist.Dog$DogPack"> <void property="dogs"> <void method="add"> <object class="testpersist.Dog"> <void property="name"> <string>Curly</string> </void> <void property="weight"> <float>15.0</float> </void> </object> </void> <void method="add"> <object class="testpersist.Dog"> <void property="name"> <string>Spotty</string> </void> </object> </void> </void> </object> </java>

The case of writing arrays is similar, although the xml looks different. Here note the indexing properties, and also note the use of the idref attribute to refer to a previously-defined object (ensuring proper re-creation of pointers).

public static class DogPack2 { Dog[] dogs; public DogPack2() { dogs = new Dog[3]; } public Dog[] getDogs() { return dogs; } public void setDogs(Dog[] dogs) { this.dogs = dogs; } @Override public String toString() { return Arrays.toString(dogs); } } public static void main(String[] args) { Dog dog = new Dog(); dog.name="Spotty"; DogPack2 pack2 = new DogPack2(); pack2.setDogs(new Dog[]{new Dog("Moe", 12), dog, new Dog("Mic", 4), dog}); XMLEncoder e = new XMLEncoder(System.out); e.writeObject(pack2); e.close(); }

<?xml version="1.0" encoding="UTF-8"?> <java version="1.5.0_21" class="java.beans.XMLDecoder"> <object class="testpersist.Dog$DogPack2"> <void property="dogs"> <array class="testpersist.Dog" length="4"> <void index="0"> <object class="testpersist.Dog"> <void property="name"> <string>Moe</string> </void> <void property="weight"> <float>12.0</float> </void> </object> </void> <void index="1"> <object id="Dog0" class="testpersist.Dog"> <void property="name"> <string>Spotty</string> </void> </object> </void> <void index="2"> <object class="testpersist.Dog"> <void property="name"> <string>Mic</string> </void> <void property="weight"> <float>4.0</float> </void> </object> </void> <void index="3"> <object idref="Dog0"/> </void> </array> </void> </object> </java>

Custom Persistence

There is a standard procedure for "delegating" persistence to another object. This is particularly useful when the base class does not support the required bean patterns. One object of this type is java.awt.geom.Point2D.Double, which has two parameters x and y, and get methods for these parameters, but no corresponding set methods. Here is an example of a something that might go wrong.

Point2D.Double p = new Point2D.Double(3,2); XMLEncoder e = new XMLEncoder(System.out); e.writeObject(p); e.close();

<?xml version="1.0" encoding="UTF-8"?> <java version="1.5.0_21" class="java.beans.XMLDecoder"> <object class="java.awt.geom.Point2D$Double"/> </java>

If we try to save and reload the file, then we end up with the coordinate (0,0) instead of (3,2). The work-around is to create a custom persistence delegate, which is actually really easy, so instead use:

Point2D.Double p = new Point2D.Double(3,2); XMLEncoder e = new XMLEncoder(System.out); e.setPersistenceDelegate(Point2D.Double.class, new DefaultPersistenceDelegate(new String[]{"x","y"})); e.writeObject(p); e.close();

<?xml version="1.0" encoding="UTF-8"?> <java version="1.5.0_21" class="java.beans.XMLDecoder"> <object class="java.awt.geom.Point2D$Double"> <double>3.0</double> <double>2.0</double> </object> </java>

This tells the encoder to store the values obtained by getX() and getY(), and then to use them in the default constructor when the object is restored using the XMLDecoder.
There is no need to set the persistence delegate for the decoder as well… I think the decoder puts the values saved in the xml directly into the constructor. (So if you switch the order of "x" and "y" the values read in incorrectly.)

Bugs and Difficulties

Arrays

I have found occasional problems when storing a class with a Point2D.Double[] property. For some reason, the value of the object is not always stored, even if the old array differs from the new array, unless the array is first recreated. I suspect this is a system bug, partly due to the equals() method in Point2D.Double, which is defined in the abstract class Point2D.Double, since an equivalent class with this method redefined works properly. This may also happen in some other circumstances… I'm not quite sure. Here are possible solutions:

• In the class with the point array, DO NOT SET UP any initial values for the points, or set them up with null values. Things seem to work properly when initial values are null.
• Create new get and set methods that will handle the persistence, e.g. use a double[][] type to get and set values instead. Then ensure that the persistence delegate only uses this value.
• Create a subtype of Point2D.Double that overrides the "equals" method and use objects of this type instead… this works even if you only use it for the default values.

Enums

Java's enums also do not work properly with XMLEncoder, at least in earlier versions (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5015403). I have found that the workaround specified there tends to work for enums that are declared with just constants, but not if they are declared with custom methods or any non-standard methods. A quick workaround is to use the String value returned by the name() method to serialize rather than the enum itself. So in the bean, instead of using

public YourEnumName getYourEnum() { return yourEnum; } public void setYourEnum(YourEnumName newValue) { this.yourEnum = newValue; }

public String getYourEnum() { return yourEnum==null ? "" : yourEnum.name(); } public void setYourEnum(String newValue) { this.yourEnum = YourEnumName.valueOf(newValue); }

Property Editors

PropertyEditors are intended to "provide support for GUIs that want to allow users to edit a property value of a given type". In doing so, they handle PropertyChangeEvents for underlying beans. When the value is changed, the class fires an event notifying any registered listeners of the change.

The PropertyEditor API encapsulates a single bean, with getValue and setValue methods, and PropertyChangeEvent handling.

The API also includes getJavaInitializationString, which provides Java constructor code to get the value underlying the component. This can be used by GUI builders to automatically generate the underlying object, or a copy of that object. I'm not entirely sure about its purpose.

Display and Editing Options

There are three display options:

1. Textual display, via getAsText.
2. Combobox display, via getAsText and String[] getTags.
3. Custom component display, via isPaintable and paintRectangle.

Similarly, there are three editing options:

1. Textual editing, via setAsText.
2. Combobox editing, via setAsText and String[] getTags.
3. Custom component editing, via supportsCustomEditor and Component getCustomEditor.

Standard Support Class

The default implementation is the PropertyEditorSupport class, which has simple text editing support.

• Allows customizing the source of PropertyChangeEvents: this defaults to the class, but also may be set directly via the "source" bean property.
• Supports getAsText and setAsText, but an exception is thrown in the set case unless the value is a String.
• Does not support custom editors or tags.

Package Implementations

Several editors are already included within the sun.beans.editors package. Most of these support textual editing only. Exceptions are noted.

• BooleanEditor (tags)
• ByteEditor
• ColorEditor (panel)
• DoubleEditor
• EnumEditor (tags)
• FloatEditor
• FontEditor (panel)
• IntegerEditor
• LongEditor
• NumberEditor
• ShortEditor
• StringEditor

Customizers

The Customizer interface has basic PropertyChangeEvent support, as well as a setObject(Object bean) method that sets the argument based on the value within the customizer. These are intended to provide for more advanced customization capabilities.

by elishapeterson

This note describes how to generate LaTeX images in an html document using a web service… all it takes is inserting the LaTeX into an image link.

Sometimes when writing your own webpages, it's quite a pain to get LaTeX to show up on your website. There are a number of ways to do this. (On this Wikidot site, the LaTeX is generated from the wiki markup.) Without that option, using the http://www.codecogs.com web service is one of the easiest and quickest techniques I have used.

<image src="http://www.codecogs.com/gif.latex?2^nx^i"></image>

<embed width="600" height="100" src="http://www.codecogs.com/swf.latex?1+sin(x)" quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer" align="top" scale="showall" wmode="window" devicefont="false" bgcolor="#ffffff" menu="true" allowFullScreen="true" type="application/x-shockwave-flash"></embed>

by elishapeterson

This preliminary note will describe how I go about rendering points, curves, and surfaces in three dimensions for blaise. See http://blaisemath.googlecode.com/ for the complete source code.

Scene Modeling and Projections

In what follows, we use lowercase (d) for scalars, uppercase (P) for points in space, lowercase bold (x) for arbitrary vectors, and uppercase bold (T) for unit vectors.

Camera Setup

Let C be the camera location, with orientation T, N, B, where T is the direction the camera is facing, N is the "up" direction, and B=TxN is the perpendicular direction. Assume the viewing screen is located at a distance d from the camera, and is centered relative to the camera. Thus, we assume the the viewscreen is perpendicular to T and the center V of the viewscreen is such that $\overrightarrow{CV} = d \vec{\mathbf{T}}$.

As indicated above, the center of the viewscreen is $V=C+d\vec{\mathbf{T}}$. Since the screen is parallel to B and N, an arbitrary point on the screen may be written as V+xB+yN. In this case, we call $\langle x,y\rangle_\pi$, the viewscreen coordinates. Let w be the width of the viewscreen and h the height; the viewscreen's four corner points are $V\pm\frac{w}{2}\vec{\mathbf{B}}\pm\frac{h}{2}\vec{\mathbf{N}}$. In general, a vector y starting at the camera may be expressed as

If the vector ends on the viewscreen, its viewscreen coordinates are therefore $\langle\vec{\mathbf{y}}\cdot\vec{\mathbf{B}}, \vec{\mathbf{y}}\cdot\vec{\mathbf{N}}\rangle_\pi$.

Projection of an Arbitrary Point

Let A_π denote the projection of a point A onto the viewscreen; this is where the viewscreen intersects the line between A and C. Let $\vec{\mathbf{x}}=\overrightarrow{CA}$ be the vector pointing from the camera C to the point. We can express this point as A_π=C+λx for some λ. The value λ is easiest to compute by focusing on the T direction. Since d is the point from C to the plane, and x·T is the distance in the same direction from the camera to the point, one has simply $\lambda=d/\vec{\mathbf{x}}\cdot\vec{\mathbf{T}}$. So

In viewscreen coordinates, one considers the vector $\overrightarrow{CA_\pi}=\left(\frac{d}{\vec{\mathbf{x}}\cdot\vec{\mathbf{T}}}\right)\overrightarrow{CA}$, so that the point A has representation in viewscreen coordinates as follows:

Pixel Conversion

As a final step, one must convert the viewscreen coordinates $\langle x,y\rangle_\pi$ to window coordinates. If the window has pixels ranging from $(0,0)$ in the upper-lefthand corner to $(W,H)$ in the lower-righthand corner (the usual way of marking window coordinates), then the pixel coordinates of this point are

Note that the ratios $\frac{W}{w}$ and $\frac{H}{h}$ will typically be the same and represent the number of pixels per unit length. If this is represented by a constant factor η, the formula becomes $\eta\left(x+\frac{w}{2},-y+\frac{h}{2}\right) = \left(\frac{W}{2} + \eta x, \frac{H}{2}-\eta y\right)$.

Combining the above discussion, if x represents the vector from C to A, then the pixel coordinates of A, as it appears on the viewscreen, should be given by the mapping

Inverse Transformation

A point (x_p,y_p) in pixel coordinates transforms in viewscreen coordinates to $\left\langle\frac{x_p-W/2}{\eta}, -\frac{y_p-H/2}{\eta}\right\rangle = \left\langle\frac{x_p}{\eta}-\frac{w}{2}, -\frac{y_p}{\eta}+\frac{h}{2}\right\rangle$. Hence, the corresponding point on the viewscreen is

The full line of potential inverse mappings is

Multiple Viewpoints & Anaglyphs

Anaglyphs are images rendered separately for each eye, typically with a different color so they can be seen using 3D glasses. In this case, one must use two different projections to obtain the image of the two cameras.

We will look at how the above formulas change for a camera C_ε that is shifted from the original location so that C_ε = C + ε = C + ε_xB + ε_yN (a translation parallel to the viewscreen). Let A_πε represent the point on the viewscreen as seen by the new camera. Note that V_ε = V + ε as well, since the translation is parallel to the viewscreen. One therefore has

This can be further simplifed. Since $\vec{\mathbf{x}}_\varepsilon=\overrightarrow{C_\varepsilon A}=\overrightarrow{CA}-\mathbf{\vec\varepsilon}=\vec{\mathbf{x}}-\mathbf{\vec\varepsilon}$, we have $\vec{\mathbf{x}}_\varepsilon\cdot\vec{\mathbf{T}}=\vec{\mathbf{x}}\cdot\vec{\mathbf{T}}$, $\vec{\mathbf{x}}_\varepsilon\cdot\vec{\mathbf{B}}=\vec{\mathbf{x}}\cdot\vec{\mathbf{B}}-\varepsilon_x$, and $\vec{\mathbf{x}}_\varepsilon\cdot\vec{\mathbf{N}}=\vec{\mathbf{x}}\cdot\vec{\mathbf{N}}-\varepsilon_y$. This shows that

Therefore, the parallel camera which is shifted by ε will give points that are shifted by (1-λ)ε (with the vector ε considered in the proper coordinate system.)

When reduced to the window's coordinate system, recall that $\langle x,y\rangle_\pi \leftrightarrow (\frac{W}{2},\frac{H}{2}) + \eta(x,-y)$, where $\eta=\frac{W}{w}=\frac{H}{h}$ is the number of pixels per unit length. Therefore, one has

So the endstate of a camera shift is a change of

in window coordinates.

A typical two-camera construction (e.g. our eyes) will have cameras at C ± εB for a scalar ε representing one half the distance between the eyes. So in the viewscreen coordinates, the x values are shifted by ±(1-λ)ε. And in the window coordinates, the values are shifted by ±η(1-λ)ε.

Color Filtering

Two-color 3d images work by providing two images with different color schemes, that depend upon the color of lenses in a pair of 3d glasses. When looking through a red lens, one cannot see the color red; therefore, the image seen through the red lens should be comprised of colors using only green and blue channels. When looking through a second lens (e.g. cyan), one may use the red channel. For example, if the left lens is red, the image projected by the left camera (left eye) should be colored with only green and blue. Similarly, if the right lens is cyan, the image projected by the right camera (right eye) should be colored by red only.

Rotations

Rotations are achieved by the following formula [1]:

Here, the vector r is being rotated by an angle of Φ around the axis n.

The motion for rotating the figure is "dragging" the screen. The natural interaction is to treat the rendered scene as existing inside a ball, and rotating that ball around its center to see how the image changes. In our case, the center of the ball will be denoted by S=C+ΔT, where Δ>d and the radius of that ball will be Δ–d. (Recall that d is the distance to the viewscreen. Think of Δ as the distance to the center of the scene of interest, since it defines the point of rotation.) When the user drags the mouse, points are created for the start and end of that motion, call them R₁ and R₂. Let r_i be the unit vector $\overrightarrow{SR_i}/\overrightarrow{SR_i}$ formed by normalizing the vector from S to R_i. Then the axis of rotation is the unit vector

and the angle of rotation is given by the dot product formula

The Euler rotation formula can then be used to transform the camera's T,N,B frame, and thereby recenter the camera to the location S–ΔT (in the transformed T).

In some cases, it may be preferable to allow for the user to make an image rotate faster or slower. This is easily accomplished by scaling the rotation angle Φ to some CΦ. One may also animate a rotation, by keeping the axis of rotation fixed, and increasing the rotation by a small angle dΦ at each time step.

Source Code

Coming soon… see page history for old source code.

References

by elishapeterson

This note covers some basics of JAXB (Java API for XML Binding). See also the Wikipedia entry, the development site, a tutorial by Sun, and a description of JAXB annotations.

Keywords: Java, XML, JAXB, JavaBeans, Binding

Marshalling

Suppose you want to automatically generate an XML file for your object. In JAXB, this process is called "marshalling". The idea is to annotate the appropriate fields that you want to store in the XML file. It handles the file-generation automatically. Here's a simple example:

public class Main { @XmlRootElement static class Dog { @XmlAttribute String name; @XmlElement float height; @XmlElement float width; Dog(){name="Spot";height=10;width=10;} } public static void main(String[] args) throws Exception { JAXBContext jc = JAXBContext.newInstance(Dog.class); jc.createMarshaller().marshal(new Dog(),new FileOutputStream("dog.xml")); } }

Here @XmlRootElement identifies the root element of the XML document tree (DOM), which is required for "well-formed" SML. @XmlAttribute specifies an attribute supplied "inline" with the object definition, while @XmlElement identifies attributes that are specified separately. Running this file produces the following output:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <dog name="Spot"> <height>10.0</height> <width>10.0</width> </dog>

Automating the Process

You can shorten the code a bit by telling the marshaller to automatically put fields into the output file. The command for this is @XmlAccessorType, as shown in this abbreviated version:

public class Main { @XmlRootElement @XmlAccessorType(XmlAccessType.FIELD) static class Dog { @XmlAttribute String name; float height; float width; Dog(){name="Spot";height=10;width=10;} } public static void main(String[] args) throws Exception { JAXBContext jc = JAXBContext.newInstance(Dog.class); jc.createMarshaller().marshal(new Dog(),new FileOutputStream("dog.xml")); } }

Working with Vectors of Data

We can easily modify the above code to work with deeper nesting structures and vectors of data. Here is the code for marshalling a "pack" of dogs:

public class Main { @XmlRootElement @XmlAccessorType(XmlAccessType.FIELD) static class Pack { Vector<Dog> dog; Pack(){dog=new Vector<Dog>();dog.add(new Dog());dog.add(new Dog());} } static class Dog { @XmlAttribute String name; @XmlAttribute float height; @XmlAttribute float width; @XmlElement Coat coat; Dog(){name="Spot";height=10;width=10;coat=new Coat();} } static class Coat { @XmlElement ColorX color; @XmlAttribute float thickness; @XmlAttribute String type; public Coat(){color=new ColorX(); thickness=2; type="solid";} } static class ColorX { Color col; public ColorX(){col=new Color(33,33,33);} @XmlAttribute public int getRed(){return col.getRed();} public void setRed(int r){col=new Color(r,col.getGreen(),col.getBlue());} @XmlAttribute public int getGreen(){return col.getGreen();} public void setGreen(int g){col=new Color(col.getRed(),g,col.getBlue());} @XmlAttribute public int getBlue(){return col.getBlue();} public void setBlue(int b){col=new Color(col.getRed(),col.getGreen(),b);} } public static void main(String[] args) throws Exception { JAXBContext jc = JAXBContext.newInstance(Pack.class); jc.createMarshaller().marshal(new Pack(),new FileOutputStream("dog.xml")); }

Note that saving a color in terms of its components requires creating "get" and "set" methods for the color components (making it a "Java bean"). A better approach is to use the @XmlJavaTypeAdapter (discussed later). Here is the resulting XML file, with the pack initialized to contain two of the default dogs:

<pack> <dog width="10.0" height="10.0" name="Spot"> <coat type="solid" thickness="2.0"> <color red="33" green="33" blue="33"/> </coat> </dog> <dog width="10.0" height="10.0" name="Spot"> <coat type="solid" thickness="2.0"> <color red="33" green="33" blue="33"/> </coat> </dog> </pack>

Unmarshalling

The process of returning the XML code into objects is called "unmarshalling". If the XML file doggin.xml is edited, maintaining the same structure, then one can read the data back in just as easily. Here is the code to read the dogs back into a Pack object:

 Pack inputPack = (Pack) jc.createUnmarshaller().unmarshal(new FileInputStream("doggin.xml"));

1. Call to no-argument constructor to create the class
2. Call to get and set methods in the order they appear within the XML

It is a good idea to design constructors with arguments to work the same way within your code (this avoids bugs).

Source Code

Here is a sample input file: doggin.xml. You can modify it directly, and see the resulting change in the inputPack object. The complete source code with String outputs to test the process is: Main.java.

Working with Inheritance

First Technique

XML binding will usually take place with a declared class rather than the "runtime" class. One approach that works is annotating with a list of possible concrete types. Suppose Animal is an abstract class that might represent a Cat or Dog or other animal? One can annotate the corresponding property with @XmlElements as follows:

@XmlRootElement class Zoo { @XmlElements({ @XmlElement(name="dog",type=Dog.class), @XmlElement(name="cat",type=Cat.class) }) public Animal animal; ... }

<zoo> <dog .../> </zoo>

<zoo> <cat .../> </zoo>

The use of the @XmlElements tag makes the following differences in the XML:

• tag names are specific to the type of subclass of the Animal class
• any additional attributes or elements specified as part of the subclass are included in the XML

Thus, one generally needs to use this technique to ensure that inheritance works properly.

Collections

How do you deal with structures such as Vector<Animal>? The process is similar:

@XmlRootElement class Zoo { @XmlElements({ @XmlElement(name="dog",type=Dog.class), @XmlElement(name="cat",type=Cat.class) }) public Vector<Animal> animals; ... }

<zoo> <dog .../> <dog .../> <cat .../> </zoo>

Second Technique

Another approach is to register the descendant classes into the JAXBContext and to use the @XmlAnyElement annotation. Here's how. First, you'll need to annotate the subclasses as follows:

@XmlRootElement @XmlAccessorType(XmlAccessType.FIELD) class Zoo { @XmlAnyElement public List<Animal> animal; ... } interface Animal { ... } @XmlRootElement @XmlAccessorType(XmlAccessType.FIELD) class Lion implements Animal { String name = "Simba"; } // other subclasses of animal

JAXBContext jc = JAXBContext.newInstance(Zoo.class, Lion.class, ...);

Customizing the XML

The @XmlJavaTypeAdapter annotation allows one to "intercept" the marshalling process and so specify exactly what the XML will look like. This requires writing two additional classes: one for the adapted version of the class, and an adapter class that handles the conversion process. Here is an example that stores dogs at half their height:

// our original class @XmlJavaTypeAdapter(DogAdapter.class) static class Dog { double height; public Dog(double height) { this.height = height; } } // our adapted class @XmlAccessorType(XmlAccessType.FIELD) static class LittleDog { double height; public LittleDog() {} // no-arg default constructor required for marshalling public LittleDog(double height) { this.height = height; } } // this performs the class conversion static class DogAdapter extends XmlAdapter<LittleDog, Dog> { @Override public Dog unmarshal(LittleDog v) throws Exception { return new Dog(v.height*2); } @Override public LittleDog marshal(Dog v) throws Exception { return new LittleDog(v.height/2); } } // the enclosing instance @XmlRootElement @XmlAccessorType(XmlAccessType.FIELD) static class Pack { Dog dog1 = new Dog(5.0); Dog dog2 = new Dog(3.0); }

Now when we perform the marshalling process, we get the following XML:

<pack> <dog1> <height>2.5</height> </dog1> <dog2> <height>1.5</height> </dog2> </pack>

by elishapeterson

This is a tutorial describing how to use Geogebra to implement a cobwebbing demonstration. The techniques demonstrated can also be applied to many situations involving numerical and recursive techniques.

NOTE: Readers unfamiliar with Geogebra may wish to refer to [2] for a basic introduction. You can leave comments or questions at the bottom of the page.

Introduction

Cobwebbing is a basic technique useful for visualizing solutions to simple recurrence equations. Given an initial value $x_0$, the recurrence $x_n=f(x_{n-1})$ determines a sequence of points

Typically, one is interested in the long-term behavior of this sequence. Does it converge? Does it approach a limit cycle? What else can you say about the sequence? Cobwebbing is a successful technique in large part because it provides a visual approach to determining the long-term behavior of the system. In particular, it can be used to show directly how the slope of the function $f$ determines much of that behavior.

Geogebra is a free open-source mathematics tool designed for the interactive exploration of mathematics[1]. Partly a dynamic geometry platform, partly a computer algebra system, it enables the creation of workbooks that beg for user interaction. This tutorial describes how to create a cobwebbing workbook that allows the user to change the initial point $x_0$, the recurrence function $f$, and the number of iterations displayed on the cobwebbing plot. It covers some advanced techniques such as using the Iteration command, designing customized functions with Geogebra's Tool feature, and creating webpages that support Javascript interactions.

How Cobwebbing Works

How does cobwebbing work? First, plot the function $y=f(x)$ along with the diagonal line $y=x$. The resulting figure makes it immediately obvious whether any fixed points exist; the number of intersections is precisely the number fixed points. Second, mark the point $(x_0,0)$ and draw a vertical line from the point to the function (whether above or below the point). Third, draw a horizontal line from that point to the diagonal line. This results in a line segment from $(x_0,0)$ to $(x_0,f(x_0))$, and another from $(x_0,f(x_0))$ to $(f(x_0),f(x_0))$. Fourth, repeat this process starting with the point on the diagonal. Continuing in this manner, the $x$-values of the vertical segments correspond to the values $\{x_i\}$ in the sequence. Figure 1 shows cobwebbing in action.

Figure 1. Cobwebbing demonstrates that iterating the sequence $x_n=x_{n-1}(3-x_{n-1})$ with initial condition $x_0=0.25$ slowly approaches the fixed point $x^*=2$.

Designing the First Iteration

Figure 2. The function, an initial point, and the $y=x$ line.

f(x)=3x-x^2

At this point, you can change the appearances or names of any of the objects, by right-clicking on the object and selecting "Properties". You should end up with something similar to Figure 2.

We can now implement the cobwebbing technique. There are a few ways to generate additional points that move when the initial point is shifted. We demonstrate two different methods. In what follows, we assume the initial point is named "A", the function is named "f", and the line $y=x$ is named "a".

Method 1: Using Perpendicular Lines and Points of Intersection

Figure 3. Creation of horizontal and vertical lines for the "up and over" cobweb construction.

1. Select the Perpendicular line tool, click on the point A, and then click on the x-axis. This creates a vertical line.
2. With the same tool selected, move your mouse to the intersection of the vertical line and the function $f(x)$. Once both pieces are highlighted (indicated by an increase in line thickness), click to select the point of intersection. Then, click on the y-axis. This creates a horizontal line through the point $(x_0,f(x_0))$.
3. Create a point at the intersection of the horizontal line and the diagonal line $y=x$ by selecting the Point tool and clicking the point of intersection.

Check that the dynamic structure is working properly by adjusting the point A. The additional lines should also move. The points that are free appear colored, while points that are not free appear black. The workbook should look like Figure 3.

I finish by cleaning up the workbook. Right-click on the objects whose labels are unnecessary and deselect the "Show label" option. This is also a good time to change the visual appearance of the figure. If you want to go with a minimalist approach, you may even wish to hide the displayed points and just display the lines. One useful trick is the Copy visual style tool, which allows you to quickly duplicate a visual style that you've created. See Figure 4 for my result.

Method 2: Using Manual Input

The second method uses direct input, and minimizes the creation of unnecessary features like the horizontal and vertical lines in the above. Here is the process:

1. Type Segment[A,(x(A),f(x(A)))] into the input bar. This creates the desired vertical segment. Note that "x(A)" indicates the value of the x-coordinate of the point A.
2. Create the horizontal segment by typing in Segment[(x(A),f(x(A))),(f(x(A)),f(x(A)))].
3. Turn off the labels on the segments, and change the appearance as desired.

Visually, this provides exactly the same output as the first result, as seen in Figure 4.

Figure 4. Clean version of the perpendicular-line construction.

Figure 5. Cobweb construction using direct algebraic input.

Subsequent Iterations

You could repeat either process to generate several steps of the cobweb diagram, but it's easier to automate the process. We describe two methods for iterating the process, which illustrate some of the most useful features of Geogebra.

Method 1: Tools

The first technique is to create a Tool. A tool is a customized function (or macro) in which several output objects are dependent on several input objects. Most of the functions we have used thus far are tools. Geogebra permits users to design their own tools as well.

The tool created here will have as inputs the function and initial point, and as outputs the vertical and horizontal cobweb lines. You must have completed one of the methods above before beginning this section. See Figure 6 for a visual of this process.

1. Select "Tools»Create New Tool…" from the menu. You select the outputs first. Select the vertical and horizontal segments corresponding to the first iteration.
2. For the inputs, select the function and the point A. The order in which these are listed corresponds to the order in which they must be selected to use the tool later, so be sure they are ordered properly. I prefer to select the point first, so I moved the point to the top of the list.
3. Give the function a name (like "CobwebIteration"), and for help type in "Point, Function". This provides a useful reminder of the order of inputs when the tool is selected.

Figure 6. Creating the CobwebIteration tool.

After clicking "Finish", the tool shows up in the normal toolbar. You can use the tool to perform further cobweb iterations by selecting the point of intersection of the last segment with the $y=x$ line, and then the function. Figure 7 demonstrates the result after several iterations. Note the new button on the right side of the toolbar. You can also save the tool just created, for use in other workbooks, by selecting "Tools»Manage Tools…" from the menu.

Figure 7. Iterated cobweb construction with a user-created tool.

The workbook is now fully functional as a demonstration of the cobwebbing technique. The author's versions are attached to this page¹. In the next section, we'll make the demo a little more powerful by allowing the user to change the number of iterations dynamically.

Method 2: Sequence

Geogebra also has the functionality to construct a sequence of objects which depend on some input parameter. This requires knowing a little more of the command line structure, but offers the added functionality of being able to choose the desired number of iterations.

There are two types of iteration processes available: Sequence, which produces a list of objects indexed by a particular value, and Iteration, which produces a list of numbers formed by iterating a single function.

values = IterationList[f,x(A),numIterations]

Segment[A,(x(A),f(x(A)))] cobwebHorizontal = Sequence[ Segment[(Element[values, i], Element[values, i+1]), (Element[values, i+1], Element[values, i+1])], i, 1, numIterations-1] cobwebVertical = Sequence[ Segment[(Element[values, i], Element[values, i]), (Element[values, i], Element[values, i+1])], i, 2, numIterations]

Figure 8. Cobweb construction with slider, allowing the user to change the number of iterations.

At this point, the user could export the displayed figure as an image file, creating beautiful images of cobwebbing. Figure 1 was exported from Geogebra as an SVG, or "Scalable Vector Graphics" file. This type of file can be displayed at any resolution without loss of image quality.

Exporting the Applet to the Web

Geogebra allows you to easily post workbooks that you create to a website. This section describes how to do this, and how to use Javascript to provide the user with a textbox to input the function directly.

Exporting to the Web

Figure 9. Exporting a Worksheet to HTML.

Warning: It is best to resize the window to your desired size before exporting. Otherwise, the change in size may not display all the objects in your worksheet properly, or may not display some of them at all.

Once you click "Export", an html file will be created along with a new worksheet file .ggb and two .jar files that are required for Java to run the program: geogebra.jar and geogebra_properties.jar. In order for the applet to work, you will need to upload all four files to a web folder, and link to the html file. Note that in some cases the .ggb files will not load properly because the file type is not "enabled" on the server. If this comes up, you can ask IT to permit you to post .ggb files. The author's version is posted here.

Adjusting the HTML and Implementing Javascript

After the html file has been created, it can be modified directly or with an html editor. One can add additional titles, links, and text, or update the appearance.

One particularly nice feature of Geogebra is that it can interface with Javascript. We'll create a simple form that the user can use to input a new function, similar to that shown in Figure 10. The Javascript code required is minimal. For further details on the Geogebra/Javascript interface, see [5, 6].

Figure 10. Javascript form input used to interface with Geogebra cobwebbing worksheet.

To implement the form, I inserted the following html code block immediately before the applet:

<form> <p align=center> Change function: <b>f(x)=</b> <input type="text" name="T1" size="20" value="3x-x^2"> <input type="button" value="Submit" name="B1" onclick="document.ggbApplet.evalCommand('f(x)='+T1.value);"> <input type="button" value="Reset" name="B2" onclick="T1.value='3x-x^2';document.ggbApplet.reset();"> </p> </form> <applet name="ggbApplet" ....

References

Much more is possible using Geogebra. An outstanding resource is the online wiki [4]. My collection of worksheets and webpages created with Geogebra is available at [7].

by elishapeterson