Enhancing your productivity with Eclipse

Eclipse can be used to debug your java applications. Here are a few tips that can help you debug better:

1. Remote Debugging
The eclipse IDE can remote debug your web application. Imagine being able to debug your development server from your local machine. Eclipse can help you do this. First you need to instruct your application / server to listen on a port for debug messages. That can be done using the -Xdebug flag

java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8787,suspend=n

This tells the JVM to listen for specific debug messages on port 8787. In eclipse open Bug Icon -> Debug configurations and select “Remote java application”. Mention the port and server address and you should now be able to remote debug the application. Make sure that the classes and source sync with each other. On a network where the bandwidth is poor, this technique will not work.

Remote java application

Use the display view:
The debug perspective in eclipse can open up a “Display” view that allows you to dynamically enter some code for execution when you hit a breakpoint. This view is priceless. You can dynamically execute code related to the variables that are in scope. Use the icons available on the top right hand corner of the view to do this.

Display View

Set breakpoints at different levels:
You can set class level, method level or line level breakpoints. Nothing special but once again it can save you time. Just set a breakpoint corresponding to a class declaration a method declaration or a specific line.

Set conditional breakpoints:
Breakpoints can be triggered conditionally. Simple right click on a breakpoint and select “Breakpoint properties” There are 3 settings that you can tweak.

1. Hit count – Break only when code flow passes over this breakpoint N times.

2. Condition – Break when a specific programmatic condition is reached.

3. Suspend VM Vs Suspend Thread – This is useful when debugging multithreaded application. If you want to suspend only the current thread and not all threads that are running through this code flow, you can use this drop down.

Breakpoint properties

Tweak the breakpoint

Specify a detail formatter of your own:
Use the Variables view to mention a detailed formatter for an object type. This will display the object in question in a different format when you look it up under Variables or in an inspection window.

Open the detail formatter

Type a detail format

See the results in the variable window (among other places)

Use inspection windows:
Inspection windows can reveal the detailed object graph of the instance in question. Simply highlight the variable and type the shortcut ctrl+shift+i

Inspect

Traverse the object graph

Use all instances / references:
Use the all instances / all references option in the Variables view to determine the usage of a particular Object type at runtime. Arguably a profiler might be better suited for this sort of work, but hey, you never know when you might need it.

View all instances of an object type

Change variable values dynamically:
You can use the Variables view to change the value of a variable dynamically. This helps to determine code flow control if you have conditional statements. You could also do the same using the Display view but the GUI helps.

Change value

Use the drop to frame feature:
The “drop to frame” feature allows you to retrace your path after making a minor code change. The code flow goes back to the line of code you have dropped to and executes once again. You could even, say, change a database variable and drop back a few call stacks behind to retrace your steps.

Drop frame

That’s about the list of debugging tips I know. Do you have one that could help other developers ? Drop a comment.

Optimize Eclipse in 5 Steps

As one of the most popular IDEs for developing Java applications, Eclipse can be adjusted with plenty of preferences. Here are my five favorite adjustments to tweak the Eclipse IDE. It works well with either the newest Eclipse Galileo or one of the older releases like Ganymede or Europa.

1.Improve performance by modifying startup arguments
Per default Eclipse starts with a low size of memory. This results in numerous garbage collections which slows the IDE. You can easily adjust the heapsize memory by setting vm parameters on startup. Use the -Xms parameter to set the minimum and -Xmx to set the maximum heapsize. I prefer to use 1 GB for both so the VM doesn’t have to increase maximum heapsize during runtime.
On Windows systems put a shortcut to the eclipse.exe and edit the target with your prefered VM-settings:
path/eclipse/eclipse.exe -vmargs -Xms1000M -Xmx1000M
To track the currently used heap memory and manually trigger the garbage collector to free up memory, go to Preferences -> General and activate Show heap status.

2.Improve performance by deactivating unused plug-ins
Each distribution of Eclipse contains plenty of plug-ins. It’s possible to deactivate several unused plug-ins without uninstalling them. So feel free to re-activate them later on demand. Go to Preferences -> General -> Startup and Shutdown to configure which plug-ins will be activated on startup.

