And then there was the address book

[Antuan Sanders]

Good morning all. I've been learning java on my own for about 2 months. I've written a few basic software's such as a shooting games, conversion app's and a few other things. But nothing designed to hold data to be accessed latter. So as a practice run, i attempted to build a address book and failed miserably. So now I have to ask. Where should I go from here. Here is my code. I'm a quick study, I know ive done a lot wrong, but for the most part i'm focusing on function ally, as far as errors, not concerned. I'll obsess over that after I get the basic formula for storing data. Additionally, what I'm really having trouble understanding is, getting all the data into one contact and it being accessed later.

Note, Ordinarily I keep all my classes in separate files, but since this a practice run, ive built them all in one file.

import java.awt.BorderLayout;
import java.awt.GridBagConstraints;
import java.awt.GridBagLayout;
import java.awt.Insets;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.util.ArrayList;

import javax.swing.BorderFactory;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JOptionPane;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JTextArea;
import javax.swing.JTextField;
import javax.swing.SwingUtilities;


public class AddressBook{

	/**
	 * @param args
	 */
	public static void main(String[] args) {

		SwingUtilities.invokeLater(new Runnable(){
			public void run(){
				new GUI();
			}
		});
		
		
	}

}

class GUI extends JFrame implements ActionListener{
	
	/**
	 * 
	 */
	private static final long serialVersionUID = 1L;
	Person p;
	
	
	JButton back;
	JButton enter;
	JButton delete;
	JButton forward;
	
	JTextField fst; 
	JTextField lst;
	JTextField adrs;
	JTextField cty;
	JTextField st;
	JTextField zp;
	
	
	public GUI(){
		
		this.setTitle("Simpe Address Book beta");
		this.setSize(500, 500);
		this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		this.setVisible(true);
		this.setResizable(false);
		this.setLocationRelativeTo(null);
		
		JPanel panel = new JPanel();
		JPanel Text = new JPanel();
		JPanel Buttons = new JPanel();
		
		JLabel first = new JLabel("First");
		fst = new JTextField(15);
		JLabel last = new JLabel("Last");
		lst = new JTextField(15);
		JLabel address = new JLabel("Address");
		adrs = new JTextField(15);
		JLabel city = new JLabel("City");
		cty = new JTextField(15);
		JLabel state = new JLabel("State");
		st = new JTextField(15);
		JLabel zip = new JLabel("Zip");
		zp = new JTextField(15);
		JTextArea txt = new JTextArea();
		JScrollPane pane = new JScrollPane(txt);
		
		back = new JButton("<<");
		enter = new JButton("Enter");
		delete = new JButton("Delete");
		forward = new JButton(">>");
		
		Text.setLayout(new GridBagLayout());
		Text.setBorder(BorderFactory.createTitledBorder("Personal"));
		GridBagConstraints c = new GridBagConstraints();
		this.add(panel);
		panel.setLayout(new BorderLayout());
		panel.add(Text,BorderLayout.NORTH);
		
		c.fill = GridBagConstraints.BOTH;
		c.insets = new Insets(3,3,3,3);
		
		c.gridy = 2;
		c.gridx = 1;
		Text.add(first,c);
		c.gridy = 2;
		c.gridx = 2;
		Text.add(fst,c);
		
		c.gridy = 3;
		c.gridx = 1;
		Text.add(last,c);
		c.gridy = 3;
		c.gridx = 2;
		Text.add(lst,c);
		
		c.gridy = 4;
		c.gridx = 1;
		Text.add(address,c);
		c.gridy = 4;
		c.gridx = 2;
		Text.add(adrs,c);
		
		c.gridy = 5;
		c.gridx = 1;
		Text.add(city,c);
		c.gridy = 5;
		c.gridx = 2;
		Text.add(cty,c);
		
		c.gridy = 6;
		c.gridx = 1;
		Text.add(zip,c);
		c.gridy = 6;
		c.gridx = 2;
		Text.add(zp,c);
		
		c.gridy = 7;
		c.gridx = 1;
		Text.add(state,c);
		c.gridy = 7;
		c.gridx = 2;
		Text.add(st,c);
		
		c.gridy = 8;
		c.gridx = 2;
		Text.add(pane,c);
		
		panel.add(Buttons,BorderLayout.SOUTH);
		Buttons.add(back);      
		Buttons.add(enter);
		Buttons.add(delete);
		Buttons.add(forward);
		this.pack();
		
		back.addActionListener(this);
		enter.addActionListener(this);
		delete.addActionListener(this);
		forward.addActionListener(this);
		
	}
		public void addUser(){
			
	
			
			String First = fst.getText(); 
			String Last = lst.getText();
			String Address = adrs.getText() ;
			String City = cty.getText();
			String State = st.getText();
			String Zip = zp.getText();
			
			p = new Person(First,Last,Address,City,State,Zip);

		}
		
