Inserting In a List

[Eric Sosman]

[...]
Its also not clear to me whether the OP is expecting some form of
sorted list of filenames. If he is expecting that, it would be best to
use a TreeMap<String> rather than an ArrayList<String> to store the
filenames.

Is there a reason to prefer TreeMap (or other SortedMap) over
accumulate-disordered-and-sort-afterward?

I think so, yes, because none of File's list() and listFiles() methods
guarantee the order of the returned files. By using TreeMap or equivalent
the OP gets the sort for free, should it be required.

"For free" seems to have swept a few coins under the rug.
The sort is by no means "free," since computational effort is
expended in producing it. My question is why one should prefer
keep-it-always-sorted-even-during-the-accumulation-phase over
just-let-the-chips-fall-and-sort-them-later. It seems to me the
latter is likely to be cheaper in both time and memory, and that
the one extra line of code ("Collections.sort(list)") is not an
overwhelming burden on the programmer.

I use it a lot, both for that and because accessing stored objects by key
from a TreeMap is almost certainly faster than scanning an ArrayMap
unless it contains very few objects indeed.

Sorry: "ArrayMap"?

 

[Joshua Cranmer ðŸ§]

06 PM, Martin Gregorie wrote:
[...]
Its also not clear to me whether the OP is expecting some form of
sorted list of filenames. If he is expecting that, it would be best to
use a TreeMap<String> rather than an ArrayList<String> to store the
filenames.
Is there a reason to prefer TreeMap (or other SortedMap) over
accumulate-disordered-and-sort-afterward?
I think so, yes, because none of File's list() and listFiles() methods
guarantee the order of the returned files. By using TreeMap or
equivalent
the OP gets the sort for free, should it be required.

For free ? The cost is just distributed amongst the insert calls, and is
likely considerably higher than with an unsorted list that has a single
sort call once it is filled.

It is not that obvious to me that:

n O(1) + 1 O(nlogn) is that much faster than n log(n)

The received wisdom I've heard would say that ArrayList is superior here
to a TreeMap. Recall that a TreeMap is a self-balancing red-black tree.
This means that every access of a node requires chasing at most O(lg n)
pointers, and that adding elements could require as many as O(lg n)
rebalancing operations. Compare this to ArrayList and the corresponding
sort technique, which is a merge sort. The array options chase
effectively no pointers (internal to the data structure), so the
accesses are predictable to the cache lines. As a result, you would
expect that the ArrayList+sort method is slightly faster in the general
case than the TreeMap implementation.

Another factor to keep in mind is algorithmic performance if the data
isn't actually uniformly random. If the input data is already sorted,
the sort function will likely achieve its best possible performance,
while the tree map will likely achieve its worst possible performance.
Since sorted data tends to be more realistic in practice than true
random, sorted lists actually have some things going for them.

 

[Arne Vajhøj]

On Tue, 2 Apr 2013 22:52:20 +0000 (UTC), Martin Gregorie wrote:

06 PM, Martin Gregorie wrote:
[...]
Its also not clear to me whether the OP is expecting some form of
sorted list of filenames. If he is expecting that, it would be
best to
use a TreeMap<String> rather than an ArrayList<String> to store the
filenames.
Is there a reason to prefer TreeMap (or other SortedMap) over
accumulate-disordered-and-sort-afterward?
I think so, yes, because none of File's list() and listFiles() methods
guarantee the order of the returned files. By using TreeMap or
equivalent
the OP gets the sort for free, should it be required.

For free ? The cost is just distributed amongst the insert calls, and is
likely considerably higher than with an unsorted list that has a single
sort call once it is filled.

It is not that obvious to me that:

n O(1) + 1 O(nlogn) is that much faster than n log(n)

By design, O() obscures all the coefficients. If you were
to say that n*log(n) and 9999999999999999999999999999*n*log(n)
are both O(n*log(n)) you would be right -- but if you were to
claim the former was not "that much faster" than the latter you
would be wrong by a factor of 9999999999999999999999999999.

Yes.

But given same big-O I would expect some solid reasons for a
big difference in coefficients before I assume a big difference
in performance.