3.Automatically Organize Imports on save
Eclipse is capable of adding imports to your classes automatically which is surely one of the most used features. The command can easily be accessed by using the appropriate keyboard shortcut. I recommend to let Eclipse automatically organize imports on save. Go to Preferences -> Java -> Editor -> Save Actions and activate Organize Imports. Feel free to add additional save actions here.

4.Refresh workspace automatically
Per default Eclipse does not refresh the workspace automatically when some files in the workspace are modified from outside the IDE. So if you copy some resources into your workspace (e.g. some icons to be included into your UI) you have to explicitly press F5 on the changed project to trigger a refresh.
It’s possible to let Eclipse refresh the workspace automatically, go to Preferences -> General -> Workspace then check Refresh automatically.
Some people claim that this feature might impact performance, but I’ve not seen any issues so far even on large workspaces. Let me know about your impressions.

5.Improve Package Explorer by using Java Type Indicator
Per default the Package Explorer uses the same icon for each class file. It’s possible to display different icons against the concrete file type, e.g. concrete class, abstract class, interface or enum.
This can be activated in Preferences -> General -> Appearance -> Label Decorations. Just activate the checkbox Java Type Indicator.
I’m sure there’re plenty more useful Eclipse adjustments. I would appreciate if you share your favorite tweaks with me. 🙂

The Liskov Substitution Principle (LSP)

Continuing with Object Oriented Design Principles (i.e. Open/Close Principle), I would like to share Robert Martin’s (Uncle Bob) views on Liskov Substitution Priciple (LSP)

“Subtypes must be substitutable for their base types”

“If S is a subtype of T, objects of type S should behave as objects of type T, if they are treated as objects of type T”

The LSP seems obvious given all we know about polymorphism. Lets understand with an example –

Consider the following Rectangle class:

