logo

Java: Custom Address Class to Check for Duplicates

My adventures as a "proper" programmer continue apace. Yesterday I created a custom class in Java that implements the Comparable interface and now feel quite smug about it. Probably undeservedly so.

I was writing a Domino-based reporting Agent in Java which need to loop a set of invoice documents for a given user and report back a sorted list of each unique billing addresses they'd supplied over the years, so that a data audit could take place.

Here's the use case code for the class:

ArrayList addresses = new ArrayList();

Document d = dc.getFirstDocument();
    
while (null!=d){
    BillingAddress address = new BillingAddress();
                        
    address.setAddress("AddressLine1");
    address.setTown(d.getItemValueString("AddressTown"));
    address.setCounty(d.getItemValueString("AddressCounty"));
    address.setPostCode(d.getItemValueString("AddressPostCode"));
              
    //Make sure the address is isn't in the array.          
    if(!addresses.contains(address)){
        addresses.add(address);
    }
                        
    d = dc.getNextDocument(d);
}

//Sort our addresses before output
Collections.sort(addresses);

//For each address convert to HTML string.
for (int i=0; i<addresses.size(); i++){
    _html+=("<p>"+((BillingAddress)addresses.get(i)).toString().replace("\\n", "<br/>")+"</p>");
}

As you can see I'm able to check whether a BillingAddress is already in the ArrayList and I'm able to sort them. The former is due to the existence of the equals() method in the class and the latter because of the compareTo() method.

Here's the class itself:

public class BillingAddress implements Comparable {

    private String _address;
    private String _town;
    private String _county;
    private String _postCode;
    
    
    public int compareTo(Object address) throws ClassCastException {
        if (!(address instanceof BillingAddress))
              throw new ClassCastException("A BillingAddress object expected.");
            
        return (_address.compareTo(
                ((BillingAddress)address).getAddress()
            ));
    }
    
    public boolean equals(BillingAddress address){
        return (
            address!=null &&
            address.getAddress().equalsIgnoreCase(_address) &&
            address.getPostCode().equalsIgnoreCase(_postCode)
        );
    }

    public void setAddress(String address){
        _address = address;
    }
    
    public String getAddress(){
        return _address;
    }
    
    public void setTown(String town){
        _town = town;
    }
    
    public String getTown(){
        return _town;
    }
    
    public void setCounty(String county){
        _county = county;
    }
    
    public String getCounty(){
        return _county;
    }
        
    public void setPostCode(String postCode){
        _postCode = postCode;
    }
        
    public String getPostCode(){
        return _postCode;
    }
    
    public String toString(){
        String out = "<p>";
        if (!_address.equals("")){
            out+=_address+"\n";
        }
        if (!_town.equals("")){
            out+=_town+"\n";
        }
        if (!_county.equals("")){
            out+=_county+"\n";
        }
        if (!_postCode.equals("")){
            out+=_postCode;
        }
        return out;
    }

}

Inside the equals() method you can see I've deemed any address where the first line and the post code (ZIP) match to be the same. Whether this holds true or not I don't know yet. But it's easy to change this logic. As is the case for changing how the compareTo() method sorts your addresses. You could choose to sort by Town/City or Post Code rather than by the first line. It's all up to you.

As you can probably tell I'm writing the code in Java 1.3 (ouch!) because the client is still on Domino 6.5.5 (double ouch!!). If you were using a later version of Java you could make the above code a lot simpler, but the theory still holds true and the principles are the same.

