[java] Data in tekstbestand gebruiken in programma

[knopper]

Hoi allen,

Ben bezig met een programma in Java om mijn duiklog digitaal bij te kunnen houden. Ben nu bijna klaar met de GUI. Ik loop echter vast op het volgende, voorlopig wil ik de duiken gewoonweg laten opslaan in een tekstbestand maar ik heb geen ervaring met methodes om dit te doen. (Enige wat ik kan is in php dingen opslaan m.b.v. sql....) Hierbij bedoel ik eigenlijk beide betekenissen van het woord "methodes/functies", enerzijds de theorie en anderzijds de praktijk in Java dus. De praktijk in Java zal moeten gebeuren met NIO/IO maar ik heb geen idee hoe ik het makkelijkste de gegevens in het tekstbestand orden.

Kan iemand mij iets zinnigs zeggen over de lay-out van zo'n bestand zodat er in het programma makkelijk te werken valt met de data die erin staat?

Een verwijzing naar een tutorial hierover zou ook erg helpen...

[Macros]

Persoonlijk vind ik textfiles niet erg handig om te gebruiken in Java. Als je er weer data uit wilt halen moet je alles weer terug parsen. Dat is niet zo'n probleem als het platte tekst is, maar ik begrijp dat het over duiken gaat en dus een tijd, plaats en omschrijving enzo erbij moet staan.
Als het niet zo nodig is om de files handmatig te editen, kan je het beste een 'duik' object maken en die Serializable maken. Dan een ObjectInputStream/ObjectOutputStream gebruiken om naar een FileInput/FileOutputStream te lezen/schrijven. Dan kan je er duik objecten indoen en duik objecten uithalen.

[knopper]

Gegevens die erin komen te staan zijn o.a. Naam, Land, tijd in, tijd uit, druk in, druk uit, diepte, zicht en meer van dat soort dingen.

Wat je voorstelt klinkt goed, is hier uitgebreide informatie over te vinden op de site van Sun of weet je ergens anders nog iets waar dit duidelijk wordt beschreven? (Ik zeg maar iets: is het boek "Java NIO" van O'Reilly de moeite om hiervoor door te nemen? Ik heb namelijk al 2 boek van O'Reilly over Java en ik vind dit altijd zeer prettige boeken.)

[Kwistnix]

Eventueel zou je het ook in XML format kunnen opslaan. Komt in iedergeval de uitwisselbaarheid van het log ten goede.

[Macros]