// A very nice Rectangle class.
public class Rectangle {
private double width;
private double height;
public Rectangle(double w, double h) {
width = w;
height = h;
}
public double getWidth() {return width;}
public double getHeight() {return height;}
public void setWidth(double w) {width = w;}
public void setHeight(double h) {height = h;}
public double area() {return (width * height);
}

Now, how about a Square class? Clearly, a square is a rectangle, so the Square class should be derived from the Rectangle class, right? Let’s see!

Observations:

• A square does not need both a width and a height as attributes, but it will inherit them from Rectangle anyway. So, each Square object wastes a little memory, but this is not a major concern.

• The inherited setWidth() and setHeight() methods are not really appropriate for a Square, since the width and height of a square are identical. So we’ll need to override setWidth() and setHeight(). Having to override these simple methods is a clue that this might not be an appropriate use of Inheritance!

Here’s the Square class:
// A Square class.
public class Square extends Rectangle {
public Square(double s) {super(s, s);}
public void setWidth(double w) {
super.setWidth(w);
super.setHeight(w);
}
public void setHeight(double h) {
super.setHeight(h);
super.setWidth(h);
}
}

Everything looks good so far. But check this out!

public class TestRectangle {
// Define a method that takes a Rectangle reference.
public static void testLSP(Rectangle r) {
r.setWidth(4.0);
r.setHeight(5.0);
System.out.println(“Width is 4.0 and Height is 5.0” + “, so Area is ” + r.area());
if (r.area() == 20.0)
System.out.println(“Looking good!\n”);
else
System.out.println(“Huh?? What kind of rectangle is this??\n”);
}

public static void main(String args[]) {
//Create a Rectangle and a Square
Rectangle r = new Rectangle(1.0, 1.0);
Square s = new Square(1.0);
// Now call the method above. According to the
// LSP, it should work for either Rectangles or
// Squares. Does it??
testLSP(r);
testLSP(s);
}
}

Test program output:

Width is 4.0 and Height is 5.0, so Area is 20.0 Looking good!

Width is 4.0 and Height is 5.0, so Area is 25.0 Huh?? What kind of rectangle is this??

it looks like we violated the LSP!

• What’s the problem here? The programmer of the testLSP() method made the reasonable assumption that changing the width of a Rectangle leaves its height unchanged.

• Passing a Square object to such a method results in problems, exposing a violation of the LSP

• The Square and Rectangle classes look self consistent and valid. Yet a programmer, making reasonable assumptions about the base class, can write a method that causes the design model to break down

• Solutions can not be viewed in isolation; they must also be viewed in terms of reasonable assumptions that might be made by users of the design

• A mathematical square might be a rectangle, but a Square object is not a Rectangle object, because the behavior of a Square object is not consistent with the behavior of a Rectangle object!

• Behaviorally, a Square is not a Rectangle! A Square object is not polymorphic with a Rectangle object.

• The Liskov Substitution Principle (LSP) makes it clear that the ISA relationship is all about behavior

• In order for the LSP to hold (and with it the Open-Closed Principle) all subclasses must conform to the behavior that clients expect of the base classes they use

• A subtype must have no more constraints than its base type, since the subtype must be usable anywhere the base type is usable

• If the subtype has more constraints than the base type, there would be uses that would be valid for the base type, but that would violate one of the extra constraints of the subtype and thus violate the LSP!

• The guarantee of the LSP is that a subclass can always be used wherever its base class is used!

How to Become Unforgettable

Yet another blog from Robin Sharma which would help in shaping your career and taking it to new heights –

A piece of being a Leader Without a Title involves being so brilliant, gifted and human at what you do that people cannot forget who you are. Your good name becomes tattooed on the minds and hearts of everyone whose lives you touch. Hoards of roving ambassadors tell everyone they know about the experience you created for them – and of your rare air genius. That’s the space you need to play at. To succeed in business today.

4 Best Practices I teach to my clients that will help you get there:

1. Keep Your Promises. Trust lives at the foundation of every great relationship. And business is all about relationships. When people like you, they buy from you – and help you in all ways. By becoming impeccable with your word, trust grows wildly.

2. Be BIW (Best in World). Being excellent at what you do is just the price of admission in our globalized, uber-connected world. To succeed and be truly unforgettable, may I suggest that the standard you play at is The Best in The World. At my leadership seminars I sometimes run an exercise that begins with this question: “what 10 things would the person who is best in the world at what you do be doing on a regular basis that you are not doing?”. Start your list.

3. Be Radically Ethical. The pristine reputation that took you decades to build could be torn down in 60 seconds of bad judgment. Seriously. Just watch the news these days and you’ll get what I mean. To show leadership in business (and life) today, it’s mission-critical to be radically ethical. No dishonorable move goes unnoticed. Decency wins.

4. Be fun. Whatever happened to fun? Stop taking life so seriously. Generate the ability to laugh – even at the toughest of times. You become unforgettable – and irresistible the moment you lighten up. And get that smile back on your face. Life’s a short ride when you really think about it. Might be smart to enjoy every turn of it.

Open Close Principle

In continuation with my previous blog on SOLID (i.e. Principles of Design in Object Oriented Paradigm) I would like to share Robert Martin’s (Uncle Bob) thoughts on next principle – which is Open Close Principle

SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.)
SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR
MODIFICATION.

When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad” design. The program becomes fragile, rigid, unpredictable and non-reusable. The open-closed principle attacks this in a very straightforward way. It says that you should design modules that never change. When requirements change, you extend the behavior of such modules by adding new code, not by changing old code that already works.

Modules that conform to the open-closed principle have two primary attributes.

1. They are “Open for Extension”.

This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.

2. They are “Closed for Modification”.

The source code of such a module is inviolate. No one is allowed to make source code changes to it.

It would seem that these two attributes are at odds with each other. The normal way to extend the behavior of a module is to make changes to that module. A module that cannot be changed is normally thought to have a fixed behavior. How can these two opposing attributes be resolved?

In Java, using the principles of object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

Figure 1 shows a simple design that does not conform to the open-closed principle. Both the Client and Server classes are concrete. The Client class uses the Server class. If we wish for a Client object to use a different server object, then the Client class must be changed to name the new server class.

Figure-1

Figure 2 shows the corresponding design that conforms to the open-closed principle. In this case, the AbstractServer class is an abstract class. The Client class uses this abstraction. However objects of the Client class will be using objects of the derivative Server class. If we want Client objects to use a different server class, then a new derivative of the AbstractServer class can be created. The Client class can remain unchanged.

