[Java] Iets toevoegen aan het einde van een array

[knopper]

Hoi allemaal,

Ik vraag me af als ik een array heb hoe ik dan waardes toe kan voegen zonder de array te overschrijven maar deze aan het einde toe te voegen.

In php kun je gewoon zoiets doen

PHP:

<?php

$array = array ();

$array[] = aap;
$array[] = koe;

?>

Vervolgens bestaat $array uit koe en aap.

Hoe gaat dit in java? In de tutorial van sun kon ik het niet zo snel vinden.

[Infinitive]

Arrays hebben een vaste lengte. Wat je wilt is op deze manier niet mogelijk. Gebruik voor dergelijke zaken de collections api. Bijvoorbeeld ArrayList. De collections bibliotheek in Java bevat nogal wat handige dingen, dus ik raad je aan om daar de nodigde aandacht in te steken.

[Plecky]

Zoals al gezegd hierboven: je moet in Java bij het maken van je array al opgeven welke lengte je wilt hebben, dit staat vervolgens vast.

Zo dus:

Java:

Beest[] dieren = new Beest[2];

dieren[0] = aap;
dieren[1] = koe;

Je kan hierna niets meer toevoegen, maar wel de inhoud van reeds gevulde posities vervangen.

Ik gebruik zelf meestal Vector, ook een Collection. Toevoegen van dingen:

Java:

// Niet vergeten te importeren
import java.util.Vector();

// Hier nog wat code

Vector dieren = new Vector();
// Eventueel initiele grootte meegeven

dieren.add(aap);
dieren.add(koe);

Objecten weer terughalen met dieren.elementAt() (retourneert Objects, dus wellicht daarna nog casten)

[Cloud]

Zoeken bij google op 'dynamic arrays java' gaf mij dit mooie resultaat. Let op; je kan geen dynamische arrays maken in java, je kan ze wel omzeilen, met een simpele home-made class

[knopper]

Ok, bedankt! Dat maakt het een stuk duidelijker.

[Macros]

Gebruik aub geen Vector maar een ArrayList.

[.oisyn]

Iets met onderbouwing enzo

[Jrz]

ArrayList is niet synchronized -> sneller, scheelt niet veel.
Dus doe maar Vector. synchronization wordt weggejit, en aangezien je niet veel ervaring hebt, is het handiger om voor de vector te gaan.

[MadMurdock]

Mja, Vector heeft ook mijn voorkeur en anders de volgende, beetje omslachtige , functie gebruiken:

Java:

public Beest[] addToArray(Beest[] oud, Beest b) { 
    Beest[] nieuw = new Beest[oud.length+1]; 
    int i= 0;
    for(i=0;i<oud.length;i++) { 
        nieuw[i] = oud[i];
    } 
    nieuw[i++] = b;
    return nieuw; 
}

(wel geschreven, maar niet getest )

[ Voor 29% gewijzigd door MadMurdock op 22-09-2004 20:17 . Reden: Jrz vond van niet.. ]

[Jrz]

Ok, dat gaat niet compilen

Vector en ArrayList gedragen zich hetzelfde.
arrayList.add(o) en vector.add(o)
(edit je post maar snel voor anderen het zien )

[zeroxcool]

Jrz schreef op 22 september 2004 @ 19:23:
Ok, dat gaat niet compilen

Vector en ArrayList gedragen zich hetzelfde.
arrayList.add(o) en vector.add(o)
(edit je post maar snel voor anderen het zien )

Maar uiteraard heeft Vector de +1 variabel .

[Macros]

Oke onderbouwing:
In een duister begin werd Java gemaakt. Daar moest een API bij met een variabele grote array. Snel werd er een Vector in elkaar gehackt. Toen later werd bedacht een systeem van Collection classes te maken, werd er besloten een nieuwe implementatie te maken. De ArrayList. Waarom een ArrayList gebruiken en geen Vector:
- eigenlijk is Vector deprecated en vervangen door ArrayList
- Vector is syncronized, en dus langer dan een ArrayList
- Vector gebruikte hele lange methodenamen, later toen de List interface kwam zijn de korte erbij gekomen, dus alle List methodes zijn dubbel

