# ArrayList initialisieren



## MQue (10. Mrz 2009)

ich möchte eine ArrayList einer Methode übergeben und dazu diese ArrayList beim Methoden aufruf initialisieren,
ich habs jetzt versucht mit 

methodenAufruf(new ArrayList(){"init1", "init2"})

aber so funktionierts leider nicht,
wie kann man das machen?
Vielen Dank,


----------



## Ebenius (10. Mrz 2009)

[HIGHLIGHT="Java"]methodenAufruf(new ArrayList(Arrays.asList({"init1", "init2"})))[/HIGHLIGHT]
Ebenius


----------



## Verjigorm (10. Mrz 2009)

Oder sowas:


```
List<Integer> list = new ArrayList<Integer>()
        {
            {
                add(1);
                add(2);
                add(3)
            }
        };
```


----------



## SlaterB (10. Mrz 2009)

insgesamt humaner wäre vielleicht eine neudefinierte statische Methode

methodenAufruf(Helper.createList("init1", "init2"));


----------



## didjitalist (10. Mrz 2009)

Verjigorm hat gesagt.:


> Oder sowas:
> 
> 
> ```
> ...



davon rate ich stark ab. eine anonyme klasse zu definieren, nur um einer ArrayList ein paar werte zu spendieren, führt zu mehr verwirrung, als dass es nutzen bringt.


----------



## musiKk (10. Mrz 2009)

Sehe ich auch so. Übrigens ein Punkt, wo uns C# leider voraus ist, da kann man Listen nämlich so definieren, wie im ersten Post.


----------



## Ebenius (10. Mrz 2009)

musiKk hat gesagt.:


> Sehe ich auch so. Übrigens ein Punkt, wo uns C# leider voraus ist, da kann man Listen nämlich so definieren, wie im ersten Post.


C#... Jupp, ich bin auch dafür alles was man irgendwo mal gebrauchen kann in die Sprache reinzupfuschen. 

Ebenius


----------



## musiKk (10. Mrz 2009)

Das war nicht polemisch gemeint.


----------



## Ebenius (10. Mrz 2009)

War mir klar. Mein's dafür zynisch.  Ich bin sehr froh darüber, dass die Sprache Java sehr stabil bleibt und viele Features nicht bietet. Aber das ist Glaubensfrage.


----------



## Wildcard (10. Mrz 2009)

Für sowas soll es bitte bitte keine neuen, nutzlosen Sprachfeatures geben, höchstens ein neuer Konstruktor. Bis dahin kann man sich das selbst bauen:
[HIGHLIGHT="Java"]public class MyList<E> extends ArrayList<E> {

	public MyList(E...es) {
		for (int i = 0; i < es.length; i++) {
			add(es_);
		}
	}

	public static void main(String[] args) {
		MyList<Integer> intList = new MyList<Integer>(1,2,3,4,5);
	}

}[/HIGHLIGHT]_


----------



## musiKk (10. Mrz 2009)

Ich verstehe jetzt nicht, warum es nutzlos sein soll. Es ist nicht wirklich weit hergeholt und imho auch intuitiv. Versteht mich nicht falsch, ich will nicht gegen eure Meinungen wettern (und auch nicht C# groß hochloben, ich programmiere damit auch kein Stück), ich verstehe nur die Begründung nicht.
Ob ich nun einen Eimer oder ein Fass habe, es wäre doch schön, wenn ich den gleichen Schlauch zum Befüllen nehmen kann.


----------



## Wildcard (10. Mrz 2009)

Ein Array ist ein Sprachkonstrukt, eine Collection ist nur ein einfaches Interface. Dafür soll es keine extra Behandlung geben. 
Zumal, wie man sieht, eigentlich nur ein passender Konstruktor fehlt.
Der wichtigste Usecase ist aber durch Collections#singeltonList schon abgedeckt.


----------



## Ebenius (10. Mrz 2009)

Wildcard hat gesagt.:


> Der wichtigste Usecase ist aber durch Collections#singeltonList schon abgedeckt.


Bzw. durch Arrays.asList(...). Genau.

Die Hochsprachen sind schwer genug. Man sollte stets überlegen, ob man ein Feature auf Sprachebene einführt und wie viel Nutzen es bringt. Schließlich zieht eine Veränderung der Sprache viel mit sich; IDEs müssen zum Beispiel Ihr Highlighting anpassen (erkennt Visual Studio inzwischen eigentlich, dass "value" in C# ausschließlich innerhalb eines Property-Setters ein Schlüsselwort ist?), die Compiler müssen angepasst werden, die Spezifikationen und Bücher müssen überarbeitet werden. All das ist nicht nötig, wenn man die Sprache nicht anfasst. So lange es eine Lösung ohne Sprachänderung gibt die beinahe nicht komplizierter ist (Arrays.asList, Collections.singletonList) gibt es keinen Grund die Sprache zu ändern. Es hat schon Gründe, dass so einfache Konstrukte wie "foreach" Jahre auf sich warten ließen. Es gab gut funktionierende Workarounds die kaum mehr Code produzierten und die Änderung selbst rechtfertigt eine neue Sprachversion bei weitem nicht.

Microsoft arbeitet da ganz anders. In jeder Major-Version einer Sprache wie VB oder C# ändert sich irgendwas. Selbst die hauseigenen Entwicklungsumgebungen stecken wegen solcher Volatilität oft voller Fehler; von diversen Kompatibilitätsproblemen ganz zu schweigen.

Ebenius


----------



## musiKk (10. Mrz 2009)

Nun, Microsoft ist garantiert eine der Firmen, die aufgrund enormer Rückwärtskompatibilitäten mehr Probleme haben, als umgekehrt (im Gegensatz zum Apfel... *hust*). Als Beispiel nur mal (alles nur angelesen, nie selbst programmiert): In VB haben Arrays immer bei 1 angefangen. Weil aber alle anderen Sprachen bei 0 beginnen, wurde das Array in irgendeiner Version um ein Element vergrößert. Nun passen beide Varianten. Schlimmer eher, dass selbst die modernen Betriebssysteme noch Relikte aus frühesten Zeiten mitschleppen. Aber das ist langsam wirklich eine andere Geschichte.

Es stimmt, dass auch gering wirkende Änderungen für die Compilerbauer nur unter teils großem Aufwand zu bewirken sind. Ich finde trotzdem, dass foreach (und vor allem Enums... dafür bin ich Sun wirklich böse, dass die nicht gleich kamen) enorm nützlich ist und würde es auf keinen Fall mehr missen wollen.

Was ich an Arrays.asList() nicht mag, ist, dass ich keine Kontrolle über die Implementierung habe. Die resultierende Arrays$ArrayList implementiert z. B. kein remove() und erzählt mir das erst zur Laufzeit. Dadurch ist halt nochmal die Overhead verursachende Übergabe an einen anderen Konstruktor (ArrayList z. B.) nötig.
Dennoch: Ihr habt natürlich nicht Unrecht. Gerade Wildcards Argument kann ich nicht viel entgegensetzen, daran hatte ich gerade gar nicht gedacht.
(Verursache ich eigentlich zu viele abschweifende Diskussionen? Manchmal kommts mir so vor...)


----------



## Ebenius (11. Mrz 2009)

Die abschweifenden Diskussionen nachdem das Thema erledigt ist empfinde ich persönlich als angenehm. Wenn nicht, äußere ich mich nicht. 

Was Du sicher weißt: Arrays.asList ist nur ein Wrapper für ein Array. Dieses zu erzeugen ist kaum Aufwand und die entstehende Instanz braucht beinahe keine Resourcen; das Feld existiert ja vorher schon.

Ebenius


----------



## musiKk (11. Mrz 2009)

Gut, dann bin ich beruhigt. 

Die entstehende Arrays$ArrayList (ich berufe mich mal so drauf, damit sie nicht mit der "echten" ArrayList verwechselt wird) kann in der Tat fast nichts. Die Array-Referenz darin ist sogar final, kein Wunder, dass außer get und set nicht viel geht. Warum ArrayList kein Array direkt (per Konstruktor übergeben) verwenden kann, versteh ich auch nicht so ganz, das wäre hier sicher auch ganz gut, aber wie bei vielem wird es sicher auch dafür seine Gründe geben.


----------



## didjitalist (11. Mrz 2009)

es gibt doch Arrays#asList(), daher gibt es keinen bedarf, noch einen konstruktor einzuführen.


```
T[] someArr = ...
List<T> mutableList = new ArrayList<T>( Arrays.asList( someArr ) );
```


----------



## Marco13 (11. Mrz 2009)

Erstmal vorneweg: Für solche Initialisierungen eigene anonyme (oder auch nicht anonyme) Klassen zu machen, ist IMHO gröbster Unfug...

```
class ListWithOne extends ArrayList
{
    add(1);
}
class ListWithTwo extends ArrayList
{
    add(2);
}
...
```
oder was? :autsch: 

Und hierzu noch ein kleiner Punkt:


musiKk hat gesagt.:


> Was ich an Arrays.asList() nicht mag, ist, dass ich keine Kontrolle über die Implementierung habe. Die resultierende Arrays$ArrayList implementiert z. B. kein remove() und erzählt mir das erst zur Laufzeit. Dadurch ist halt nochmal die Overhead verursachende Übergabe an einen anderen Konstruktor (ArrayList z. B.) nötig.



Man kann die entstehende List an jede andere Collection im Konstruktor übergeben, und hat damit die gewünschte Implementierung. Zeitkritisch ist das eigentlich nicht, weil die Liste 1. entweder sehr kurz ist, oder 2. sehr lang ist, und dann diese Art der Initialisierung eh fehl am Platz ist. WENN das in irgendeiner inneren Schleife oder so gemacht wird, wo jedes "new" potentiell die Performance beeinflusst, würde man das anders lösen - und für diesen speziellen Fall eine Speziallösung anzubieten, wäre syntatktischer Zucker, der das Verhältnis zwischen "Anzahl der Methoden" und "Durch die Methoden gebotenen Möglichkeiten" (also das "_Gewicht_" der Methoden) negativ beeinflussen würde.


----------