Ik heb geen tutorial ofzo, maar alles staat duidelijk in de [url=http://java.sun.com/j2se/1.5.0/docs/api/]API[/ur] van Sun. Kijk bij de java.io FileInputStream, FileOutputStream, ObjectInputStream en ObjectOutputStream.
Het idee is simpel. Als je wilt opslaan, dan maak je een FileOutputStream met een File object. Daarmee maak je een ObjectOutputStream. Daar zend je je objecten naar toe (als je meerdere duiken opslaat, doe het dan eerst in een Collection Class, bijvoorbeeld een ArrayList).

Dan als je het weer wilt inlezen, dan maak je een FileInputStream, daarvan een ObjectInputStream en dan doe je readObject(). Je moet dan wel weten wat je erin hebt gedaan, omdat je het dan moet casten. Dat is makkelijk als je er een ArrayList in hebt gedaan.

Hier is een voorbeeldje waarbij ik wat static methods in een classe heb getoegevoegd omzichzelf op te slaan:

Java:

    public static NeuralNet loadNeuralNet(File file) throws FileNotFoundException, IOException, ClassNotFoundException{
        return loadNeuralNet(new ObjectInputStream(new FileInputStream(file)));
    }
    
    protected static NeuralNet loadNeuralNet(ObjectInputStream stream) throws IOException, ClassNotFoundException{
        return (NeuralNet) stream.readObject();
    }
    
    public static void saveNeuralNet(File file, NeuralNet net) throws FileNotFoundException, IOException{
        saveNeuralNet(new ObjectOutputStream(new FileOutputStream(file)), net);
    }
    
    public static void saveNeuralNet(ObjectOutputStream stream, NeuralNet net) throws IOException{
        stream.writeObject(net);
    }

Zoals je ziet, gebruik ik een File object, daarmee maak ik een FileInput/OutputStream, waarmee ik een ObjectInput/OutputStream maak. En dan doe ik writeObject of readObject op die stream.
Alle objecten die je wilt opslaan op zo'n manier moeten Serializable zijn. Dat is een interface zonder methoden, dus makkelijk genoeg om te implementeren voor je eigen klassen

[knopper]

Ik ben aan het twijfelen of dit misschien een goede optie is: http://hsqldb.sourceforge.net

Dit schijn je gewoon binnen je programma te kunnen draaien en te kunnen gebruiken met de JDBC interface. Verder kun je dus gewoon sql gebruiken. Als ik het goed begrijp neemt het ook weinig ruimte in beslag.

[ Voor 4% gewijzigd door knopper op 19-09-2004 13:19 ]

[Alarmnummer]

HSQLDB is een erg fijne db. Je hoeft niets bij odbc te registreren. Voor een standalone applicatie hoef je alleen maar een jar te includen. Ideaal voor lightweight database oplossingen. Verder kan het uitvoer geven in komma gescheiden tesktbestanden, of als 1 sql-script bestand.

[knopper]

Dus dit zou ook wel een goede oplossing kunnen zijn?

[flowerp]

HSQLDB lijkt me een goede oplossing. Je kunt hiermee via JDBC makkelijk data op high-level niveau opslaan. Zeker als je een PHP achtergrond hebt zul je het waarschijnlijk niet zo leuk vinden om in een ongestructureerde file char voor char in te lezen, bij te houden waar je zit in de file enz. Dat is voor PHP mensen behoorlijk low-level en gewoon niet 'leuk'.

Het voordeel van HSQLDB (of andere SQL DB) is dat je meteen je data in een universeel formaat opslaat en via SQL makkelijk dingen kunt opvragen als "alle duiken op dagen wanneer het niet regende" ofzo iets. Je kunt er ook meteen bij vanaf andere applicaties (in andere talen desnoods), zonder je parse code overnieuw te schrijven.

XML is ook een oplossing, en werkt ook op high-level niveau. Je hebt dan alleen meestal niet de mogelijkheid voor queries.

[Alarmnummer]

flowerp schreef op 19 september 2004 @ 13:32:
XML is ook een oplossing, en werkt ook op high-level niveau. Je hebt dan alleen meestal niet de mogelijkheid voor queries.

*kuch* XQuery *kuch*

fallenangel666
Eventueel zou je het ook in XML format kunnen opslaan. Komt in iedergeval de uitwisselbaarheid van het log ten goede.

Ik zou trouwens sowieso niet gaan voor XML. XML is niet gemaakt voor dataopslag maar voor data uitwisseling/transformatie. Databeestjes zijn nog steeds het beste ervoor.

[ Voor 44% gewijzigd door Alarmnummer op 19-09-2004 13:42 ]

[knopper]

Hartelijk dank allemaal!

Gezien de voordelen van een sql database waar ik idd wat meer ervaring mee heb ga ik denk ik maar eens hsqldb bestuderen en kijken hoever ik ermee kom.

Leuke toevoeging zou kunnen zijn om vanaf afstand (een duiklocatie?) je duiken online te kunnen invoeren d.m.v. een php script welke dezelfde database gebruikt. Maar voorlopig hou ik het gewoon op een single-use, standalone applicatie... Dat is voor nu al lastig genoeg....:*)

[Alarmnummer]

knopper schreef op 19 september 2004 @ 13:44:
Hartelijk dank allemaal!
Gezien de voordelen van een sql database waar ik idd wat meer ervaring mee heb ga ik denk ik maar eens hsqldb bestuderen en kijken hoever ik ermee kom.

Je kunt zelf hardcore SQL gaan proggen, maar je kunt ook kijken naar Object Relationeel (OR) Mappers zoals hibernate. Jij zegt hoe jouw objecten gemapt moeten worden naar de database en hibernate zorgt voor de rest.

Leuke toevoeging zou kunnen zijn om vanaf afstand (een duiklocatie?) je duiken online te kunnen invoeren d.m.v. een php script welke dezelfde database gebruikt.

Zorg ervoor dat je je applicaties in layers gaat opzetten. De belangrijkste layer is je domein layer. Hierin vind je objecten zoals DuikTijdstip, Metingen etc. Als j er voor zorgt dat deze domein layer geen (of weinig) afhankelijkheden heeft naar zijn layers erom heen (datalayer, weblayer etc). Dan is het eenvoudig(er) om van een normale applicatie een webapplicatie te maken.

Maar voorlopig hou ik het gewoon op een single-use, standalone applicatie... Dat is voor nu al lastig genoeg....:*)

Wijs plan.

[flowerp]

Alarmnummer schreef op 19 september 2004 @ 13:35:
[...]

*kuch* XQuery *kuch*

Daarom zij ik ook 'meestal', maar eigenlijk bedoelde ik SQL queries. Je hebt natuurlijk ook nog dingen als Xpath enzo die ook een beetje query achtig zijn. XQuery ken ik niet, dus voor ik te veel ga blaten hier zal ik dat eens gaan bekijken!