Figure-2

Single Responsibility Principle

One of the most widely used principles of design in Object Oriented Paradigm is SOLID
S – Single Responsibility Principle
O – Open Close Principle
L – Liskov Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle

To begin with I would share Robert Martin’s (Uncle Bob) thoughts on Single Responsibility Principle.

If a class has more then one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.

For example, consider the design in Figure 9.1. The Rectangle class has two methods shown. One draws the rectangle on the screen, the other computes the area of the rectangle.

Figure 9.1 More than One Responsibility

Two different applications use the Rectangle class. One application does computational geometry. It uses Rectangle to help it with the mathematics of geometric shapes. It never draws the rectangle on the screen. The other application is graphical in nature. It may also do some computational geometry, but it definitely draws the rectangle on the screen.

This design violates the SRP (i.e. Single Responsibility Principle). The Rectangle class has two responsibilities. The first responsibility is to provide a mathematical model of the geometry of a rectangle. The second responsibility is to render the rectangle on a graphical user interface.

The violation of SRP causes several nasty problems. Firstly, we must include the GUI in the computational geometry application. If this were a C++ application, the GUI would have to be linked in, consuming link time, compile time, and memory footprint. In a Java application, the .class files for the GUI have to be deployed to the target platform.

Secondly, if a change to the GraphicalApplication causes the Rectangle to change for some reason, that change may force us to rebuild, retest, and redeploy the ComputationalGeometryApplication. If we forget to do this, that application may break in unpredictable ways.

A better design is to separate the two responsibilities into two completely different classes as shown in Figure 9.2. This design moves the computational portions of Rectangle into the GeometricRectangle class. Now changes made to the way rectangles are rendered cannot affect the ComputationalGeometryApplication.

Figure 9.2 Separated Responsiblities

What is a Responsibility?

In the context of the Single Responsibility Principle (SRP) we define a responsibility to be “a reason for change.” If you can think of more than one motive for changing a class, then that class has more than one responsibility. This is sometimes hard to see. We are accustomed to thinking of responsibility in groups. For example, consider the Modem interface in Listing 9-1. Most of us will agree that this interface looks perfectly reasonable. The four functions it declares are certainly functions belonging to a modem.

Listing 9-1

Modem.java — SRP Violation interface Modem
{
public void dial(String pno); public void hangup();
public void send(char c); public char recv();
}

However, there are two responsibilities being shown here. The first responsibility is connection management. The second is data communication. The dial and hangup functions manage the connection of the modem, while the send and recieve functions communicate data.

Should these two responsibilities be separated? Almost certainly they should. The two sets of functions have almost nothing in common. They’ll certainly change for different reasons. Moreover, they will be called from completely different parts of the applications that use them. Those different parts will change for different reasons as well.

Therefore the design in Figure 9.3 is probably better. It separates the two responsibilities into two separate interfaces3. This, at least, keeps the client applications from coupling the two responsibilities.

Figrue 9.3 Separated Modem Inerface

However, notice that I have re-coupled the two responsibilities into a single ModemImpl class. This is not desirable, but it may be necessary. There are often reasons, having to do with the details of the hardware or OS, that force us to couple things that we’d rather not couple. However, by separating their interfaces we have decoupled the concepts as far as the rest of the application is concerned.

We may view the ModemImpl class is a kludge, or a wart; however, notice that all dependencies flow away from it. Nobody need depend upon this class. Nobody except main needs to know that it exists. Thus, we’ve put the ugly bit behind a fence. It’s ugliness need not leak out and pollute the rest of the application.

Conquer Fear

Recently I came across a very motivational article by Kishore Biyani (CEO of Future Group) in Times of India, which I would like to share with the e-world.

You have nothing to fear but fear itself

Darr ke aagey jeet hai – Conquer fear and you can conquer anything. I learnt this fairly early while growing up in a joint family along with 13 siblings and cousins.

