How could I print names randomly?

[Naghmeh Ghanooni]

I want to write a program which a user writes some names and then I want the program to print them randomly. what should I do? should I use Randome class? please help me!

[Marco Ehrentreich]

Hi Naghmeh,

you could simply put the names in a list like ArrayList and use the helper class java.util.Collections to shuffle this list with Collections.shuffle(). Then you don't need a random number generator and you don't have to worry that each name should only be displayed once.

Marco

[Naghmeh Ghanooni]

Thank you so much,

but I don't want to use ArrayList. Is any other solution for my problem? Because I should write this program without ArrayList.

Thanks,
Naghmeh

[chandra mohan]

then how you are going to store the names ? are you going to use arrays ?

[Naghmeh Ghanooni]

yes, I should store the names in arrays.

[Marco Ehrentreich]

You can still do it the way I explained. There's another helper class you can use to temporarily convert your array to an ArrayList: java.util.Arrays.asList()

[Campbell Ritchie]

An array and java.util.Random?

[Marco Ehrentreich]

Of course this is an option. I just thought Naghmeh probably wants every name only printed once and with an array and random numbers he would have to take care of this himself.

However if you first shuffle the list you can just print out the names one by one and you get each name only once.

If you don't worry about this it's of course easier to just use a RNG and simply use the array as-is.

Marco

[Campbell Ritchie]

Beware of Arrays#asList() even though I tend to spell it wrongly.

It returns an object of a class called ArrayList, but it is a different class from the java.util.ArrayList we know and love.

[Marco Ehrentreich]

Sounds interesting but unfortunately I don't know what you mean Could you please explain? Are we both talking about the method asList() of class java.util.Arrays? According to the JavaDoc this method returns a regular (fixed-size) java.util.List with the content of the array parameter.

Thanks!

Marco
[ May 11, 2008: Message edited by: Marco Ehrentreich ]

[Campbell Ritchie]

Yes, we are talking about the asList() method, which does return a fixed-size List object. Unfortunately that List object declares itself of a class called ArrayList. This has confused me, and several other Ranchers, when we have tried methods of java.util.ArrayList on it.

And java.util.ArrayList is the ArrayList class we all know and love so well.

[Marco Ehrentreich]

Actually I've never worried about this fact because the API documentation just indicates that asList() returns a List<T>. At least the API of JDK 1.6 does so. Where did you get that information? From the source code of the JDK?

Sorry for asking stupid questions but I can't see where the problem is The API doc (J2SE 1.6) says this method

Returns a fixed-size list backed by the specified array. (Changes to the returned list "write through" to the array.) This method acts as bridge between array-based and collection-based APIs, in combination with Collection.toArray(). The returned list is serializable and implements RandomAccess.

It doesn't even mention that it has to do something with any kind of ArrayList.

[Nicholas Jordan]

Yes, I want to know too. I just coded that hidden mistake - don't know it yet.

For Original Poster, I suggest HashSet, I have worked your problem many times and it will be worth the effort. If you do not use the class directly, study it for ideas from proven code.

[Joanne Neal]

If a method is defined to return an interface type, then you should only rely on any object that is returned from it implementing the methods of that interface. If you find out what actual object type is returned (by using a debugger or looking at the source code) and then make use of that knowledge in your code, then you are asking for trouble because different versions of the JRE may return a completely different object type. The only thing you can rely on is that that object will implement the stated interface.

[Marco Ehrentreich]

This is exactly what I thought, too. I don't see any problems if you stay with the interface return type.

And if you really need a specific implementation like ArrayList it would be no problem to create one with the List you have.

Marco

[Nicholas Jordan]

[JN]Then what if one needs very specific and predictable behaviour of an interface according to the specific job requirements? Should that become a return type of a class that one designs in adherence to design specifications, relying on the generality of library interfaces where such generality is provably correct? We may need the unpredictable behvaiour as stated in such things as HashSet. Isolating the design from critical review - such as dismissing Hashtable - when the behaviour was intentionally designed in at first coding is an issue for Team Lead or Project Manager. The decision is a consequence of installation / site needs and general design environment. If the return type from Arrays.asList() is a List, then that signature fulfills the generality issue. If the behaviour of the list may vary according to what was used to generate the list, it is my opinion that the coder needs a way to compartmentalize the behaviours and determine the behaviour of the code when it is coded, not in a failure incident.

I have been presented with that situation ( enforcing generality by fiat ) enough times that I will code around it internally, and would if called present an interface return type from the library - if and when that is asked for. Not before.
[ May 13, 2008: Message edited by: Nicholas Jordan ]

[Paul Sturrock]

Then what if one needs very specific and predictable behaviour of an interface according to the specific job requirements?

That is immaterial. Why should it matter? If your return type is an interface, all you can depend on is the defined functionality of that interface, not how it was implemented. Coding a solution that relies on the implementation of that interface is coding bugs into your software.

[Joanne Neal]

Of course you can code around the situation (I assume you are talking about using instanceof to check the actual type of the returned object), but this could lead to situations where your code will only run on certain versions of the JRE. Versions of the JRE that don't return the type of object you are expecting will not be able to run your code fully.

If you've written a method that has a Set return type, but you always call it from code that requires a HashSet, then that is bad design. If you have to have a HashSet returned from a method then define it to return a HashSet. If you define it to return a Set, then someone else may modify that method to return a different type of Set and so inadvertently break your code that calls the method.
[ May 13, 2008: Message edited by: Joanne Neal ]

[Nicholas Jordan]

Joanne + Paul - I work in a smaller shop where who uses the code and how may be tightly defined at project definition. Both of you have had to deal with the situation ( obviously ) in settings where who uses the code and how - must apriori - be versitile and reliable in the sense that conformance to established libs is something like paint on the wall or water coolers cool water.

Joanne's have to have is what I was looking for, as ( possibly ) is the original poster. Of course, we can advise OP to call collections.randomize() - and if that is the reliable paradigm, then we should advise so. This avenue would show OP why.

[Marco Ehrentreich]

I still think, there's no need to "code around" something or to count on a specific implementation of an interface.

The API definitely says Arrays.asList() returns a List (interface) which is guaranteed to be a List and not more. And if you really need additional features of an ArrayList for example you can easily built one by using ArrayList's overloaded constructor which takes a collection. No need to deal with problems of a specific version or JDK dependent implementation. No need be stuck with a simple List interface.

ArrayList al = new ArrayList(Arrays.asList(ar));

So where is the problem here? Or am I missing something?

Marco
[ May 13, 2008: Message edited by: Marco Ehrentreich ]

[Jim Yingst]

Ordinarily the implementing class shouldn't matter. For some reason though, Nagmeh doesn't want to use ArrayList, so I guess that's why Campbell mentioned the fact that Arrays.asList() returns an instance of a class called ArrayList, even though it's not a java.util.ArrayList. We don't know why Nagmeh doesn't want to use an ArrayList, so we don't know if this matters. Perhaps it's for a school assignment, and the instructor doesn't want them to use too many standard libraries to make their lives easier. (That's my guess.) Let's get Nagmeh to explain the requirements a little more, rather than saturating him/her in explanations of things that may well be outside of the intended problem space.

Nagmeh, if you print the names "randomly", are you supposed to make sure that each name occurs exactly once? Or can the names repeat? And are you allowed to use other classes and methods like Arrays.asList() or Collections.sort()?