Je kunt overigens ook nog je XML als het een bepaalde structuur heeft in een relationele tabel om zetten. Ik dacht dat Visual Studio ook zo'n optie heeft voor xml files.

[Alarmnummer]

flowerp schreef op 19 september 2004 @ 14:11:
[...]
Daarom zij ik ook 'meestal', maar eigenlijk bedoelde ik SQL queries. Je hebt natuurlijk ook nog dingen als Xpath enzo die ook een beetje query achtig zijn. XQuery ken ik niet, dus voor ik te veel ga blaten hier zal ik dat eens gaan bekijken!

Het resultaat van een XQuery is een XPath.

Je kunt overigens ook nog je XML als het een bepaalde structuur heeft in een relationele tabel om zetten. Ik dacht dat Visual Studio ook zo'n optie heeft voor xml files.

Maar wat is dan nog de toegevoegde waarde van XML?

[flowerp]

Alarmnummer schreef op 19 september 2004 @ 14:16:
[...]

Het resultaat van een XQuery is een XPath.

Weer wat geleerd. Ik heb met de MS DOM parser wel eens van die select dingen opgeschreven als alle knopen waarvan een (grant) parent een X is waar de gezochte knoop het attribuut Y met de waarde Z heeft. Dat komt aardig query achtig over. Ik heb er te weinig verstand van om echt gefundeerde uitspraken over te doen (slechts 1 maal mee gespeeld), maar het leek me dat het toch niet helemaal hetzelfde is als wat je met een SQL query kan doen, zoals subselects en joins etc. Natuurlijk is de data structuur ook geheel anders (table vs tree), dus iha gaat een vergelijking niet helemaal op.

Als ik het fout heb hoor ik dat natuurlijk graag.

Maar wat is dan nog de toegevoegde waarde van XML?

Twijfelachtig. XML is IMHO in de eerste instantie een taal voor machine 2 machine communication, met als prettige eigenschap dat het human readable is. Een voordeel van een table als XML opslaan zou kunnen zijn dat dit format dus leesbaarder is. Hoe een DMBS zijn tables opslaat staat natuurlijk nergens gespecificeerd en is puur een interne aangelegenheid. Met een XML format zou je makkelijker andere tools kunne schrijven die direct op de table werken, of deze desnoods met de hand bewerken voor 'vieze' refactoring acties (bv een global replace van *henk* naar *piet* ofzo) die niet direct door het DBMS gesupport worden.

Soms is het moeilijk waar je de grens trekt. Het opslaan van bv een Word document in een XML formaat is wel goed (andere apps kunnen dan makkelijker dit formaat lezen), en een Excel sheet (met veel data) zou ook nog kunnen, maar een DB uit een relational db zou dan weer niet kunnen (in principe is de specificieke DB de enige die de data zou mogen benaderen).

[Kwistnix]

Alarmnummer schreef op 19 september 2004 @ 13:35:
[...]

*kuch* XQuery *kuch*


[...]

Ik zou trouwens sowieso niet gaan voor XML. XML is niet gemaakt voor dataopslag maar voor data uitwisseling/transformatie. Databeestjes zijn nog steeds het beste ervoor.

Ja, maar voor een simpele logfile gelijk een database gebruiken?
Persoonlijk vind ik dat een beetje overkill
Ik gebruik daar altijd flatfiles voor, tenzij mijn applicatie al van een DB gebruik maakt.

Maar je hebt natuurlijk gelijk. Het log dat de TS bedoelt is geen applicatie logfile.
In zijn geval is een database m.i. ook het handigst.

[ Voor 12% gewijzigd door Kwistnix op 19-09-2004 17:24 ]

[Alarmnummer]

FallenAngel666 schreef op 19 september 2004 @ 17:17:
[...]
Ja, maar voor een simpele logfile gelijk een database gebruiken?
Persoonlijk vind ik dat een beetje overkill

Niet als je HSQLDB gebruikt. Dat is echt extreem lightweight. Je hoeft niets te installeren... alleen een jar in je classpath en een paar config bestanden (2 stuks)... that is it .

[Kwistnix]

Alarmnummer schreef op 19 september 2004 @ 17:23:
[...]

Niet als je HSQLDB gebruikt. Dat is echt extreem lightweight. Je hoeft niets te installeren... alleen een jar in je classpath en een paar config bestanden (2 stuks)... that is it .

Dat moet ik dan eens bekijken. Heb er nog nooit van gehoord.

_{Had trouwens net m'n vorige post gewijzigd. Je bent te snel}

[ Voor 10% gewijzigd door Kwistnix op 19-09-2004 17:25 ]