Every evening, we would gather around our grandmother to hear her stories. One of her favourite stories revolved around five pilgrims who were on a journey to the holy places in the Himalayas. On a bitterly cold night, they arrived at a dharamshala. It had only one room and the gatekeeper warned them against staying there as legend had it that it was inhabited by a big snake. He told them no one had ventured inside for years. On hearing this, the pilgrims decided to play safe and spend the night in the open.

After a few shivering hours, one of them overcame his fear and decided to check the room. On entering, he didn’t find a snake. Instead, a rope lay on the floor. In the dark it resembled a snake. But the other pilgrims didn’t believe the account and decided to sleep outside. The brave one slept soundly; for his fellow travellers it was a long night.

As my grandmother would explain, failure exists only in one’s imagination. We fear failure, because we fear criticism, ridicule or rejection. But the truth is that anyone who has been successful has failed at some stage of their life. From failure comes knowledge of what works and what doesn’t; from failure comes knowledge of one’s strengths and weaknesses and it’s from failure that one begins a more determined attempt to achieve success.

As one grows up there comes the realization that there is no standard measure of failure or success. It is a relative term. What one person perceives as extraordinary success may be an ordinary accomplishment for another. What may seem a failure today often turns out to be insignificant in the long run?

Thankfully, I grew up in an environment where there were no high expectations I would excel academically. I never came first in any school exam. I hardly attended classes at college. That may not be the best thing to do but in retrospect I believe that there are many lessons to learn outside the classroom. Learning about how to build relationships and business partnerships; about human behavior and social dynamics is just as important as classroom lessons to succeed in any field.

It is a fact that in our society we ridicule failure. Rather than encourage people to take the road less travelled, we discourage them. There is encouragement to conform to a set pattern rather than stand out in a crowd. This is why failing an exam or a new venture is feared.

I don’t think setbacks, disappointments, rejections and unsuccessful attempts can be called failures. They are steps to success. How one deals with a setback determines the success of the next step. A sudden setback can be seen as a brick wall. It can also be seen as a stepping stone. It’s the way one perceives it that determines whether an unsuccessful attempt turns into a failure. Absolute failure is about not trying to do new things; it’s about lack of conviction; it’s about giving up.

Kishore Biyani: Chief executive officer of the Rs 5,000-crore Future Group. Biyani, who ranked 20 in a class of 35 at school, is regarded as the man who pioneered the retail revolution in India.

11 Rules to change the world

Recently I came across a very inspirational article by Robin Sharma. I liked it so much that I thought of publishing the article on my blog.

1. You be the change you dream of seeing (Thanks Mahatma Gandhi). “If everyone of us would sweep their own doorstep, the whole world would be clean,” observed Mother Teresa. She was right.

2. Make time every day to reconnect to your highest ideals and boldest dreams. Without hope, people perish.

3. Leave every person you meet better than you found them. Life’s too short to withhold encouragement and kindness.

4. As I wrote in ‘The Monk Who Sold His Ferrari”, see every setback as a stepping stone and every problem as a blessing in disguise. Contrary to what critics might say, these are NOT corny aphorisms. They are timeless truths of humanity. (And critics are just people too scared to grow their dreams anyway – pay no attention to them. The world needs more people lifting people up rather than putting people down).

5. Go the extra mile in everything you do – you don’t need a title to be a leader. And on your deathbed, you’ll never regret expressing the best within you

6. Do what’s right rather than what’s easy. Being a great person isn’t a popularity contest. Many of the greatest leaders were disliked because they refused to bend to the winds of public opinion. That’s called Strength of Character

7. Care for your health. You elevate the world by elevating yourself and your health really matters. Why be the richest person in the graveyard?

8. Tell your kids they are geniuses – and how much you adore them. Each of us are born geniuses but lose that gift within the first 6 years of our lives as we adopt the fears and limiting beliefs of those around us. Your kids are the leaders of the future. Grow their potential. Now.

9. Learn something new every day. As you grow, you begin to see possibilities you didn’t have the eyes to see before. Read from an inspiring book, listen to an audio program, visit a good blog, go to a powerful workshop or have a conversation with an elder. One idea is all it takes to transform your life.

10. Keep your life simple. Please. The secret to success and happiness is building your life around a few important things. The person who tries to do everything accomplishes nothing. As I recently mentioned on my blog, “What’s the point in being busy doing the wrong things?”