Kortom, een Vector is een oude jurk die opgelapt is naar de moderne tijd om weer een beetje in de mode te komen, maar is eigenlijk ouderwets. Gebruik aub de nieuwe mode.

[Cloud]

Heb je dan ook nog een bron voor die onderbouwing? Want ik wist niet dat de Vector class deprecated was, en java.sun.com weet het zelf ook nog niet! Op google had ik evenveel geluk... Dus waar haal je dat ooit vandaan?

[.oisyn]

Lekkere loze redenatie, dus omdat Vector vroeger ooit een oude interface had mag je het nu gelijk niet meer gebruiken
En wat bedoel je met "Vector is langer"? Of bedoel je langzamer? Lekker boeiend, het voordeel is dat ie synchronized is, en dat is het hele verschil met een ArrayList. Dat is echter geen reden om altijd een ArrayList te gebruiken, en nooit een Vector.

[MadMurdock]

Jrz schreef op 22 september 2004 @ 19:23:
Ok, dat gaat niet compilen

Mnee..

Toch maar ff veranderd

[Zoijar]

Even tussen door; je moet een (java) array niet vergelijken met een php-array. Dat laatste is nl. eigenlijk een "map"...

[Alarmnummer]

.oisyn schreef op 22 september 2004 @ 20:11:
Lekkere loze redenatie, dus omdat Vector vroeger ooit een oude interface had mag je het nu gelijk niet meer gebruiken

Je mag het best gebruiken.

En wat bedoel je met "Vector is langer"? Of bedoel je langzamer? Lekker boeiend, het voordeel is dat ie synchronized is, en dat is het hele verschil met een ArrayList.

Collections kun je eenvoudig synchronized maken door ze in een synchronized decorator te verpakken. Vector heeft dus niet echt veel nut meer (tenzij je zelf weer wilt extenden van een synchronized list).

[Macros]

Sun documentatie over de Vector en Stack

A Vector is an historical collection class that acts like a growable array, but can store heterogeneous data elements. With the Java 2 SDK, version 2, the Vector class has been retrofitted into the Collections Framework hierarchy to implement the List interface. However, if you are using the new framework, you should use ArrayList, instead.

Emphasis added

[Cloud]

Macros schreef op 22 september 2004 @ 21:32:
Sun documentatie over de Vector en Stack

[...]
Emphasis added

[sarcasme]Nou poeh poeh, daar is inderdaad de wereldkennis, genoemd op een niet-zo-bekende pagina (niet de Doc over de Class zelf) Hartstikke goed joh, meteen allemaal overstappen op ArrayList dus![/sarcasme]

FF serieus, dus daar maakte je al die drukte om? Waar het op neer komt is, is dat Vector niet deprecated is maar gewoon veroudert. En dat ie synchronized is (waar je dus niets aan hebt blijkbaar ), en dat maakt em blijkbaar langer. Sorry hoor, maar als ie écht deprecated wordt, dan ga ik wel over dat soort dingen nadenken. Maar dit zijn wel hele minieme verschillen, en absoluut niet dat soort verschillen waarvan ik meteen zeg; nooit meer Vector gebruiken!

[ Voor 5% gewijzigd door Cloud op 22-09-2004 21:48 . Reden: foutje ]

[Macros]

Je moet gewoon consequent zijn. Het is gewoon dom dat er twee versies van een bepaalde klasse in een API zitten.
Zo gebruik ik ook alleen maar de HashMap en niet meer de Hashtable. Misschien wordt de Vector nog wel ooit eens deprecated.

[Robtimus]

Plecky schreef op 22 september 2004 @ 18:31:
Objecten weer terughalen met dieren.elementAt() (retourneert Objects, dus wellicht daarna nog casten)