		public void clear(){
			
			fst.setText(null);
			lst.setText(null);
			adrs.setText(null);
			cty.setText(null);
			st.setText(null);
			zp.setText(null);
			
		}

	public void actionPerformed(ActionEvent arg0) {
		if (arg0.getSource() == back){
			JOptionPane.showMessageDialog(back, "Not Coded");
		}
		else if (arg0.getSource() == enter){
			addUser();
			clear();
		}
		else if (arg0.getSource() == delete){
			JOptionPane.showMessageDialog(delete, "Not Coded");
		}
		else if (arg0.getSource() == forward){
			JOptionPane.showMessageDialog(forward, "Not Coded");
		}
		
	}
	
}



class Person{
	
	String First;
	String Last;
	String Address;
	String City;
	String State;
	String Zip;
	

	ArrayList<String> people = new ArrayList<String>();
	
	
	public Person(){
		
		First = "";
		Last = "";
		Address = "";
		City = "";
		State = "";
		Zip = "";
		
		
	}
	
	
	public Person(String First,String Last,String Address, String City,String State,String Zip ){
		
		
		
		this.First = First;
		this.Last = Last;
		this.Address = Address;
		this.City = City;
		this.State = State;
		this.Zip = Zip;
		
		people.add(First);
		people.add(Last);
		people.add(Address);
		people.add(City);
		people.add(State);
		people.add(Zip);
		
	}


	public String getFirst(){
		return First;
	}
	
	public String getLast(){
		return Last;
	}
	
	public String getAddress(){
		return Address;
	}
	
	public String getCity(){
		return City;
	}
	
	public String getState(){
		return State;
	}
	
	public String getZip(){
		return Zip;
	}
	
}

[Michael Dunn]

by the look of it, all you've done is create the 'add' function of your address book.

an address book gui could be just a JTable with your current field identifiers as the column names,
or a JTabbedPane with 26 tabs (A to Z) etc. i.e. something to display everyone's info.

all you do with your add function is to save the info to a database, or, for simplicity, to a text file,
with a delimeter between the fields (~ or | etc - some character not likely to be part of name/address).

when the program starts it would read the text file, line by line and splitting at the delimeter, then add
that data to the address book gui

[Stevens Miller]

I think Michael's got you on the right track, Antuan. Let me add the suggestion that, if you are new to Java and don't yet know how to read and write data to persistent storage (you know, "to the disk"), then you should set all that Java in your posting aside for an hour or two and just fiddle with basic I/O. For example, if you had this text stored in flatfile.txt:

one
two, three
four, five
six, seven, eight

nine
ten

You could read it with this method:

    public static void main(String[] args)
    {
        FileInputStream fis = null;

        File f = new File("C:/users/smiller/flatfile.txt");
        
        try
        {
            fis = new FileInputStream(f);
        }
        catch (FileNotFoundException ex)
        {
            System.err.println("Couldn't open the file.");
        }

        Scanner scan = new Scanner(fis);
        scan.useDelimiter("[,$]");
        
        while (scan.hasNext())
            System.out.println(scan.next().trim());
        
        try
        {
            fis.close();
        }
        catch (IOException ex)
        {
            System.err.println("Couldn't close the file.");
        }      
    }

And get this output:

one
two
three
four
five
six
seven
eight

nine
ten

Now, that's got some stuff in it that you really do need to know, but I almost feel guilty posting it, because you don't want to do your I/O that way. There is nothing inherently wrong with what I've listed here, but it omits some important features that any real program would include. (See, for example, the BufferedInputStream class.) In fact, it really does its I/O in a way that very few real programs would use at all. For your application, a database is almost certainly what you want to use. Until you're ready for that, you might want to look at some of the other ways the Java API allows you to use persistent storage, as the choices are many, and you wouldn't want to find out later you had reinvented any wheels (trust me on this: I know what that's like). For example, have a look at the XMLEncoder and Properties objects.

