Careers: Interviews
JAVA Expert Martin Bond

This week, Stephen Ibaraki, I.S.P., has an exclusive interview with, Martin Bond, B.Sc. M.Sc. C.Eng. M.B.C.S., one of the key authors of SAMS Teach Yourself J2EE in 21 Days with EJB, JSP, Servlets, JNDI, JDBC, and XML. Martin, who has an honours degree and a masters degree in computer science, is also a European chartered engineer. Martin has developed parallel processing compilers for Inmos and he has designed systems using C++, Java, JavaScript plus he has developed training courses on Unix programming, Solaris security, Java programming and XML.

Martin is an international expert in application development, deployment, consulting, training, and technical writing. We were able to catch Martin at Content Masters Ltd., a technical authoring company in the UK specializing in the production of training and educational materials -

Q: Your combined accomplishments are staggering. Thank you for agreeing to this interview.
A: My pleasure.

Q: I reviewed your most informative and useful book. What led you to write this masterful work?
A: I wouldn't describe it as masterful; large certainly, but then J2EE is a large subject. I was contacted by Content Master to see if I was interested in contributing to a book about J2EE. As I have previously written training courses and white papers I was interested in extending my writing skills to include a book; and J2EE is a subject I teach on training courses. The request also coincided with a quiet period in my schedule allowing me to take on 4 or 5 of the chapters at very short notice.

Q: What ten or more tips can you provide from the book and about developing in the Java space?
A: They are:
  1. Keep learning through reading and training courses. Java is continually developing and there is always something new to learn.
  2. Consider multi-threading issues carefully, especially with servlets and JSPs. A large number of sporadic and hard to reproduce bugs can usually be traced to multi-threading problems. Most developers do not understand how to use multi-threading and are unaware of the problems of sharing data (objects) across more than one thread.
  3. Design in exception handling from the start; don't add it on when the compiler refuses to compile your code because you haven't put a try/catch block around a method call. Plan where you will catch and recover from thrown exceptions in your method call hierarchy, and propagate errors back to these known recovery points.
  4. Don't expose entity beans to clients. Always hide them behind session beans.
  5. Use session beans to enforce business rules and entity beans to enforce data integrity rules.
  6. I hate to say this but I don't think entity beans are very useful at the present time and I personally would rather use Data Access Objects and connection pooling to access a database directly rather than use entity beans.
  7. Use entity beans as an in memory cache for readonly data such as lookup tables.
  8. Make more use of JNDI for storing information rather than use yet another database table
  9. Worry about data security (integrity and confidentiality).
  10. Worry about performance, all these RMI method calls and proxy/adapter objects seriously affect performance.