... and that's the gist of my question: It seems to me likely
that the actual time to sort an ArrayList of large-ish N size will
be less than the time to build a TreeMap (BTW, Martin probably
meant TreeSet) of the same N items. Argument: The TreeSet expends
effort in keeping itself always sorted all the time, while the
ArrayList has the freedom to be disordered up until the end, and
then to impose an ordering just once. The ArrayList is asked to
present one sorted version of N items, while the TreeSet must
offer sorted versions of 1,2,3,...,N items. If the intermediate
orderings are not required, I don't see much reason to compute them.

I can follow you so far that TreeSort is likely a bit slower
than the ArrayList sort.

But I can not see any reason to expect a big difference.

It is fundamentally the same divide and conquer principle
applied.

Arne

 

[Arne Vajhøj]

On Tue, 2 Apr 2013 22:52:20 +0000 (UTC), Martin Gregorie wrote:

06 PM, Martin Gregorie wrote:
[...]
Its also not clear to me whether the OP is expecting some form of
sorted list of filenames. If he is expecting that, it would be
best to
use a TreeMap<String> rather than an ArrayList<String> to store the
filenames.
Is there a reason to prefer TreeMap (or other SortedMap) over
accumulate-disordered-and-sort-afterward?
I think so, yes, because none of File's list() and listFiles() methods
guarantee the order of the returned files. By using TreeMap or
equivalent
the OP gets the sort for free, should it be required.

For free ? The cost is just distributed amongst the insert calls, and is
likely considerably higher than with an unsorted list that has a single
sort call once it is filled.

It is not that obvious to me that:

n O(1) + 1 O(nlogn) is that much faster than n log(n)

The received wisdom I've heard would say that ArrayList is superior here
to a TreeMap. Recall that a TreeMap is a self-balancing red-black tree.
This means that every access of a node requires chasing at most O(lg n)
pointers, and that adding elements could require as many as O(lg n)
rebalancing operations. Compare this to ArrayList and the corresponding
sort technique, which is a merge sort. The array options chase
effectively no pointers (internal to the data structure), so the
accesses are predictable to the cache lines. As a result, you would
expect that the ArrayList+sort method is slightly faster in the general
case than the TreeMap implementation.

I do not have a problem with 'slightly'.

Another factor to keep in mind is algorithmic performance if the data
isn't actually uniformly random. If the input data is already sorted,
the sort function will likely achieve its best possible performance,
while the tree map will likely achieve its worst possible performance.
Since sorted data tends to be more realistic in practice than true
random, sorted lists actually have some things going for them.

Also true.

Arne

 

[Eric Sosman]

On 4/2/2013 8:04 PM, Joerg Meier wrote:
On Tue, 2 Apr 2013 22:52:20 +0000 (UTC), Martin Gregorie wrote:

06 PM, Martin Gregorie wrote:
[...]
Its also not clear to me whether the OP is expecting some form of
sorted list of filenames. If he is expecting that, it would be
best to
use a TreeMap<String> rather than an ArrayList<String> to store the
filenames.
Is there a reason to prefer TreeMap (or other SortedMap) over
accumulate-disordered-and-sort-afterward?
I think so, yes, because none of File's list() and listFiles() methods
guarantee the order of the returned files. By using TreeMap or
equivalent
the OP gets the sort for free, should it be required.

For free ? The cost is just distributed amongst the insert calls,
and is
likely considerably higher than with an unsorted list that has a single
sort call once it is filled.

It is not that obvious to me that:

n O(1) + 1 O(nlogn) is that much faster than n log(n)

By design, O() obscures all the coefficients. If you were
to say that n*log(n) and 9999999999999999999999999999*n*log(n)
are both O(n*log(n)) you would be right -- but if you were to
claim the former was not "that much faster" than the latter you
would be wrong by a factor of 9999999999999999999999999999.

Yes.

But given same big-O I would expect some solid reasons for a
big difference in coefficients before I assume a big difference
in performance.

... and that's the gist of my question: It seems to me likely
that the actual time to sort an ArrayList of large-ish N size will
be less than the time to build a TreeMap (BTW, Martin probably
meant TreeSet) of the same N items. Argument: The TreeSet expends
effort in keeping itself always sorted all the time, while the
ArrayList has the freedom to be disordered up until the end, and
then to impose an ordering just once. The ArrayList is asked to
present one sorted version of N items, while the TreeSet must
offer sorted versions of 1,2,3,...,N items. If the intermediate
orderings are not required, I don't see much reason to compute them.

I can follow you so far that TreeSort is likely a bit slower
than the ArrayList sort.