As you look into persistence, you're also going to find out about the Serializable interface. I will trust more experienced heads to advise you on that one, but the short version is this: you don't want to use it for data-storage (because Java makes no promises about whether or not it will work from one version to the next). I mention it because it is probably impossible to do any reading about persistent storage without running into Serializable, so be warned in advance.

Hope that helps.

[Antuan Sanders]

Michael Dunn wrote:by the look of it, all you've done is create the 'add' function of your address book.

an address book gui could be just a JTable with your current field identifiers as the column names,
or a JTabbedPane with 26 tabs (A to Z) etc. i.e. something to display everyone's info.

all you do with your add function is to save the info to a database, or, for simplicity, to a text file,
with a delimeter between the fields (~ or | etc - some character not likely to be part of name/address).

when the program starts it would read the text file, line by line and splitting at the delimeter, then add
that data to the address book gui

Correct, I started over and simply built the GUI for the app. I Wanted to get some advice before I repeated the same mistake.

[Antuan Sanders]

Stevens Miller wrote:I think Michael's got you on the right track, Antuan. Let me add the suggestion that, if you are new to Java and don't yet know how to read and write data to persistent storage (you know, "to the disk"), then you should set all that Java in your posting aside for an hour or two and just fiddle with basic I/O. For example, if you had this text stored in flatfile.txt:

one
two, three
four, five
six, seven, eight

nine
ten

You could read it with this method:

    public static void main(String[] args)
    {
        FileInputStream fis = null;

        File f = new File("C:/users/smiller/flatfile.txt");
        
        try
        {
            fis = new FileInputStream(f);
        }
        catch (FileNotFoundException ex)
        {
            System.err.println("Couldn't open the file.");
        }

        Scanner scan = new Scanner(fis);
        scan.useDelimiter("[,$]");
        
        while (scan.hasNext())
            System.out.println(scan.next().trim());
        
        try
        {
            fis.close();
        }
        catch (IOException ex)
        {
            System.err.println("Couldn't close the file.");
        }      
    }

And get this output:

one
two
three
four
five
six
seven
eight

nine
ten

Now, that's got some stuff in it that you really do need to know, but I almost feel guilty posting it, because you don't want to do your I/O that way. There is nothing inherently wrong with what I've listed here, but it omits some important features that any real program would include. (See, for example, the BufferedInputStream class.) In fact, it really does its I/O in a way that very few real programs would use at all. For your application, a database is almost certainly what you want to use. Until you're ready for that, you might want to look at some of the other ways the Java API allows you to use persistent storage, as the choices are many, and you wouldn't want to find out later you had reinvented any wheels (trust me on this: I know what that's like). For example, have a look at the XMLEncoder and Properties objects.

As you look into persistence, you're also going to find out about the Serializable interface. I will trust more experienced heads to advise you on that one, but the short version is this: you don't want to use it for data-storage (because Java makes no promises about whether or not it will work from one version to the next). I mention it because it is probably impossible to do any reading about persistent storage without running into Serializable, so be warned in advance.

Hope that helps.

Yes! this is exactly what i was asking, I wont use that code, but it all the information is just what i need to get me going, first thing Im going to do I\O to file get my feet wet. Than moving to table than eventually to DB.

[Winston Gutkowski]

Antuan Sanders wrote:Correct, I started over and simply built the GUI for the app. I Wanted to get some advice before I repeated the same mistake.

I hate to say, but I think the best advice I can give you is: resist the temptation to code.

You don't solve problems in Java by coding, you solve them by thinking.

Your problem here is an Address BOOK; and that suggests to me that you need to concern yourself with how you store (or persist) those addresses.

For example, it's interesting that you've defined a Person class for your app, because people are one of the most difficult things to define and store properly, which is why most computer systems end up defining a 'Customer ID'. There are all sorts of attributes that will help you narrow a search, but apart from some (and mostly non-universal) government IDs, almost nothing that uniquely identifies an individual Person.

And addresses themselves present a lot of interesting problems. Obviously, you can just store it as a piece of text if you want; but there are several components of an address that may be of interest if you really want to analyse the problem in depth. I offer just a few for you to think about:
Street
Town
Zip/Postal Code
Country
Building number (or range) or name
Apartment

