Ty vypocty sedi, ale otazka zni, proc je pouzit ArrayList? Docela bych rekl, ze je to dost umely priklad ne? Pole intu neni v mode? Btw i kdyby znela odpoved "ale ja potrebuju insert/delete/append", tak v ArrayListu se budou delat ty same operace, co by se udelaly s arraycopy.
S kolekcemi (interně primárně arraylisty) se pracuje velice pohodlně, rychle a hlavně bezpečně. Obzvláště použití streamů na běžné pořád opakované úkony kód zkracuje a zpřehledňuje. Pokud to interně v JVM pojede jako pole intu, jedině dobře.
Jasne o tom neni sporu, ale priznejme si - vetsina prikladu, co tady zaznela, nevede k pouziti ArrayListu, semanticky to byly vetsinou mnoziny (Set). Coz samozrejme nic nemeni na tom, ze i Set<int> a ne Set<Integer> by bylo fajn mit primo v zakladni knihovne. No nestalo se.
Re: pole objektu je pole referenci, ma to i vyhody, obecne dela GC v Jave "dobre" kdyz jsou objekty male, naopak "humongous" objekty se s GC dost perou (jdou primo do old generation atd.).
Ano, ale pole hodnotových typů nebude přece o mnoho větší než původní pole referencí. A navíc tam nebudou ty malé objekty.
To byla spis odpoved na tu cast diskuze, kde se resila pole objektu, coz v cecku odpovida poli struktur. Priklad:
struct x
{
int id;
float perc;
};
int main()
{
struct x zaznam;
struct x pol
e[1000];
printf("%ld\n", sizeof(zaznam));
printf("%ld\n", sizeof(pole));
return 0;
}
Vypise na vystup 8 bajtu pro "zaznam" a 8000 bajtu pro pole.
V Jave to takto nejde, ma to svoje duvody:
1) historie
2) zajimave je, ze v Jave se nikdy nemusi resit velikosti objekty, protoze ty jsou bud konstantni nebo jde o pole, takze pole objektu je pohodicka - pole referenci. Ze ma nejaky objekt v sobe String? Neni problem, to je stejne reference na objekt s vnitrnim polem jako atributem. atd. Neni to asi vsude idealni, ale ta jednoduchost pro JVM z toho asi vyplyva.