Je kan beter als List declareren en dan dus get(int index) gebruiken. Dan kun je door alleen de initialisatie te veranderen het type veranderen mocht dat nodig zijn (bv als een LinkedList beter is).

Alarmnummer schreef op 22 september 2004 @ 20:21:
Collections kun je eenvoudig synchronized maken door ze in een synchronized decorator te verpakken. Vector heeft dus niet echt veel nut meer (tenzij je zelf weer wilt extenden van een synchronized list).

java.util.Collections#synchronizedList(List list) doet dit mooi voor je

[Robtimus]

Macros schreef op 22 september 2004 @ 21:50:
Je moet gewoon consequent zijn. Het is gewoon dom dat er twee versies van een bepaalde klasse in een API zitten.
Zo gebruik ik ook alleen maar de HashMap en niet meer de Hashtable. Misschien wordt de Vector nog wel ooit eens deprecated.

Er zit een groot verschil tussen HashMap en Hashtable, behalve dan het synchronized verhaal: een Hashtable kan geen null keys of values aan, een HashMap wel.

[Alarmnummer]

Wolkjeh schreef op 22 september 2004 @ 21:45:
[...]


[sarcasme]Nou poeh poeh, daar is inderdaad de wereldkennis, genoemd op een niet-zo-bekende pagina (niet de Doc over de Class zelf) Hartstikke goed joh, meteen allemaal overstappen op ArrayList dus![/sarcasme]

Joshua Bloch (voor de kenners onder ons de persoon die verantwoordelijk is voor het collection framework). Zegt ook dat de vector out dated is.

FF serieus, dus daar maakte je al die drukte om? Waar het op neer komt is, is dat Vector niet deprecated is maar gewoon veroudert. En dat ie synchronized is (waar je dus niets aan hebt blijkbaar )

Zie mijn verhaal over de Collections.synchronizedList methode.

, en dat maakt em blijkbaar langer.

Het synchronized verhaal maakt hem niet langer, maar het feit dat later het collection framework later aan java is toegevoegd dan de Vector. De vector wouden ze ook in dit framework plaatsen, maar ze willen ook backwards compatible zijn. Daarom zit de vector dus met een enorme zooi ouwe methodes die je niet hoort aan te spreken. *moppelt iets over subsumption*

Sorry hoor, maar als ie écht deprecated wordt, dan ga ik wel over dat soort dingen nadenken. Maar dit zijn wel hele minieme verschillen, en absoluut niet dat soort verschillen waarvan ik meteen zeg; nooit meer Vector gebruiken!

Je kunt de vector best gebruiken, en in sommige gevallen (ben er zelf nog nooit een tegengekomen) kan de vector ook handig zijn (als je wilt extenden van een synchronized list structure).

[Cloud]

Consequent zijn is heel goed, vooral bij programmeren Ben ik met je eens. Maar voor iemand die (zo heb ik opgevat uit de TS) nog niet zo bedreven is met Java, is dit misschien niet zo heel erg van belang. Maar tuurlijk zit er wel wat in om meteen de up-to-date classes te gebruiken. Je moet alleen maar weten dat ze een goede vervanger gevonden hebben Wist ik (en volgens mij bijna niemand in deze topic) in ieder geval niet.

Voor Alarmnummer:
Jep ben ik het ook wel mee eens, als jij zegt dat die dingen zo zijn, dan neem ik aan dat je gelijk hebt. Maar dan nog, is dit wel helemaal van belang voor de TS? Zo diep zit hij nog lang niet in de materie (vermoed ik).

[ Voor 22% gewijzigd door Cloud op 22-09-2004 21:56 ]

[knopper]

Wow, toch nog een hele discussie hiero...;)

Nee, ik ben inderdaad nog niet heel bedreven in Java maar heb wel wat meer ervaring met PHP en vandaar dat ik dat maar even als vergelijkingsmateriaal heb gebruikt om het "probleem" uit te leggen.

