I have the following problem and I dont undesratnd how to use arralists to implement.

I have a customer class which I want to hold some primitive data types as name , id , address etc.

To implement this using arraylists I must declare it as below?

Arraylist Customer =new Arraylist[150];

One more question:

I want to use arralists to hold accounts for a specific customer.
How I am going to do this with arraylists also??

Syntax is since JRE 1.5

ArrayList<Customer> alCust = new ArrayList<Customer>();

In your Customer class your can have

class Customer {
   private ArrayList<Account> alAct;

   // constructor
   public Customer()  {
      alAct = new ArrayList<Account>();

Happy coding

import java.util.ArrayList;
public class list{

    public static void main(String[] args) {
    	ArrayList list = new ArrayList();

Refer to: http://download.oracle.com/javase/1.4.2/docs/api/java/util/ArrayList.html

Remeber, after using the .get(int index) to retrieve an item, you have to re-cast it to the type of object if whatever there is not a primitive data type (byte,short,int,string,double,long,float,boolean)

@toko What you wrote applies only to versions of Java before 1.5 (apart from the bit about primitives which was just wrong). It's very misleading to post that now.
@mbouster: You should ignore that, and stay with the 1.5 syntax as shown by pbl. There is normally no need to cast the object returned by get(int index) as the 1.5 syntax includes the type of object as part of the ArrayList declaration and creation.

@JamesCherrill, could you explain to my why what i said about primitives was wrong? All I said was that you do not have to cast primitives when you take them out of the ArrayList all other objects yo do have to. This is all before java 1.5 and seeing as he didn't indicate if he was using java older than 1.5 or newer you can't say its misleading...

You can't put a primitive in an ArrayList, only Objects, so you can't take them out either. Anyone on versions older than 1.5 has severe security problems, and needs to get current asap, not write obsolete code for an obsolete version.

ps - just checked, even version 1.5 was end-of-life April 8th 2008, and ceased to be supported November 3rd 2009, so we should restrict ourselves here to 1.6 unless explicitly required otherwize.

James - unfortunately, for Mac users who still use 10.5.8 (which is a large number) there are a lot of issues with 1.6, especially around applets. I've seen this now on two completely unrelated projects: if you're writing applets, you have to expect that Mac users will be unable to load unless you write to 1.5. Sorry, but if you don't like it you'll have to complain to apple.

I'm still on 10.5.8 myself, because it works fine aside from this issue and I can't be bothered to run out and update every time someone releases a charismatic carnivorous mega-feline, so I have this problem myself, and I saw it last year when I was writing on this project. More recently, the writer of tunepal ran into this as well, as you'll see in this discussion. (tunepal, by the way, is a pretty nifty piece of work - this guy wrote an app that recognizes traditional Irish tunes from audio input only, matching the audio input to abc notation in a couple of public databases.)

There are no updaters that I can find that fix the problem, and trying to fix it manually seems like it could cause a lot of problems - I'm only likely to go screwing with it if I have an update to 10.6 handy. It's sort of moot, anyway, since even if I fixed my machine, there's no reason to suppose that J. Random MacUser is going to do this, and every reason to suppose they won't.

So the upshot is, assume mac users can't run your applet if it's compiled to Java 1.6
- sorry.

Toko - what's wrong about your advice is that you should not be using a naked ArrayList.

Your code, repaired:

import java.util.ArrayList;
public class list{

    public static void main(String[] args) {
    	ArrayList<String> list = new ArrayList<String>();

As for the primitive issue, if you want an ArrayList of ints, they'll be stored as Integer in any case, so you'd want to declare it as an ArrayList<Integer>. I don't know off the top of my head if they'll be autoboxed, but I suppose it's likely.
This test code:

ArrayList<Integer> typedList = new ArrayList<Integer>();
ArrayList untypedList = new ArrayList();

System.out.println(typedList.get(0) instanceof Integer?"Yes, autoboxed":"No, not autoboxed");
System.out.println(untypedList.get(0) instanceof Integer?"Yes, autoboxed":"No, not autoboxed");

indicates that they are. So if you put primitives into an ArrayList, you'll be able to retrieve them and treat them as if nothing had happened, but you'll be taking a performance hit and it'll be completely hidden from you. Don't do this in a time-sensitive context - for example, don't use an ArrayList to store and retrieve a lot of ints or floats in a GUI context, use an array instead.

OK, fair point. I haven't been a mac user since MacOS 9.
Fortunately 1.5 is where all the big language enhancements came in, so sticking to 1.5-compatible code isn't really a hardship.
So I'd like to let all my previous statements about pre- and post- 1.5 ArrayLists stand, but I'll withdraw the references to 1.6.
Thanks for pointing that out.
ps: You can always set the compiler options to emit code for any earlier version of the runtime - so presumably you can enjoy 1.6 language on Mac if you like, as long as you generate .class files for 1.5 (or even 1.4)?

ps: You can always set the compiler options to emit code for any earlier version of the runtime - so presumably you can enjoy 1.6 language on Mac if you like, as long as you generate .class files for 1.5 (or even 1.4)?

That's true - we did something like that on the TBS applet, it worked okay as I recall. I haven't looked into the details of this, unfortunately - it's settled into a comfortable place on my "things I'd like to look into but probably won't" list. If you know anyone who's interested in figuring out what this is about, send them my way, and it'll probably be sorted out over a weekend, but if it's up to me I'll never get to it.