But I can not see any reason to expect a big difference.

It is fundamentally the same divide and conquer principle
applied.

The original assertion is "it would be *best* [emphasis mine]
to use a TreeMap<String> [sic] rather than an ArrayList<String>".
I'm not claiming that the difference is "big," nor even that the
difference is "important" -- for reasonably-sized directories, at
any rate. What I'm questioning is "best."

Also, I dispute "fundamentally the same." There is, I think,
a "fundamental" difference between a scheme that makes a sorted
traversal possible once at the end of things and a scheme that
promises such a traversal at every single intermediate stage.
The latter, it seems to me, necessarily does more work because it
adheres to a guarantee at points 1,2,...,N instead of at N only.

 

[Robert Klemme]

[...]
I believe in using "final" pretty often as it will immediately indicate
which local variables are constant for a method call and which are
modified all the time. [...]

De gustibus non disputandum est, but I think "final" should
be reserved for things that *mustn't* change, and shouldn't just
be pasted on to anything that happens to remain constant in the
code's current incarnation. When considering a change to some
code I might see

Thing thing = getThing();
// ... code that doesn't happen to change `thing'

I am so used to using "final" that this immediately makes me wonder why
it's not final - did the author intend to not change it, forget to
change it or forgot the "final"?

or I might see

final Thing thing = getThing();
// ... code that (obviously) doesn't change `thing'

In the first case I might think about inserting, say,

if (thing == null)
thing = fallbackThing();

