Share/Save

No related posts.

JavaOne and Oracle Develop 2010

Share/Save

No related posts.

Receiving null is confusing. When you make a function call and the result is null what does it mean? Was the data not found? Was there an exception in the function that was silently swallowed resulting in the return of a null object? You’re not really sure if null is an expected return value. If no exception is thrown then you just kind of assume that null is a valid return value. However, you can’t really do anything with the returned null object so what do you do now?

Here are a couple of alternatives to returning null:

Use the Empty Collection Methods

If you are working with returning collection objects from your function you should return an empty collection rather than a null object. This is very easy to do with the Collections class. There are three static methods available:

• Collections.emptyList()
• Collections.emptySet()
• Collections.emptyMap()

An empty List is easily instantiated for return as shown here:

   List<String> myList = Collections.emptyList();

Returning an empty List eliminates the required check for null by the function caller. Now instead of having code which looks like this:

   List<String> names = getNames();
   if(names != null) {
      for(String name : names) {
         System.out.println(name);
      }
   }

You can simply write the following without worrying about a NullPointerException:

   List<String> names = getNames();
   for(String name : names) {
      System.out.println(name);
   }

This second example is much cleaner, easier to read and understand. Returning empty Collections is much safer as well since it avoids the potential run time exception: NullPointerException.

An unchecked exception represent defects in the program (bugs) - often invalid arguments passed to a non-private method. To quote from The Java Programming Language, by Gosling, Arnold, and Holmes : “Unchecked runtime exceptions represent conditions that, generally speaking, reflect errors in your program’s logic and cannot be reasonably recovered from at run time.”[1]

Certainly an empty collection is not a bug! So lets just return an empty collection rather than a null reference. In addition, testing for an empty collection is a lot more intuitive than testing for null.

   List<String> names = getNames();
   if(names.isEmpty()) {
      //throw an Exception
      //or do something else
      //or do nothing at all

   }
   

Throw an Exception

It’s perfectly acceptable to throw a custom checked exception alerting the calling client that the requested object cannot be populated or retrieved. This approach is much more revealing and forces the calling client to handle the potential problem. It also eliminates the need to check the returned object for null.

A checked exception is guaranteed to be handled so you gain more control over your program. A RuntimeException may or may not be handled by the caller and will bubble up until either it is caught or reaches the top of the caller chain.

Conclusion

Nulls are useful under certain conditions when null values are expected. However, for the above conditions with collections and data retrieval I feel it has been abused. Use the empty collection and avoid returning null objects whenever possible. It will make code cleaner, easier to read and debug.

1. “checked versus uncheck exceptions” JavaPractices.com. 2010 Hirondelle Systems. 6 June 2010 <http://www.javapractices.com/topic/TopicAction.do?Id=129>

Share/Save

No related posts.

Share/Save

No related posts.

A Simple Service

To start out you should create an interface defining your business methods. I will keep the implementation extremely simple so we can focus on the details of web services. Here’s our interface named SimpleServiceWS

public interface SimpleServiceWS {

	public String simpleMethod();

}

The next step is to create a plain java class (POJO) which implements this interface. I’ll name it SimpleServiceImpl

public class SimpleServiceImpl implements SimpleServiceWS {

	public String simpleMethod() {
		return "Simple response";
	}

}

Please note that it is not required to create and implement an interface and almost every web service example I found did not do so. I feel it is good practice and consistent with Java programming practices to program against interfaces.

What we have so far is just a plain Java class (POJO) that returns a simple string. Now we have to decorate our class with some annotations to make it behave as a web services.

import javax.jws.WebService;

@WebService(
		serviceName="SimpleService",
		portName="SimpleServicePort",
		endpointInterface="net.franksalinas.javablog.SimpleServiceWS")
public class SimpleServiceImpl implements SimpleServiceWS {

	public String simpleMethod() {
		return "Simple response";
	}

}

I added the @WebService annotation and supplied some values to the annotation attributes. You can simply add the @WebService annotation without specifying any of the attributes and they will pick up default values based on the class and package names. However, there is one exception. If you choose to define and implement an interface you must do two things:

1. You must decorate the interface with the @WebService annotation.
2. You must also supply the endpointInterface annotation attribute with the fully qualified name of the interface in the implementation class.

import javax.jws.WebService;

@WebService()
public interface SimpleServiceWS {

	public String simpleMethod();

}

As far as code goes this is all there is to it. The remaing steps describe how to package and deploy these objects.