Comments

    • avatar
    • ChrisC
    • Wed 14 Dec 2011 04:16 AM

    Very nice Jake...sure we can't tempt you over to the XPages world yet?

    1. It's not really about being tempted (which I'm not really) it's all about work (money!). When a customer asks me to write them a web app and specifies it must be done in Xpages, then I'll be tempted (forced!) to. The chances of it happening are fairly remote though.

      Hide the rest of this thread

        • avatar
        • Michael
        • Wed 14 Dec 2011 04:47 AM

        You can also suggest them to...a customer on 6.5.5 is likely to be "attracted" by more modern solutions (and thus likely to not be a customers of yours, at least there are chances too if they chose a technolgy you don't feel comfortable with).

        Whereas if you show he can perform a simple upgrade of it's infrastructure to have a modern application framework, you are much more likely to keep your customer...

        1. The modern solution this customer has been attracted to (like all my other customers) isn't from the Lotus stable.

          I've never seen it as my job to advise customers on choice of platform. I'm a developer. I just do what is asked of me. In doing my job I try remain impartial in my views on any one platform. This, I think, has attracted customers to me over the years as they know I'm not a colour-blind yellowhead.

            • avatar
            • Michael
            • Wed 14 Dec 2011 06:39 AM

            Whatever the solution is, I doubt a migration to another horse will be cheaper than upgrading the current one (be it Lotus or not), provided that the current one provides features that are on par with what other tools offer.

            And I don't see any problem - in the contrary - to at least inform the customer of a possible upgrade and a possible cost saving solution.

        • avatar
        • Jeremy Hodge
        • Wed 14 Dec 2011 06:19 AM

        Isn't this a sort of self-fulfilling proclamation? Why would a customer come to you do work in XPages when you declare you don't know it, don't really want to, and you have to be forced to learn it.

        I understand strategically choosing where you want to concentrate your resources and efforts to maximize your earning potential based on the business market as you see it, that makes a lot of sense. But the general sentiment of your statements really do your personal brand a lot of harm. Taking a proactive approach to capitalizing on new opportunities to learn a new technology could actually help you rejuvenate old business, sell new work, and open up more avenues of sales, work, and ultimately profits.

        1. I know, I know. As I wrote that last comment I was aware of what I was saying. I meant to mention that but forgot.

          I've long since given up on any notion of having a future as a Domino developer in any other capacity than that of legacy support or "migration specialist".

          Perhaps I'm wrong but I really don't see any benefit in devoting what little spare time I do have to learning XPages and proving to the ever-shrinking yellowverse that I can use them.

          I've long wanted out of the Domino world. The day has yet to come when Domino work *completely* dries up for me, but I'm aware that it will come one day and that - when it does - it will be a painful time.

            • avatar
            • ChrisC
            • Wed 14 Dec 2011 08:29 AM

            Can I just say that (you probably know this so apologies in advance) XPages == JSF.

            I see plenty work there.

            XPages / Eclipse == Java - work there too...

            Again - I am sure you know all of that.

            I decided it was time to invest in my java skills - don't regret it one bit.

            XPages was a good place to start.

            Difference I suppose is that my customers were interested in what I had to say about the platform...it does involve selling to customers that want to "modernise" and are willing to listen to the XPages story...if yours are not then of course it makes little sense to pursue it.

            Everyone is different - customers and fee earning (cash) is king. I know only too well....

  1. As you do not recycle you should check memory consumption at the server if you iterate over a large collection.

    Most parts of the code would fit well into an XPages environment too but a 6.5.5 customer would not benefit from an XPage solution anyway.

    In my dreams IBM enhanced the "classic" application approach so that old ugly applications automatically become nice looking modern GUI applications that work on both the web and a client simple by upgrading the server and starting the design task on a database level.

    That would mean enormous potential for customers that already said good-bye to Notes and Domino a long time ago but still keep it running. There are thousands of former customers falling into this category.

    1. Spot on. XPages is a solution in search of a problem. Most Domino application environments have been left on minimal life support for very good reasons. Since an XPages migration is effectively a total rewrite, it has little or no advantage over migrating to any other platform - especially one that might be cheaper, more robust, more open, better documented or more widely adopted. This is why XPages deployments are few and far between and developer interest and market demand for those skills is near non-existent.

      Show the rest of this thread

      • avatar
      • axel
      • Wed 14 Dec 2011 11:19 AM

      You should better use:

      [code]

      Document oldOne = d;

      d = dc.getNextDocument(d);

      oldOne.recycle();

      }

      [/code]

      Way much saver, when you iterate over a larger collection of Domino Objects.

  2. If you use a TreeSet instead of an ArrayList, you don't have to check for duplicates and you don't have to sort the collection.

    1. Are TreeSets in Java 1.3?

      How do they know if an object based on a custom class is already in them?

      How do they manage custom sorting?

      Show the rest of this thread

  3. Thanks Jake, I always like to see other peoples code samples to see how they use a language feature.

    Two questions.

    Does/can the post office provide address verification as a service or Database and API?

    Also, does this customer have less than a thousand seats?

    If so, sounds like a really good candidate to switch to express server licensing and upgrade in an incremental manner.

    1. Hi Wayne,

      1. I'd be surprised if it didn't.

      2. No.

      Jake

    2. Is express server licensing even available any more? Last I heard, big blue had gone to a 'one size fits all (we care about)' model... no more foundations, no more express.... maybe I totally misunderstood (hopefully so - both express and foundations were great ideas for small biz).

      Show the rest of this thread

  4. You could also use Session.evaluate() with @sort and @unique

    1. Now, come on Bob, that's hardly going to make me a better developer and prepare for a world without Domino is it?! ;-)

Your Comments

Name:
E-mail:
(optional)
Website:
(optional)
Comment:


About This Page

Written by Jake Howlett on Wed 14 Dec 2011

Share This Page

# ( ) '

Comments

The most recent comments added:

Skip to the comments or add your own.

You can subscribe to an individual RSS feed of comments on this entry.

Let's Get Social


About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »

More Content