11. Remember that life is a mirror and we receive what we give out. To get more joy, give more joy. To have more respect, give more respect. To realize your dreams, help others realize theirs.

Binding XML to Java code

Binding XML to java code

There are several scenarios where one system gets data in the form of XML file and the data contained in the (XML) file is used in the application. There are several ways to do that –

1. JAXB
2. XStream
3. XPath
4. XQuery etc . . .

However, these are bit performance intensive, as it requires XML file traversal through nodes, tags and attributes. More elegant approach is to convert XML to object. As a result of object we (i.e. Java Developers) have an upper hand in terms of its utilization -:), rather than firing XPath, XQueries . . . . So in my blog I shall briefly explain JiBX and its utility. At the core of these differences is the parsing technology that’s used when marshalling and un-marshalling documents takes place. The established frameworks are all based on the widely used SAX2 push parser API. JiBX instead uses a newer pull parser API that provides a more natural interface for dealing with the sequence of elements in a document. Because of this different API, JiBX is able to use relatively simple code to handle un-marshalling.

JiBX

JiBX is a framework for binding XML data to Java object. JiBX uses binding definition file to tell JiBX framework how object needs to be created

Figure 1. Example bindings

JiBX reads a binding definition file to control how the code it adds to your classes converts instances to and from XML. JiBX isn’t the only data binding framework that supports this type of approach — Castor, for one, also handles this — but JiBX goes further than the alternatives in allowing you to change the relationship between your classes and the XML document. For various types of bindings provided by JiBX framework please visit http://jibx.sourceforge.net/tutorial/binding-tutorial.html

The actual class file modifications are done by a JiBX component called the binding compiler. The binding compiler is executed at program assembly time — after you’ve compiled your Java language source code to class files, but before packaging or executing the class files. The binding compiler reads one or more binding definition documents. For each class included in any of the bindings it adds the appropriate marshalling or un-marshalling code. Normally the total number of added classes and the total size of the added code are fairly small.

The generated code (i.e. including base class and added binding code) comparison is given below

Figure 2. Binding code comparison

Performance

JiBX is designed for runtime performance. There are three main aspects

1. Efficient un-marshalling –

It is achieved using Pull Parser. JiBX uses a pull parser for un-marshalling so that it can take advantage of this code structure advantage. Because the code for pull parsing can be much simpler than that for event-driven parsing, JiBX is able to use byte code enhancement to add both marshalling and un-marshalling code to your class definitions. Using byte code enhancement in turn lets JiBX make use of the other two performance aspects.

1. Direct access to data
2. Lean runtime –

Configuration information is normally processed at application assembly time (after compiling classes), and is embedded directly in the code added by byte code enhancement. Other frameworks that read configuration files at run time (most do not) suffer a performance disadvantage both from the actual processing time and from the added code needed to support this. This can make for a very slow start on execution, as classes are loaded and compiled to native code by the JVM. JiBX’s approach of handling the entire configuration prior to running the application minimizes start up overhead, both directly and through avoiding unnecessary run time code. JiBX’s use of a pull parser also helps keep the run time small and efficient, as does its limited validation support – JiBX automatically checks many aspects of a document based on your mapping when un-marshalling, but does not support in-memory validation.

Performance Statistics

Figure 1 – Reading large documents to memory (i.e. XML to Object)

Figures 1 gives the timing results for reading an XML document (un-marshalling it, in data binding terms) and constructing an in-memory representation using the dom4j document model and various data binding approaches. In these charts you can regard the first timing value, for SAX2, as a base time for parsing the documents. The document models and data binding implementations use the parse results to build their representations in memory, so they’re never going to be faster than the parser itself. The two data binding tests based on mappings, rather than code generation, are noted in the captions.

Figure 2 – Writing large documents from memory (In memory object to XML)

Figures 2 gives the timing results for generating the XML text serialization (marshalling it, in data binding terms) of an in-memory representation using dom4j and various data binding approaches. These charts use the same vertical scale as the previous pair to simplify comparisons, but differ in that there’s no equivalent to the SAX2 parser figure.