A very old friend of mine, for example, lives in a house simply called "Shambles" on a country lane. It doesn't have a number (or if it does, he doesn't use it).

Don't let me put you off, Addresses are interesting; but you must think about what it is they do before you can write decent software to emulate it.

HIH

Winston

[Stevens Miller]

Winston Gutkowski wrote:

Antuan Sanders wrote:Correct, I started over and simply built the GUI for the app. I Wanted to get some advice before I repeated the same mistake.

I hate to say, but I think the best advice I can give you is: resist the temptation to code.

You don't solve problems in Java by coding, you solve them by thinking.

I think (tee-hee!) that Winston has made a very good point. Java is more than just the language. Until you know some of the API, you don't know Java. It's kind of like the ubiquitous "printf()" routine in C. There's no "printf()" in the language specification, but you can't do much if you don't know how to use printf() (and the rest of the standard library). (Parenthetically, I will mention that, back about 1983, I had to write C programs for a machine that did not have the standard library, so I had to write my own printf() routine. That sucked, so take heart that, as big and daunting as the Java API is, life without it would be a dreary thing indeed.)

Winston's "coding vs. thinking" dichotomy reminds me also of my days as a student of physics. In physics, there is a battle for supremacy between the experimenters (who actually try things in laboratories to see what will happen) and theoreticians (who scribble things on blackboards to see what will happen). Unlike physics, where lab gear costs money, you can experiment all you want to in Java. But, there is a difference between a genuine experiment and each of the following: guessing, procrastinating, misusing, and screwing around. I'd take Winston's advice as far as shoving my nose into a good book on Java, and keeping it there until I had one of those "Aha!" moments that makes you think you know how to do something that might actually be useful. Then I'd run to a keyboard, and experiment with what I thought I'd just learned. After I felt like I had some solid understanding of my new skill, I'd go back to that book and learn another one.

FWIW, my favorite is the two-volume set, "Core Java, 8th ed.," though I got some good guidance from "Java: The Complete Reference, 7th ed.," and I often glance at "Murach's Java SE 6, 1st ed." Now that's $220(US) of computer books, I know, so if you can only afford one, that one should be Volume I of "Core Java." (The 9th edition is scheduled for publication in late November of this year. Don't wait. Get the one that's available now and move on.)

Hang in there. It'll come to you.

[Antuan Sanders]

I looked over all your responses and have to agree. I have two books that i've been reading, "Learning java" and "Java Examples." Both O'Reilly(Not sure about the second one). I'll finish them first and then come back! Thanks for the time, I can appreciate honest advice. Regardless, I'm on a mission to become a coder, eventually. Until then I will remain jealous of you all that are good at it ;)

[Stevens Miller]

I find computer books are kind of like the Sunday brunch buffets the local restaurants serve: you'll often pay the full price to get just one thing you want. I have boxloads of books that were mostly purchased because of just one problem they solved for me. Fortunately, Google has helped me avoid bankruptcy over that, but even Googling a specific problem can be a skill all its own.

If your budget can stand it, don't be afraid to buy a couple of books. What's easy to understand in one may be hard in another, and vice versa.

Best of luck.

[Winston Gutkowski]

Stevens Miller wrote:Winston's "coding vs. thinking" dichotomy reminds me also of my days as a student of physics. In physics, there is a battle for supremacy between the experimenters (who actually try things in laboratories to see what will happen) and theoreticians (who scribble things on blackboards to see what will happen). Unlike physics, where lab gear costs money, you can experiment all you want to in Java. But, there is a difference between a genuine experiment and each of the following: guessing, procrastinating, misusing, and screwing around. I'd take Winston's advice as far as shoving my nose into a good book on Java, and keeping it there until I had one of those "Aha!" moments that makes you think you know how to do something that might actually be useful. Then I'd run to a keyboard, and experiment with what I thought I'd just learned. After I felt like I had some solid understanding of my new skill, I'd go back to that book and learn another one.

Hate to say, but I can't agree with that analysis. Programming is much more like engineering: you aren't breaking new ground, and if you do, it'll be in the design phase, NOT the coding. Almost all programming is extraction → manipulation → submission (IPO); in fact if you can find one that isn't, let me know.

