Using Lists instead of arrays in parser/compiler DOM?

[mickaelistria]

Hi all,
As I'm playing with the parser, I see it uses arrays in many places, and lots of System.arrayCopy and array size management and so on. While I can imagine it can allow to save a few references here and there, I find it makes the code seem more complex and more fragile in some places compared to using List<>.
So I'm curious: is there an important reason to stick to arrays? or is there some strong counter arguments against using some Lists in place of arrays?
If moving to list would seem welcome, I volunteer in doing some of the work here.

[manojnpalat]

Historically, jdt.core was at 1.4 for a long time. I don't know whether this was the sole reason, but List<> was not available to use.
You may want to take it only on a case-to-case incremental basis rather than introducing a big bulk change.

[carstenartur]

The osgi module system had been offered as solution to the problems that arise from the fact that you want invent new versions of a library with internal improvements. With the advent of collections many situations that e.g. require a "set" that does not allow duplicates and has no defined order like an array would be the right choice as data structure to use while the existing use of arrays is simply the wrong choice. The same is with the support of concurrent processing where arrays offer nothing. Why not create a copy of the modules in question with a bigger major number and start there with internal improvements and add additional api to make use of generics and other compatibility breaking changes? For some time both could be built and maintained and as soon the burden of the old library is to high and the improvements in the new version is worth it the old one could be abandoned and switched to it.

[jukzi]

I would prefer non-null Collection especially on APIs. arrayCopy can often also be substituted With Arrays.copyOf / copyOfRange() which already makes sourcecode easier to read.