Ik zal als ik de tijd heb de gegevens opties allemaal eens rustig bekijken en nagaan welke ik het beste kan gebruiken. Het doel is namelijk dit te gebruiken in een "JList".

Nu begin ik alleen een beetje te twijfelen of daar wel een (echte) array gebruikt wordt aangezien niet vantevoren wordt bepaald uit hoeveel waardes de array bestaat.
In het boek dat ik lees staat namelijk gewoon

Java:

String label[] = { "Zero", "One", "Two", "Three", "Four" };

Er wordt niet vantevoren vastgelegd uit hoeveel waardes label[] bestaat.
Ik begrijp nog wel dat het hier dus om een String gaat maar ik vind het wel erg veel weg hebben van een (php) array.

[Cloud]

knopper schreef op 22 september 2004 @ 22:40:
Nu begin ik alleen een beetje te twijfelen of daar wel een (echte) array gebruikt wordt aangezien niet vantevoren wordt bepaald uit hoeveel waardes de array bestaat.

Waarschijnlijk (ik ken JList niet zo goed) gaat het wel om een échte array, alleen dan een met een class eromheen. Deze zorgt ervoor dat als er een item bij komt (wat buiten de grootte van de array valt) er een nieuwe, grotere, array gemaakt word.

Java:

String label[] = { "Zero", "One", "Two", "Three", "Four" };

In het java voorbeeld wat jij geeft, word wél een grootte meegegeven aan de array, namelijk het aantal argumenten dat jij meegeeft.

[Woy]

Bij de declaratie kan je idd een aantal elementen meegeven. Dat aantal is dan de lengte van de Array. Je array kan je daarna niet meer vergroten.

[Macros]

Als je gebruik wil maken van een JList moet je een ListModel implementeren. Je kan ook een DefaultListModel gebruiken. Let wel op:

Presently it delegates to a Vector, in a future release it will be a real Collection implementation.

[Cloud]

Macros schreef op 23 september 2004 @ 00:08:
Als je gebruik wil maken van een JList moet je een ListModel implementeren. Je kan ook een DefaultListModel gebruiken. Let wel op:

[...]