But the major difference is that we are human. We don't think like computers - and we weren't designed to - so trying to think of a problem in terms of code we're writing is like asking Beethoven to write his 9th Symphony (well OK, maybe his 2nd) in pen and ink while he's tinkering on the ivories.

There's an old adage: Think, then act.
Well, for programmers it should be: Think, then code.

Winston

[Paul Clapham]

Well, yeah, generally you aren't breaking new ground, in the sense that you aren't doing something which has never been done before. However it does happen that you're breaking new ground in the sense that you are doing something which YOU have never done before.

Given all of that, when you find yourself breaking ground which is new to you, it's generally a good idea to find out how other people have already done it. So here Winston's exhortation to "Step away from the keyboard" comes into play. This is a bad time to start coding. Instead you should be researching. What you're trying to do may seem weird and difficult, but chances are that thousands of people have already done it. Maybe even hundreds of thousands of people. So yeah, get the book. Google for the tutorial.

I find it strange -- people don't seem to realize that they are ordinary. The problems that they have are the same problems that millions of other people have already had. So you see people asking questions like "Has anybody ever seen this phenomenon before?" when the answer is "Yes, almost every Java programmer (and there are millions of them) has already seen that."

[Stevens Miller]

Paul Clapham wrote:Well, yeah, generally you aren't breaking new ground, in the sense that you aren't doing something which has never been done before. However it does happen that you're breaking new ground in the sense that you are doing something which YOU have never done before.

That's what I meant, Paul. I see it your way, Winston, after one has mastered the basics of one's craft. Design first, write second. But when one is learning one's craft, and that craft is programming, I believe one should jump from book to keyboard and back again rather frequently. I learned my craft a long, long time ago. Maybe methods are different now (though the recent spate of beginners coping with how a computer handles numbers like "2.01" tells me they are not, alas), but my thinking for decades has been that learning to program is like storming a castle: no matter how you approach it, you are going to have to cross a moat with some alligators in it. Sometimes they bite you, sometimes they don't, but there is no avoiding the alligators. (Yes, I know moats didn't have alligators. No crocodiles, either, but it's a great metaphor.)

You know, that 2.01 thing kind of worries me. I had a physics prof who despised computers. He made us all write a Fortran (actually "FORTRAN," in the version we used) program to compute a numerical approximation to the velocity acquired by a rock dropped from the orbit of the moon onto the Earth. At big intervals, the approximation was awful. As the intervals got smaller, the approximation improved. But, past a certain small size, as the intervals got very tiny, round-off error accumulated to the point where the approximations were worse than ever. His goal, of course, was to leave us all thinking that the computer is a useless tool for a physicist (he was a pure theoretical type, btw). I find it disturbing to think instructors of programming are deliberately forcing their new students into problems designed to shock them with how "badly" computers handle real numbers, perhaps for similar reasons. When I learned all this guff, back in 1974, it was out of a book that painstakingly taught me basic floating-point format (normalization, bias, all of it). So, when I finally had to write programs that coped with real numbers, I had a good background in the fact that computers are discrete beasts, which meant that I wasn't shocked at all when x = 1/3, y = x + x + x, didn't mean y = 3.

Which, I suppose, supports the notion that one learns to program by, at least in part, reading about it first.

[Winston Gutkowski]

Stevens Miller wrote:Which, I suppose, supports the notion that one learns to program by, at least in part, reading about it first.

Hey, don't get me wrong. A programmer should program; and a novice programmer should program twice as much. The difficulty with most novices is actually stopping them (or at least slowing them down) from doing what they think is programming, which is coding.

There's a wonderful cartoon out there in Internet-land of the "gorilla programmer", and it's basically "problem....keyboard.....Uuurgh"; and I hate to say but there are plenty of newbies out there who think that a problem can be solved simply by writing code.

And, as an 'answerer' on this forum, I find myself often dealing with a neophyte of what I term the 'Existentialist School'. They've been given a problem, they've sat down at the keyboard and they've started to code... the best may have even written a working program, but usually they've got about half way through and the question is (reading between the lines) 'what do I do now?'
And my advice is always the same:
1. Stop coding.
2. Turn your computer OFF.
3. Get out lots of paper and a pencil and a sharpener, and THINK through the problem.
4. When (and only when) you understand the problem, turn the computer back on.