Package and Deploy

As I mentioned above we will package and deploy these classes as a servlet implementation. I am most familiar with JBoss so that is the application server I will use but any servlet container should work fine.

Create a new xml file named web.xml and define the servlet mappings for the SimpleServiceImpl class as shown here.

<?xml version="><?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC
	"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
	"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
	<servlet>
		<servlet-name>SimpleServiceWS</servlet-name>
		<servlet-class>net.franksalinas.javablog.SimpleServiceImpl</servlet-class>
	</servlet>

	<servlet-mapping>
		<servlet-name>SimpleServiceWS</servlet-name>
		<url-pattern>/SimpleService</url-pattern>
	</servlet-mapping>
</web-app>

Now create a WEB-INF directory and place this file there. Compile your Java files and place them in a folder named classes. Create a folder named dist. Copy the WEB-INF and classes directory to this new folder. Now create a JAR file named SimpleService.war containing the contents of dist directory. (Visit http://en.wikipedia.org/wiki/Sun_WAR_(file_format) for more info on the WAR file structure.)

You should now have a WAR file with the following structure:

META-INF/
META-INF/MANIFEST.MF
WEB-INF/
WEB-INF/web.xml
classes/
classes/net/
classes/net/franksalinas/
classes/net/franksalinas/javablog/
classes/net/franksalinas/javablog/SimpleServiceImpl.class
classes/net/franksalinas/javablog/SimpleServiceWS.class

Now you can copy this SimpleService.war file to your application server’s deployment directory (<jboss_home>/server/default/deploy) and start the server. Your web service will be deployed. On JBoss you can see the deployment and access the WSDL for the service at url http://127.0.0.1:8080/SimpleService/SimpleService?wsdl

That’s all there is to it!

Note that we did not implement the javax.servlet.http.HttpServlet interface in the service class. It is not required but may be considered good practice to do so depdending on your implementation.

Summary

In this example we created a simple web service using JAX-WS and packaged and deployed the implementation as a servlet configuration. We learned that web services are nothing more than plain old Java objects (POJOs) that are decorated with a few simple annotations and that servlet configurations do not require the web service class to implement the javax.servlet.http.HttpServlet interface. We covered packaging the code as a WAR file and deploying on the JBoss application server.

This is a very simple example and there’s a lot more material to cover. I hope you found this posting informative and helpful. You can download all the source code for this example here: SimpleService.zip.

Share/Save

Related posts:

1. Web Services on JBoss I’ve been working on a project which requires developing some...
2. The EJB Specification, Concurrency, and Batch Processing The EJB specification does not leave much room for implementing...

Java tip: How to read files quickly | Nadeau Software

Share/Save

No related posts.

Renaud Waldura’s The Final Word On the final Keyword .

Share/Save

No related posts.

EGL Community Edition 1.0 is an Eclipse based tool that is free for download. To learn more read the Quick Overview.

Share/Save

No related posts.

I just finished reading The Art of Agile Development
by James Shore and Shane Warden. I picked up the book because I wanted to find out more about agile development. I hear a lot of terms thrown around the office about scrum processes and agile development. However, as I paid more attention to the activity within the work place I started to question the validity of our processes as being “agile”.

A scrum meeting which pushes almost an hour in time does not fit the definition of a stand-up scrum meeting. Developing formal requirements and functional specification documentation up front and scheduling around those processes fit in the “traditional” waterfall methodologies rather than agile methodologies. It seems to me that we are practicing traditional waterfall methodologies and masking it behind scrum terminology. I think there is room for improvement in our development processes and I want to learn as much as I can to help improve the process and speed up development.

The book provided exactly the information I was seeking. It’s loaded with information and thoroughly covers the entire software development process focusing on Extreme Programming (XP) methodologies. The XP lifecycle includes all the phases of the traditional software development life cycle (SDLC) of planning, analysis, design, code, test and deploy but eliminates formal documentation and reorganizes the phases into more efficient processes through the use of face-to-face collaboration, incremental design and parallel task execution.

XP emphasizes pair programming, test-driven development (TDD), iterative design, an open, collaborative workspace, and on-site customer support (e.g. Product Manager or other team members who are able to provide real requirements). The authors walk you through adopting XP practices from planning workspaces, pair programming techniques, handling changing requirements and team organization along with commentary on alternatives to XP methods.

If you are interested in XP, or agile development in general, and want to get a solid understanding of how to work in or create an agile team this is the resource. I highly recommend it.

Share/Save

No related posts.

1. Technical Knowledge
2. Verbal and Written Communication
3. White Board
4. Time Management
5. Social Interaction

Technical Knowledge

As a software developer this is a set of skills which is constantly evaluated and tested by managers and co-workers. It’s a topic of your performance review and is the most highlighted topic on your resume. If you fluffed up your resume to land that job you’d better study hard nights and weekends to deliver the goods; this is not a skill you can fake for long.

Keeping up with the latest technology is tough and requires many hours of personal time to read about and play with the latest and greatest of technology X. Technology moves too fast to keep up with it all so narrow your focus to specific areas of interest and become an expert those areas. Remember that technology is only a tool for implementing software designs. The selected technology, or programming language, should not dictate your software design rather your software design should dictate which technology you use to best implement the design. Whatever you do, target technical skills that you find interesting and maximize your marketability

While it’s fine to specialize you also want to remain flexible. A developer who has a solid understanding and the ability to work in all layers of an application from the user interface to the back end database code is a valuable team member. More importantly, become an expert on the application you work on. If you find a weak area within your team, take the opportunity to become the expert. Build relationships and talk with developers that work on other areas of the application to increase general knowledge of the overall product. The more you know, the more valuable you are to the company.

Verbal and Written Communication

Developers must be able to communicate software designs clearly and effectively with managers, business analyst and other team members. The ability to analyze business requirements and produce functional specification and design documentation is critical. Documentation should be written concisely covering all the business requirements. At times, it may be necessary to present your software design to a larger group in the form of a presentation. Presentations require strong verbal communication skills and the use of visual aids are beneficial. The ability to communicate your ideas clearly in front of a group of people is essential to career advancement.

White Board

I’ve written thousands of pages of documentation in the form of functional specifications and architectural design documents using Word, Visio and PowerPoint. While these documents are great for presentations and getting a project off the ground I’ve found that most people don’t actually read them (particularly the executives). This is when a quick, high-level overview of the design described pictorially on a white board is the most effective and efficient form of communication. As the old saying goes…”A picture is worth a thousand words”.

There is some skill required to be a good “white boarder”. I’ve worked with engineers who’s white board skills are horrible. While verbally communicating the design, they attempt to use the white board as a visual aid but nothing of substance is ever drawn. A series of dots, boxes, circles, lines and squigglies (which are supposed to represent text) are produced which result in something resembling a heaping, multi-colored plate of spaghetti (I myself am guilty of this). If you come back to the board the next day to review the drawing it is completely unreadable and has no meaning at all. Slow down and try to remain aware of what you are communicating. It is easy to become so involved in what you are verbalizing that the visual aspect of the white board suffers. I’ve always been impressed with people who can use the white board effectively. They tend to speak clearly and produce clean, easy to understand diagrams.

Time Management

Time management is an essential skill in the developers tool belt. A developer who has good time management skills can consistently deliver projects on time. This, in turn, will earn you the respect and confidence of project managers. Effective time management requires the ability to multi-task and delegate. Multi-tasking allows the developer to juggle multiple task at one time. Delegation enables multi-tasking by allowing the developer to distribute and offload tasks to alternate resources. Think of multi-tasking and delegation as concurrency in the work place, each employee/department is a worker thread, delegate a task and move on to the next.

Make the most of your time at work while at work. Do not bring work home unless you absolutely have to. If you find yourself bringing work home often then you are probably not utilizing your time at work efficiently. Create a todo list each day and methodically check off each task as they are completed. Microsoft Outlook has a task list feature which allows you to set reminders and completion dates. This is a great way to keep things moving. If you are working from a project plan, check it daily to make sure you are completing task on time in conjunction with the projected completion date. Keep interested parties up to date on your progress and completion of major milestones.

Social Interaction

At the end of the day this is just a job, a way to make money and pay the bills. Take some time to relax and associate with your co-workers in a social environment. Eating together is a great way to bond with people so try getting a group together for lunch or an after work drink and appetizers. Keep the work talk light and spend more time getting to know each other on a personal level. Socializing with your co-workers can help you in the work place. Allowing others to get to know you on a personal level may make them feel more comfortable and trusting. Developing a trusting relationship with your co-workers can increase communication, and efficiency in the office. Social interaction, along with demonstrated competence, is a great way to build up your referral network.

Share/Save

No related posts.