Nou wil ik absoluut niet irritant overkomen hoor, maar ik vermoed niet dat de TS enig idee heeft wat die post te betekenen heeft Misschien ietsje meer uitleg? (zou'k zelf ook interessant vinden)

[Macros]

JList tekent een lijst van elementen op het scherm. De lijst zelf zit niet 'in' de JList. Je kan hem globaal op 2 manieren elementen laten zien. Door hem een array met objecten te geven. Dan kan je er niks meer aan veranderen.
Of door een ListModel te gebruiken. Zoals de naam al zegt, is het een model voor een list, de JList. Dit model is een object dat de ListModel interface implementeerd. Iedereen kan dus een eigen ListModel maken waardoor je helemaal kan bepalen hoe de elementen eruit komen te zien.

offtopic:
Je ListModel zou dus ook objecten kunnen 'genereren'. Zo kan je bijvoorbeeld alle int's van 0 tot max_int kunnen laten zien in een JList

Maar omdat het omslachtig is om voor elk wissewasje een ListModel zelf te maken zijn er 2 makkelijkere oplossingen.
Je kan de DefaultListModel gebruiken. Deze heeft dezelfde methoden als de (oude) Vector (dus elementAt() enzo, dus niet de nieuwe List methodes (dat wordt later wel veranderd). Hiermee kan je tijdens het draaien van het programma elementen toevoegen aan de lijst. Dat doe je dus niet door de JList zelf aan te spreken, maar zijn model.
Of je extends AbstractListModel, die doet het meeste al voor je. Je moet alleen 2 methodes implementeren. (getElementAt, getSize)
In jou geval is het dus het makkelijkst om DefaultListModel te gebruiken. Persoonlijk maak ik mijn eigen model van AbstractListModel. Voordeel: je kan zelf bepalen wat voor interface je aan je programma presenteerd. Zo kan je een toevoeg methode schrijven die nieuwe elementen sorteerd op iets, of dubbele niet acepteerd. Je hebt veel meer controle dan een normale ArrayList, Vector of DefaultListModel.

Nu vraag je je af waarom je niet gewoon een ArrayList kan gebruiken als een ListModel. Nou, dat komt omdat een ListModel de JList moet vertellen wanneer er iets is veranderd aan het model. Als je zelf AbstractListModel gebruikt moet je dat zelf ook doen door de fireContentsChanged, fireIntervalAdded, fireIntervalRemoved aan te roepen als je het model veranderd.

Voorbeeldje:

Java:

MijnListModel extends AbstractListModel{
  private List<String> data = new ArrayList()<String>;
  
  //ListModel interface
  public Object getElementAt(int index){
    return data.get(index);
  }
  
  //ListModel interface
  public int getSize(){
    return data.size();
  }
  
  //eigen interface naar het model
  public void voegToe(String titel){
    int pos = Collections.binarySearch(data, titel);
    if(pos < 0){ // titel is nieuw als pos is kleiner dan 1
                 // -(pos-1) geeft de plek in de lijst aan waar hij zou moeten indien gesorteerd
      pos = -(pos-1);
      data.add(titel, pos);
      fireIntervalAdded(this, pos, pos); //geef door aan JList dat het model veranderd is
    }
    // als hij er al in staat doen we niets
  }
}

Nu vergeet ik te vertellen hoe je hem gebruikt. Dat is eigenlijk heel makkelijk:

Java:

MijnListModel titelLijst = new MijnListModel(); //maak nieuw model
JList titelLijst = new JList(titelLijst);

Dan kan je nu ergens in een ActionListener die bij een knop of invoerveldje zit, of misschien een database, of elke zoveel seconden, of door een berekening, of at random of uit een bestand nieuwe titels halen/maken/ruiken.
Bijvoorbeeld uit een invoer veld:

Java:

String titel = textInvoerVeld.getText();
titelModel.voegToe(titel);

Nu wordt al door je model gezorgt dat de lijst gesorteerd blijft. Ook al gebruik je een ArrayList waarbij er 10 manieren om data toe te voegen is, je kan er alleen maar bij met voegToe(), dus je hoeft alleen met die methode rekening te houden om je data gesorteerd te houden.

[ Voor 16% gewijzigd door Macros op 23-09-2004 00:53 . Reden: Wat meer uitleg erbij. ]

[knopper]

Ok, bedankt voor je uitleg. Ik zal er als ik wat tijd heb iets meer documentatie over lezen.

[ACM]

Macros schreef op 23 september 2004 @ 00:47:
Deze heeft dezelfde methoden als de (oude) Vector (dus elementAt() enzo, dus niet de nieuwe List methodes (dat wordt later wel veranderd).

Vector implementeert al sinds de introductie van het Collections-framework de List-interface...

Maar ik ben het wel met je eens dat je in principe beter de ArrayList kan toepassen dan de Vector. En de reden is simpel:
Zolang je geen technische reden hebt om voor de Vector of de ArrayList te gaan, kies dan voor de ArrayList; Die heeft bij Sun de voorkeur gekregen sinds het Collections-framework is geintroduceerd.
En dat is imho voldoende reden om bij geen technische voorkeur de ArrayList te nemen. Pas als je zeker bent dat je een synchronized collection nodig hebt, zou je ertoe kunnen overgaan de Vector te gebruiken, die is iets sneller dan een synchronized list uit Collections, meen ik, en sowieso handiger aan te maken.

Wat je imho wel gelijk moet houden is de abstractie waarmee je je object aanmaakt:

Java:

// Niet:
Vector v = new Vector();
// Of:
ArrayList al = new ArrayList();
// Maar:
List l = new Vector();
// En:
List l = new ArrayList/LinkedList/etc;

In dat geval kan je veel simpeler de keuze voor Vector later veranderen in ArrayList en vice versa, omdat je beide verplicht met de List-interface aanspreekt ipv met eventuele eigen interfaces.