And you'd be amazed how many (even ones who've actually written a working program) come back later (not always enthusiastically, it has to be said) with 'OK, re-wrote the program, and it seems to be working'.
Play is fine, but when you've actually got to accomplish a task, sometimes you have to put the toys away and knuckle down.

Winston

[Edit] I should add that the main problem for an old fart like me is actually forcing me to code. Awful. Uurgh. Hey, I like being in development paralysis, OK???

[Stevens Miller]

I think we're converging on the same conclusion, but from different directions. One of the problems I see modern programmers coping with when they are just learning how to program is that tons and tons and tons of what they have to learn isn't what I consider "programming." First, the language constructs they have to master are far more arcane than when I was a boy. Second, no one limits themselves to the language constructs anymore. Anything worth doing requires extensive knowledge of libraries (the "API" in Java-speak).

When I was a callow youth of 14, I taught myself how to program out of a book called "Basic BASIC." (That link is to the second edition; I used the previous version, a tome so dead to the world I can't even find you a picture of it on the 'net.) In those days, if you wanted to sort an array, you sat down with your pencil and a pad, drew some boxes, and tried to devise an algorithm (a word much too rarely seen these days) to do it. Today, no one would waste their vanishing time with such nerdy ruminations. Today, you just make sure your object implements the Comparable interface, and use the appropriate static method. If anyone even caught you coding a sorting algorithm today, they'd likely pull you away from the keyboard by your ear, give you a lecture about goofing off, and leave you to the ministrations of people like us.

But that's a shame, in a way, because it means you can't do much of anything if all you learn is "how to program." Good old BASIC only had about a dozen or so keywords, no libraries, no APIs, and no place to go to download examples. You either wrote what you needed from scratch, or you didn't. Under conditions like that, it was natural to spend a lot of time away from the keyboard (well, away from the ASR-33, in my case). You had to, because, until you had solved your underlying problem (how to sort an array; how to deal a deck of cards at random; how to represent a complex number; whatever) you had nothing to code. Today, it feels like the "solution" to every problem is the code itself. No one is expected to devise "algorithms" anymore; they are expected to know which API call does what they need. In that context, it might seem natural to be spending all of one's time at the keyboard. After all, with an object/method/library/API for everything, what else is there to do but write the necessary code? (One even sees the declining regard for writing programs as a substantive undertaking in the propensity database administrators sometimes have for calling the work of programmers, "scripts," as though all we do is give the computer its lines, and it does the rest.)

Yet, with the solution to the need for devising algorithms taking the form that it has, as libraries and so on, the need for away-from-the-keyboard time is as great as it ever was. That time just has to be devoted to something different than it was, 40 years ago. That's because saying, "you just make sure your object implements the Comparable interface, and use the appropriate static method," is a lot easier than knowing what the Heck that means. What's an interface? How do you implement it? What's a static method? Which one is appropriate? How do I know? The answers to those questions are, indeed, not to be found by typing. They are to be found by reading.

But now I return to my moat metaphor: You want to sort? You need Comparable. What's Comparable? An interface. What's an interface? It's a definition. How is it defined? And so on, and so on, and so on... before one can make use of all those pre-cooked solutions, one needs to know the relevant basics. If one has never used an interface, I wouldn't start one with "Comparable." I'd start one with something almost impossible to misunderstand, so the focus would be on understanding interfaces, rather than any particular interface itself. To do that, I'd assign one reading, but then I'd have one do some coding. After that, I'd have one read more, this time about using existing interfaces. Then I'd have one code for an existing interface. After that, I'd talk about how to find interfaces that might assist in solving problems one is likely to have (and I'd do that with more reading). And so on, and so on, book to keyboard, keyboard to book, over and over.

Alas, I do worry that we are creating, even with the best of our teaching methods and our supportive communities (like this one) a generation of programmers who will never devise an algorithm, always expecting instead that some API call somewhere must exist to do whatever it is they are doing. Someone must write those API calls, of course, but I don't think we're doing much to raise the next generation of those programmers with the coding models most newcomers are learning today.

I seem to have digressed, somewhat. I am becoming an old fart, however, and they do that.

[Antuan Sanders]

Just to follow up on this thread, I read my book and completed this program with ease. I stored the data in a hash map that eventually went into a SQL database. I chose to display the data in a JTable. I also used the delete row button that was designed by someone on this forum . Forgive me but his name escapes me at the moment. This all was very simple. Thank you all for the time and advice.

God Bless.