Q: How would you contrast enterprise development in Java versus .NET and is there a winner? What do you see for the future of both development environments?
A: Like many developers I have concerns about the security of .NET and the tendency for Microsoft to change the standard every 18 months or so. In many ways .NET is a rebranding of existing technologies such as DCOM with minor (or major) API changes together with useful new features. However the proliferation of languages (C++, VB, C# and now J#) must be causing problems in many development groups with respect to skill shortages and choosing which language to use.

The .NET platform ties the developer to a single platform (WinTel) but this can be an advantage as it takes away many of the hardware/software manufacturer and product architecture issues that have to be decided in an open systems environment. The development tools provided with .NET are the best in the industry and certainly improve developer productivity.

J2EE is open and whilst Sun control the Java and J2EE standard there are a large number of partners (IBM, BEA, Netscape, etc.) that act as a controlling influence that prevents Sun from making radical changes. Even though J2EE is standard there are still grey areas around the edge of the standard that allow different vendors to add value. The ability to choose from one of many vendors gives the developer a choice that will help keep all the vendor's honest with regard to pricing and licensing. Having free to use J2EE servers such as JBoss makes J2EE accessible to cost conscious users.

Performance, reliability and scalability are an issue for enterprise systems and here I think there are some differentiators. The .NET platform uses native machine code and must therefore be faster than the interpreted byte codes of Java. A good JVM (such as HotSpot from Sun Microsystem's) will improve the performance of Java to be close to native code, but it is unlikely to ever match it. However raw processor speed is less of an issue these days given the incredible speeds of modern processors. Unless an application is heavily into number crunching then disk and network I/O performance is usually the limiting factor. Having said that, many data encryption and multi-media manipulation algorithms require CPU intensive operations. Reliability depends on the underlying platform and I believe Unix and Linux are more reliable than NT (2000 or XP). I personally would be wary of running a critical enterprise system on an NT platform.

I see a future for both platforms. I think .NET with its good development tools supports rapid application development, and is useful for systems that are constantly changing and are not essential. I think J2EE is more applicable to mission critical systems that have a long lifetime and whose requirements do not change too rapidly. I think the success or failure of the technologies will be affected more by external criteria than the internal architectural merits of the products. I'm thinking of things like development tools, administrative tools and licensing/cost issues. I wonder how many .NET users are evaluating J2EE because of the new XP licensing scheme?

Q: Describe future book titles and articles that we can expect from you?
A: Myself and Debbie Law are working on a book on Jakarta Tomcat for a new SAMS series (the name has yet to be finalized). This is due to be published in Nov 2002 and will cover Servlet/JSP development techniques, Tomcat administration and some of the Jakarta tools like Struts and Cactus.

Q: Can you describe some of the projects that you have worked on and what tips you can pass on?
A: My last commercial project was a simple time recording system written using servlets (this was before JSPs were available). It took longer than I planned. With hindsight, I wish I had been able to use JSPs and had put more effort into the design. A couple of years ago (for my own interest) I wrote a simple Java MIDI system that allows me to write and playback classical guitar music. I learnt a great deal about Java design and implementation writing the program but I wish I had understood Java idioms and design patterns better; but learning how to design and write Java code was one of the reasons for the project. I have recently started another version of the program utilizing a better overall design (I decided I couldn't refactor the original code), one day I might release the program as shareware or freeware (if I ever finish it).

Q: What are ten or more traps or pitfalls that developers should be wary of and avoid?
A: They are:
  1. Complacency – you can always improve on what you do
  2. Arrogance – you don't know everything and can always learn something new
  3. Laziness – shortcuts will always come back to bite you
  4. Lack of testing
  5. Coding without thinking. Design first, code second.
  6. Reinventing the wheel – learn the standard Java classes (especially the java.test amd java.util packages) and use provided functionality rather than write your own class. Look on the web at sites such as JARS (, Jakarta (, Source Forge ( and Alphaworks ( for open source packages that will do what you want.
  7. Not understanding and using design patterns
  8. Not attending training courses to gain extra knowledge
  9. Using the same technology for every project rather than choosing the most suitable technology for each problem
  10. Eating too much pizza

Q: Can you share your leading career tips for those thinking of getting into the computing field?
A: They are:
  • Get a formal IT education first as what you learn at school/college will help in the future even if you can't apply it immediately.
  • Look at the job specification rather than the salary. A more interesting job will be more rewarding; higher salaries come with time and experience.
  • Expect to work long hours. Even if you are not in the office working you will have to spend time keeping abreast with the new technology.
  • Don't expect to learn everything and then be able to sit back and relax. After 25 years in the industry I am always learning something new.
  • Be prepared to have people corner you at parties and bore you with tales of their PC hardware statistics or horrors stories of software problems.

Q: What are the hottest topics that all IT professionals must know to be successful in the short term and long term?
A: That changes on a regular basis. In 1997 Data Warehouses, SAP, Design Patterns and C++ were hot, Java was lukewarm, .NET didn't exist and Linux was seen as a student/university toy.

These days I think .NET, J2EE and Security are the hot topics.

Long term I think security and digital certificates will become more widely used and Linux will gain ground at the expense of both Windows/XP and Solaris. I expect Java and .NET to remain hot for at least 3 years more.

Q: What would be your recommended top ten references for the serious developer?
1-8) The web. There is so much out there that you can nearly always find the answer to your problem. Books are good but given the fast changing nature of IT most books are out of date after 2 years.
9) The javadocs for product APIs
10) I would advise developers to read the following books for widening their knowledge rather than adopting the practices (such as XP) that are covered.
  • The Mythical Man Month – Fred Brooks
  • Extreme Programming Explained – Kent Beck
  • Refactoring – Martin Fowler
  • Programming Pearls – Jon Bentley
  • The Elements of Java Style.
It is out of print now but I regard The Elements of Programming Style – Kernigan and Plauger, as the best book on thinking about and writing software (it made me rethink how I wrote code).

Q: If you were doing this interview, what three questions would you ask of someone in your position and what would be your answers?
A: Why did you get into IT?
It was easier than Physics and Math which was my initial degree subject.

What do you enjoy the most?
The hands on technical work and passing on my knowledge. I am an educator (trainer, course writer, book writer) because it lets me evaluate and use the latest technologies.

What do you dislike the most?
Maintaining someone else's code (or mine for that matter).

Q: It’s a blank slate, what added comments would you like to give to enterprise corporations and organizations?
A: Invest more in your staff in the form of training and career paths. Many developers move into management to get a higher salary rather than a desire to be a manager. Provide a career path for good developers to remain hands on whilst earning a higher salary. Management is a separate career path requiring different skills and there is no necessity for a manager to have a higher salary than the staff they manage.

Q: Thank you for sharing your valuable insights with us today and we look forward to reading your books, and articles.
A: Thank you.


Suggestions for this page?
Email NPA Web Services: click here

NPA      facebook      LinkedIN logo
© Copyright Network Professional Association® 1994-2024 All Rights Reserved.
NPA Privacy Statement