... while in the second case I wouldn't even consider it: I
would suppose that the code relied on `thing' being exactly
what getThing() had returned, perhaps in some way and for some
reason not clear to me.

But, as I said above, de gustibus.

Maybe we're not that far apart: I make things "final" that are not
supposed to change. If at a later time I decide they need to change I
remove the "final" but it reminds me that other code relies on this
value not changing - so I can check whether the change breaks the code
in some way.

"finally" is a Godsend -- but did you mean "final"?

Yes, of course.

Kind regards

robert

 

[Arved Sandstrom]

On 4/2/2013 5:06 PM, Martin Gregorie wrote:
[...]
Its also not clear to me whether the OP is expecting some form of
sorted list of filenames. If he is expecting that, it would be best to
use a TreeMap<String> rather than an ArrayList<String> to store the
filenames.
Is there a reason to prefer TreeMap (or other SortedMap) over
accumulate-disordered-and-sort-afterward?

I think so, yes, because none of File's list() and listFiles() methods
guarantee the order of the returned files. By using TreeMap or equivalent
the OP gets the sort for free, should it be required.

For free ? The cost is just distributed amongst the insert calls, and is
likely considerably higher than with an unsorted list that has a single
sort call once it is filled. SortedMaps are for things that need sorting
accessible before all elements are inserted, which really isn't the case
here.

I use it a lot, both for that and because accessing stored objects by key
from a TreeMap is almost certainly faster than scanning an ArrayMap
unless it contains very few objects indeed.

Java doesn't have ArrayMaps.

[SNIP]

Well, Java actually does have ArrayMaps, if one is willing to include
published APIs other than those of the JDK. MyFaces, and Google API Java
Client, and Oracle Fusion Middleware Java API have similar ones, and
from the Javadocs (they all essentially boil down to "good for small
number of entries") they even resemble Martin's description.

AHS

 

[subhabangalore]

Dear Group,



I am taking out the files in my desktop folder, as,



File folder = new File("C:\\Users\\subhabrata\\Desktop");



Next, I am trying to take them out one by one as using for loop and name

of each file is converted to String,



for( File name :folder.listFiles()){

String s1=name.toString();

System.out.println("####"+s1);

System.out.print( name );

}



Till this there is no issue, now I am trying to insert name of all the files in an array, generally it can be done, as,



ArrayList<String> myList = new ArrayList<String>();

myList.add(s1);



But the problem I am facing is, if I put it as,



for( File name :folder.listFiles()){

String s1=name.toString();

System.out.println("####"+s1);

System.out.print( name );

ArrayList<String> myList = new ArrayList<String>();

myList.add(s1);

}



I am getting name of files individually but I want to see them as the whole bunch like,



myList=["string1","string2","string3",...."StringN"]



My aim is to check the names then in another for loop and if match is not found with some defined name update the list.



I am slightly new in Java so if anyone can kindly suggest how I should address it.



Regards,

Subhabrata.

Thanks Room for suggestion and discussion. It worked. Regards,Subhabrata.

 

[Steven Simpson]

It worked.

What worked? I counted a dozen or so distinct suggestions, not
necessarily mutually exclusive.

1. Build the combined string with a loop.
2. Use Guava libraries.
3. Use Apache libraries.
4. list.toString()
5. Move the list creation to before the loop.
6. Arrays.toString(list.toArray())
7. Don't bother trying to compose a string.
8. Create a fixed-size list using Arrays.asList.
9. Create a fully mutable list using new ArrayList(Arrays.asList)
10. Create a File object representing the filename you're looking for,
and test directly.
11. Use FastCat.
12. Use StringBuilder.
13. Use getPath().
14. Use getName().

 

[Joerg Meier]

Java doesn't have ArrayMaps. [SNIP]

Well, Java actually does have ArrayMaps, if one is willing to include
published APIs other than those of the JDK.

If one is willing to do that, the expression "Java has" or "Java doesn't
have" becomes effictively meaningless.

For example, would you consider the following statements to be true ?

Java has a 'val' data type.
Java has an OpenGL 3D engine.
Java has automatic getter and setter generation.
Java has voice recognition.
Java has function pointers.
Java has delegates.

I think most people would say those, as well as "Java has ArrayMaps", are
wrong. There is relatively little point to asking if a language the size
and popularity of Java has something 3rd party created.

In other words: no, when I say "Java doesn't have xxx", I don't count third
party libraries, and I have trouble believing most other people would.

Liebe Gruesse,
Joerg

 

[Robert Klemme]

Just as a matter of interest what's with all the finals

particularly

for (final File name : folder.listFiles())

[snip]

I believe in using "final" pretty often as it will immediately indicate
which local variables are constant for a method call and which are
modified all the time. Plus, with "final" you can easier catch errors
in control flow:

final String x;

if ( someCondition() ) {
x = y.toString();
}
else {
if ( someOtherCondition() ) {
x = "foo";
}
// forgot the else branch here
x = "bar";
}

System.out.println("We got " + x);

Generally I find "finally" quite useful - apparently significantly more
useful than you do.

Well I'm not sure that using a storage class to help you write a
conditional statement is 'good programming style' but hey ho, different
strokes for different folks

I am not sure what you mean by that. Can you elaborate? Where's the
storage class in the example above?

Anyway, the usability of final depends on your point of view I suppose.

We can certainly agree on *that*.

If for some reason I find myself using 'final' all over the place then I
would have to ask myself if my abstraction was coherent. If one has
something, or in fact a number of somethings that need 'protecting' in
this way then surely it is better to wrap them up in a component and
control access by virtue of the public interface of that component.

It probably depends. Sometimes you want to hold on to something because
obtaining it is expensive or the accessor might return a changed version
during subsequent calls but you want to be sure to retain a specific
status. In those cases I would not think that wrapping it up
necessarily helps because the data may actually have been wrapped
already. It feels a bit over the top introducing another layer just to
avoid a local variable with "final".

It's more OO, makes for cleaner code and of course provides opportunity
for the holy grail of OO 're-usability'

Maybe I could better see (and agree) if you provide a specific example
of what you mean here.

Kind regards

robert

 

[Joerg Meier]

[...] When I see the
modifier final it says something to me, it says, this value is not
modifiable ('scuse the pun).

Then you need to read a Java beginner tutorial

"final" makes a variable or field impossible to reassign. It says
absolutely nothing at all about whether or not that variables is
modifiable. What you are thinking of is immutability, something that is not
formalized in Java. In Java, having final mutable fields is perfectly
legitimate.

I know you know that, of course, I'm just saying, that's not really a
sensible way to look at final imo.

Liebe Gruesse,
Joerg

 

[Robert Klemme]

On 03/04/13 18:08, Robert Klemme wrote:

final, although it's not is it, at least it's not Java terminology,
apologies, I should have said 'modifier'. I'll restate.

Ah, OK, I see. Thanks!

Well I'm not sure that using a modifier to help you write a
conditional statement is 'good programming style'. When I see the
modifier final it says something to me, it says, this value is not
modifiable ('scuse the pun).

Sometimes you need nested conditions as shown and with a blank final you
can ensure that the variable is assigned exactly once on every possible
path. I find that useful.

Is it improving the clarity of your code to
use final for it's side effect, that is the side effect of causing the
compiler to barf because a final variable may already have been
initialized. I'm not sure about that.

That's not a side effect - it is _the_ effect of "final" modifier for
variables. "final" ensures a variable is assigned to at most once:

http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4

There is no other effect - final is all about assignment. This is true
for local variables - it's different with field which get assigned
compile time constants.

I'd say, "final" is probably even more useful for fields because it
ensures that a field is initialized in every constructor path - you
cannot forget it.

http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.3.1.2

For a single local variable I'd probably agree, in fact in general I
would agree but that wasn't my initial point really, in the code that
kicked off this sub thread there was more than one final variable, in
fact there were several in close proximity, I was initially questioning
the clarity of this for a new user. However then I opened my mouth and
put my foot in it and said ...



I think you probably know what I mean and any off the cuff example will
be contrived to the point irrelevance, so, leave it with me and I'll see
if I can come up with a simple self contained example.

Thank you!

Kind regards

robert

 

[Arved Sandstrom]

Java doesn't have ArrayMaps. [SNIP]

Well, Java actually does have ArrayMaps, if one is willing to include
published APIs other than those of the JDK.

If one is willing to do that, the expression "Java has" or "Java doesn't
have" becomes effictively meaningless.

For example, would you consider the following statements to be true ?

Java has a 'val' data type.
Java has an OpenGL 3D engine.
Java has automatic getter and setter generation.
Java has voice recognition.
Java has function pointers.
Java has delegates.

I think most people would say those, as well as "Java has ArrayMaps", are
wrong. There is relatively little point to asking if a language the size
and popularity of Java has something 3rd party created.

In other words: no, when I say "Java doesn't have xxx", I don't count third
party libraries, and I have trouble believing most other people would.

Liebe Gruesse,
Joerg

If we're going to be pedantic I might as well add that I wouldn't myself
say that Java has ArrayLists or HashMaps either. I consider "Java" to be
the language. If we're going to talk official libraries you'd have to
refer to a specific version of J2SE/Java SE or J2EE/Java EE, for example.

Having said that, I think the pragmatic question would be (or would have
been), are there reliable libraries available for a Java programmer to
do X? In many cases, both now and historically, if one were to adopt
your narrower definition, one would have to admit that X cannot be
easily done with just the Java language and official platform
APIs/implementations, not without a great deal of coding, whereas in
reality people would be availing themselves of well-known 3rd party
libraries to do just that.

AHS

 

[markspace]

"final" makes a variable or field impossible to reassign. It says
absolutely nothing at all about whether or not that variables is
modifiable. What you are thinking of is immutability, something that is not
formalized in Java.

Well, immutability is formalized in the JLS, and it's pretty important:

"final fields also allow programmers to implement thread-safe immutable
objects without synchronization." etc.

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5>

You might be referring to something else, but what you wrote there is
kind of misleading, at least.

 

[Arne Vajh?j]

Well, immutability is formalized in the JLS, and it's pretty important:

"final fields also allow programmers to implement thread-safe immutable
objects without synchronization." etc.

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5>

You might be referring to something else, but what you wrote there is
kind of misleading, at least.

????

The text you quote do not define immutable neither formal nor informal.

It refer to the concept.

If immutable is defined formally somewhere in the JLS it must be
somewhere else.

Until we have a ref, then I can't see anything misleading.

Arne

 

[markspace]

The text you quote do not define immutable neither formal nor informal.

It refer to the concept.

If immutable is defined formally somewhere in the JLS it must be
somewhere else.

Until we have a ref, then I can't see anything misleading.

Are you serious, Arne? Did you read the section I linked to? I didn't
quote the whole thing, it would be immense. I just quoted one line to
show that the section did talk about immutability, not to definitively
establish all the ins-and-outs of immutability in the JLS. There's no
point in me copying what you can read yourself.

Honestly I'm shocked at your response and I think you're missing the
point by a wide margin. Are you trying to tell me that final fields are
not involved in immutability in Java?

 

[Joerg Meier]

Well, immutability is formalized in the JLS, and it's pretty important:

"final fields also allow programmers to implement thread-safe immutable
objects without synchronization." etc.

You might be referring to something else, but what you wrote there is
kind of misleading, at least.

You display an honestly shocking and disturbing misunderstanding here. I
can only assume that this is some sort of temporary brain fart on your part
or bad communication between us. Making an object reference final does not
make the object immutable, and I have trouble believing you really think so
yourself.

Think about this piece of code:

final Point p = new Point(0, 0);
p.move(1, 1);

Are you really trying to say that you believe that the final keyword has
made p immutable, and that the call to p.move will fail to mut..ate ? p,
and that a subsequent call to p.getX() will return 0 ? Because if yes, then
you are simply wrong, and if no, then p is not immutable.

What the above quote means (and says) is that by USING final in the MAKING
of an object (as in writing a class), you can make an immutable object:

public class A {
final int b = 123;
}

A a = new A(); will now produce an immutable object a.

In fact it is a very popular (if not the most popular) way to deal with
synchronization to simply make as much as you can immutable, as that frees
you of a majority of synchronization concerns and issues.

But of course, again, you cannot make an mutable OBJECT immutable simply by
creating a reference to it that is decorated with final.

Basically, it's an issue about outside or inside: using final inside an
object on its fields can make that object immutable (assuming all state is
covered with finals), but just because you have a final reference to an
object does not change whether the object is modifiable or not.

Again, I'm pretty certain that you already know all of the above and we are
just having a communication breakdown.

Liebe Gruesse,
Joerg

 

[Joerg Meier]

If we're going to be pedantic I might as well add that I wouldn't myself
say that Java has ArrayLists or HashMaps either. I consider "Java" to be
the language. If we're going to talk official libraries you'd have to
refer to a specific version of J2SE/Java SE or J2EE/Java EE, for example.

You can feel free to say whatever you want, but lets be realistic: the
majority of people will say "Java has" for stuff in the JCL, and "Java
doesn't have" for stuff not in the JCL. And I am 99% certain that if I had
asked you any of the examples above, you would have said "No, Java doesn't
have a val data type", and you would have says "Yes, Java has a hash map,
it's java.util.HashMap".

You can be pedantic all you want, but I would argue that "stuff in the JCL"
is the definition used by the vast majority of people and really the only
one that makes much sense.

Having said that, I think the pragmatic question would be (or would have
been), are there reliable libraries available for a Java programmer to
do X? In many cases, both now and historically, if one were to adopt
your narrower definition, one would have to admit that X cannot be
easily done with just the Java language and official platform
APIs/implementations, not without a great deal of coding, whereas in
reality people would be availing themselves of well-known 3rd party
libraries to do just that.

If one was asking about libraries, one would likely ask that, and not
whether Java has it. I can only repeat what I said above.

Liebe Gruesse,
Joerg

 

[Joerg Meier]

06 PM, Martin Gregorie wrote:
[...]
Its also not clear to me whether the OP is expecting some form of
sorted list of filenames. If he is expecting that, it would be best
to use a TreeMap<String> rather than an ArrayList<String> to store
the filenames.
Is there a reason to prefer TreeMap (or other SortedMap) over
accumulate-disordered-and-sort-afterward?
I think so, yes, because none of File's list() and listFiles() methods
guarantee the order of the returned files. By using TreeMap or
equivalent the OP gets the sort for free, should it be required.

For free ?

I meant in terms of coding effort.

In terms of coding effort, it's one single line.

Not necessarily so (see above) and that's why I specified a TreeMap
rather than any other type of ordered map because of the relative drop in
access costs as the collection size increases.

A TreeMap has a higher access cost than an ArrayList. It's O(log(n)) for
both get and put, whereas ArrayList's is O(1).

And isn't the case with the TreeMap either - red-black binary trees have
rather nice characteristics there.

Which are nevertheless still only in the best case scenario as good as the
alternative, and never better.

Yeah, I meant ArrayList and should have been obvious from the context
provided by the OP.

Not really. Since you want access by key, it makes no sense to use an
ArrayList at all. But I suppose your original point, then, was correct: a
TreeMap would indeed be superiour to storing logical map data in an
ArrayList - I'm not even sure how you would fit both key and value into an
ArrayList. Was your alternative to using a Map to make a patchwork Entry
class to put keys and values in, and then make an ArrayList of those ?

Because if it was, I can think of plenty more scenarios that would be worse
than storing things in a TreeMap. Storing them in a String, for example.
But just because Strings suck to store map data in doesn't mean everyone
who wants to store map data should therefore use a TreeMap.

Liebe Gruesse,
Joerg