[java] java.io ziekte: overdesign.

[Alarmnummer]

Ik heb me net weer eens gruwelijk lopen ergeren aan java.io. Het principe erachter snap ik (je maakt namelijk een aaneenschakeling van allerlei streams), maar in de praktijk komt het erop naar dat de gemiddelde professional (die niet dagelijks met IO werkt) er niet mee kan werken. Je hebt heel vaak dat je bij A bent. en je moet bij B uitkomen... en je zit zo van ok... wat gaan we nu weer proberen om van A naar B te komen.

Dit is niet alleen mijn ervaring maar ik hoor het veel vaker. Java io heeft voor mij een volslagen onwerkbare api en ik zou met veel plezier de makers ervan onderuit willen schoffelen met hun overgecompliceerde en onwerkbaar overdesign ellende.

Java IO is zeer onprettig om mee te werken.

Wie deelt deze mening met mij?

[edit]
Een mogelijke manier om gecompliceerde nare systemen toch beter mee te maken om mee te werken is door een of meerdere facades op te zetten en daarin de veel gebruikte opties in te zetten zoals: ReadFileAsString. Waarom mist dit soort functionaliteit?

[ Voor 22% gewijzigd door Alarmnummer op 16-12-2004 12:29 ]

[TlighT]

Ik denk dat je in ieder geval verschil moet maken tussen het principe en de uitvoering. Het principe van streams is prachtig. De uitvoering zoals in de Java API zou een redesign kunnen gebruiken maar meer vanwege een aantal inconsistenties en niet vanwege de achterliggende gedachte.

Het toevoegen van utility/helper classes zoals ReadFileAsString vind ik meer iets voor bijvoorbeeld Jakarta Commons dan dat het in de API thuishoort.

[Onno]

Voor simpele dingen oogt het onnodig complex ja, gewoon even een bestandje lezen ofzo. Maar het heeft zoveel voordelen dat ik het echt niet zou willen missen. Je zult alleen even moeten omschakelen van het denken in bestanden naar het denken in streams. Streams zijn zoveel krachtiger en schaalbaarder dan dingen als 'ReadFileAsString'. Wil je ook een aparte functie voor ReadGZippedFileAsString'? ReadEntryFromTarFileAsString? ReadAutomatischGegenereerdeOutputVanEenAnderOnderdeelAlsString? (en voor grote en/of blocking input is als string inlezen sowieso al geen serieuze optie meer)

Het is juist een enorm voordeel dat je al die objecten aan elkaar kunt vastknopen en op een generieke manier kunt benaderen. Ik heb wel eens code moeten maken die afhankelijk van instellingen dingen naar een email, naar een bestand, of over gegzipt een socket moet sturen. Dat is juist door deze opzet in Java extreem simpel te doen, en je code kan zo generiek mogelijk blijven. Zelfde geldt voor belangrijke dingen als bijvoorbeeld karakterset-vertalingen, enz. Elke stream kun je op een generieke manier als elke karakterset lezen/schrijven. Of je input nou uit een bestand, het geheugen, een socket, of wat dan ook komt. Zonder dat je eerst alles als string inleest, en daarna gaat gunzippen, en daarna de tekenset gaat omzetten. (vreet resources en kost meer tijd)

Met functies als ReadFileAsString beperk je je ook nog eens tot een hele specifieke vorm van input, namelijk een bestand. Ik schrijf liever code die 'input' gebruikt, maar zich verder niet beperkt tot een bepaalde vorm.

* Onno java.io.*

[Bobco]

TlighT schreef op donderdag 16 december 2004 @ 12:50:
[...]
Het toevoegen van utilities/helper classes zoals ReadFileAsString vind ik meer iets voor bijvoorbeeld Jakarta Commons dan dat het in een API thuishoort.

Daar ben ik het wel mee eens. Als je de API bekijkt is eigenlijk alles wel aanwezig wat je normaal gesproken nodig kan hebben, wat dat betreft ben ik nog nooit iets tegengekomen waarvan ik vind dat het echt ontbreekt. Het is eerder dat enorme oerwoud aan classes dat de boel onoverzichtelijk maakt. Een goede beschrijving van hoe je de ene op de andere kunt stapelen is wel iets handiger dan door de API JavaDoc klikken.

Het lastige aan de opzet is wel dat je behoorlijk wat objecten nodig hebt voordat je precies dat hebt wat je wilt hebben. Een utility class die meteen een ISO-8859-1 encoded String kan fabriceren uit een UTF8 gecodeerde file kan zeker z'n toepassingen hebben, maar dit zijn zaken die je relatief simpel met de geboden API kan realiseren. Overigens zijn er al redelijk wat van dat soort functies in Commons IO terug te vinden.

[-FoX-]

Dat is het probleem een beetje die ikzelf ook met Java heb. Sommige dingen gaan gewoon te ver. Mede dankzij de grote bedrijven die Sun waarschijnlijk "gevraagd" hebben voor dergelijke API implementaties.

Nog zo'n voorbeeld van overdesign is de Date class. Alle mogelijke bewerkingen zijn mogelijk, maar om een simpel Datum-formaat er uit te slopen, moet je allerlei gekke helperclasses (GregorianCalendar) erbij gaan slepen..

[Infinitive]

Je hebt toch al shortcuts zoals FileReader e.d.?
Nu geef ik toe dat ik meestal ook wel het een en ander aan utility classes hebt omdat bepaalde handelingen zo omslachtig zijn om op te schrijven.

[Alarmnummer]

TlighT schreef op donderdag 16 december 2004 @ 12:50:
Ik denk dat je in ieder geval verschil moet maken tussen het principe en de uitvoering. Het principe van streams is prachtig. De uitvoering zoals in de Java API zou een redesign kunnen gebruiken maar meer vanwege een aantal inconsistenties en niet vanwege de achterliggende gedachte.

Het werken met decorators om functionaliteit toe te voegen is aan 1 kant wel leuk, maar vanuit praktisch oogpunt zou het beter werkbaar moeten zijn.

Het toevoegen van utility/helper classes zoals ReadFileAsString vind ik meer iets voor bijvoorbeeld Jakarta Commons dan dat het in de API thuishoort.

Ben ik gedeeltelijk met je eens. Als ik een api schrijf verwacht ik dat anderen daar eenvoudig mee kunnen werken en daarom maak ik bv een facade als het nodig is om een complex subsysteem toch eenvoudig toegankelijk te maken. Die verplichting heeft iedereen die een api maakt en sun Dito. Soms doen ze het wel aardig (bv Collections, SwingUtilities) maar bij Java io is het echt maar een rommeltje.

[Sjaaky]

Het echte probleem is volgens mij niet dat het design te ingewikkeld is. Het probleem dat het design en de manier waarop je ermee dient te werken niet uit de javadocs is te destileren. Om erachter te komen hoe je verschillende klassen aan elkaar koppelt kun je of alle klassen gaan bekijken in de javadocs. Maar dat is veel werk en biedt geen garantie voor de beste oplossing. Wat ik meestal doe ik zoeken naar een stukje voorbeeldcode. Voor de dingen die ik nodig heb is dat meestal voldoende. Als het ingewikkelder wordt en er geen voorbeeldcode te vinden is via bijv google. Tja dan wordt het idd lastig.

Ik heb een keer zitten stoeien met java midp op mijn nokia, waar je een connectie op deze manier opent:

Java:

javax.microedition.io.HttpsConnection 
   con = (javax.microedition.io.HttpsConnection)
      javax.microedition.io.Connector.open(https://www.host.com/blah");

Dat had ik ook niet verzonnen na een tijdje door de javadocs te hebben gebrowst. Daar heb je echt een voorbeeldje voor nodig.

[Alarmnummer]

Sjaaky schreef op donderdag 16 december 2004 @ 13:47:
Het echte probleem is volgens mij niet dat het design te ingewikkeld is. Het probleem dat het design en de manier waarop je ermee dient te werken niet uit de javadocs is te destileren. Om erachter te komen hoe je verschillende klassen aan elkaar koppelt kun je of alle klassen gaan bekijken in de javadocs. Maar dat is veel werk en biedt geen garantie voor de beste oplossing. Wat ik meestal doe ik zoeken naar een stukje voorbeeldcode. Voor de dingen die ik nodig heb is dat meestal voldoende. Als het ingewikkelder wordt en er geen voorbeeldcode te vinden is via bijv google. Tja dan wordt het idd lastig.

Ik heb een keer zitten stoeien met java midp op mijn nokia, waar je een connectie op deze manier opent:

Java:

javax.microedition.io.HttpsConnection 
   con = (javax.microedition.io.HttpsConnection)
      javax.microedition.io.Connector.open(https://www.host.com/blah");

Dat had ik ook niet verzonnen na een tijdje door de javadocs te hebben gebrowst. Daar heb je echt een voorbeeldje voor nodig.

Als je continue moet gaan zoeken naar fragmenten met code om maar iets voor elkaar te krijgen, dan is er toch iets misgegaan met het ontwerp van een api. En ja.. Java IO kan veel.. maar als 9 van de 10 standaard ontwikkelaars er niet mee uit de voeten kunnen, dan had het net zo goed weinig kunnen doen want uiteindelijk werkt het onprettig/niet

Ik moet ook eerlijk toegeven dat IO niet een van de api`s is waar ik echt in thuis ben.

En verder vind ik de praktische toepasbaarheid van een api net zo belangrijk als de mogelijkheden die het heeft. Ik heb zelfs nog liever een api die minder mogelijkheden heeft dan een die onpraktisch in het gebruik is.

[ Voor 8% gewijzigd door Alarmnummer op 16-12-2004 13:55 ]

[Bobco]

-FoX- schreef op donderdag 16 december 2004 @ 13:08:
Nog zo'n voorbeeld van overdesign is de Date class. Alle mogelijke bewerkingen zijn mogelijk, maar om een simpel Datum-formaat er uit te slopen, moet je allerlei gekke helperclasses (GregorianCalendar) erbij gaan slepen..

Dat ben ik niet met je eens. De geschiedenis van de kalender is lang en complex, en wil je op een verantwoorde manier met datums over een langere periode dan de 2 eeuwen om de huidige datum kunnen rekenen dan kom je al snel op dit soort oplossingen. Ik vind het zelf getuigen van goed ontwerp dat er bijvoorbeeld een mogelijkheid is om de overgangsdatum van de Juliaanse naar de Gregoriaanse kalender in te stellen. Deze is namelijk verschillend voor verschillende landen. Als je software schrijft voor internationaal gebruik dan vind ik dat getuigen van een vooruitziende blik. Als je de JavaDoc van GregorianCalendar leest dan zie je meteen dat er aan heel veel is gedacht. Dat bevordert misschien niet de ease-of-use, maar wel de algemene bruikbaarheid.

[Bobco]

Alarmnummer schreef op donderdag 16 december 2004 @ 13:51:
[...]
Als je continue moet gaan zoeken naar fragmenten met code om maar iets voor elkaar te krijgen, dan is er toch iets misgegaan met het ontwerp van een api. En ja.. Java IO kan veel.. maar als 9 van de 10 standaard ontwikkelaars er niet mee uit de voeten kunnen, dan had het net zo goed weinig kunnen doen want uiteindelijk werkt het onprettig/niet

Ik denk dat je dit wel een beetje scherp stelt. Hoe vaak schrijf je nu I/O code van scratch? Over het algemeen hoef je dit soort zaken maar 1 keer uit te zoeken en de volgende keer weet je het of gebruik je een code snippet van een vorig project. Die eerste keer uitzoeken kan frustrerend zijn, zeker, maar dat is de prijs die je betaalt voor de flecibiliteit en algemene toepasbaarheid die door Onno werd bejubeld.

9 van de 10 standaard Java ontwikkelaars moeten er naar mijn idee wel mee uit de voeten kunnen, al heb je soms wel even een kladpapiertje nodig om te bepalen hoe je een BufferedReader krijgt die leest uit een String....

[Alarmnummer]

Bobco schreef op donderdag 16 december 2004 @ 14:05:
[...]
Ik denk dat je dit wel een beetje scherp stelt. Hoe vaak schrijf je nu I/O code van scratch?

Niet vaak.. maar voor die enkele keer dat het gebeurt is het iedere keer van.. ik ben bij A...en ik moet bij Z uitkomen... En dan is het beetje combineren om van A naar zet te komen. Beetje een doolhof probleem... ohh dood pad.. nieuwste regel weg.. andere combinatie... ook weer dood pad? ok. nog een regel terug... weer een nieuwe combinatie.

En dat stoort mij dus mateloos.

Over het algemeen hoef je dit soort zaken maar 1 keer uit te zoeken en de volgende keer weet je het of gebruik je een code snippet van een vorig project. Die eerste keer uitzoeken kan frustrerend zijn, zeker, maar dat is de prijs die je betaalt voor de flecibiliteit en algemene toepasbaarheid die door Onno werd bejubeld.

TJa.. mijn motto is "don`t pay for what you don`t use" en als ik nooit die complexiteit nodig ben van IO wil ik er ook niet voor betalen. Uitzoeken kost tijd..tijd kost geld.

[ Voor 10% gewijzigd door Alarmnummer op 16-12-2004 14:36 ]

[Verwijderd]

Ik vind het juist heerlijk werken, ik snap ook niet helemaal probleem, want methodes als readline bestaan toch gewoon en het is toch aan jou om de juiste encoding etc erin te hangen? Het enige waar ik me aan stoor is het verplicht opvangen van Exceptions. dat had naar mijn mening niet nodig geweest.

[Alarmnummer]

Verwijderd schreef op donderdag 16 december 2004 @ 14:51:
Ik vind het juist heerlijk werken, ik snap ook niet helemaal probleem, want methodes als readline bestaan toch gewoon en het is toch aan jou om de juiste encoding etc erin te hangen?

Ze bestaan wel maar in de praktijk heb je vaak A = File... B = String.. Hoe kom ik van File naar String. En dan moet je weer een hele zooi dingen proberen om van A naar B te komen. En dat stoort mij dus...

A C ... B nee.. lukt niet
A D E ... B nee.. lukt ook niet
A F H ... B nee.. lukt ook niet..

Het is gewoon een puzzel en daar ben ik schijtziek van.

Daarbij komt ook nog eens het feit dat de documentatie gewoon naad voor A B problemen is.

Het enige waar ik me aan stoor is het verplicht opvangen van Exceptions. dat had naar mijn mening niet nodig geweest.

Dat vind ik juist geen probleem doordat IO altijd iets is dat fout kan gaan, dus checked exceptions zijn noodzakelijk.

[ Voor 16% gewijzigd door Alarmnummer op 16-12-2004 15:00 ]

[Verwijderd]

Alarmnummer schreef op donderdag 16 december 2004 @ 14:58:
Dat vind ik juist geen probleem doordat IO altijd iets is dat fout kan gaan, dus checked exceptions zijn noodzakelijk.

Ah die kreten zocht ik, checked en unchecked
Tuurlijk, maar een NullPointer kan ook altijd optreden. Ik vind het in dit geval de keuze van de programmeur of hij/zij er wat mee doet. Misschien zijn de controlles allang uitgevoerd.


Maar ik weet niet hoor, echt spannend is het toch niet

code:

BufferedReader in = new BufferedReader(new FileReader("infilename"));
        String s;
        while ((s = in.readLine()) != null) {
            //bla die bla
        }
        in.close();

[Alarmnummer]

Verwijderd schreef op donderdag 16 december 2004 @ 15:11:
[...]

Ah die kreten zocht ik, checked en unchecked
Tuurlijk, maar een NullPointer kan ook altijd optreden. Ik vind het in dit geval de keuze van de programmeur of hij/zij er wat mee doet. Misschien zijn de controlles allang uitgevoerd.

NullPointerException is een programmeerfout en daar wil je eigelijk nooit op checken. Een IOException is geen programmeerfout.. bv de arm van een hd is afgebroken... de cd is aan kapotgesprongen in de cdromdrive. Dat zijn dingen waar je niet op kan checken omdat het nog goed was toen je checkte... en 1 us erna is het kapot gegaan.

Maar ik weet niet hoor, echt spannend is het toch niet

code:

BufferedReader in = new BufferedReader(new FileReader("infilename"));
        String s;
        while ((s = in.readLine()) != null) {
            //bla die bla
        }
        in.close();

Als je het klaar hebt liggen valt het wel mee.. Maar als je achter iemand anders zijn pc zoiets in elkaar moet plakken zit je ook even zo van uhhh.. hoe moest het nog maar.

[Verwijderd]

Kom op Alarmnummer, na de eerste 5 keer weet je toch wel hoe je met een FileReader en een StringBuffer snel en efficient een bestand naar een string in kunt lezen

Maar dat neemt overigens niet weg dat ik het 100% met je eens ben dat de Java API hopeloos overgedesigned is. Neem bijvoorbeeld al die provider/consumer patterns (crypto, imageio etc)... leuk, maar voor 99,9% van de programmeurs is het gewoon overtollige ballast. Hetzelfde geldt voor de over-use van MVC in Swing... doe mij maar SWT... of liever PHP voor webapps

[Soultaker]

Het grote probleem met de Java I/O API is naar mijn mening dat simpele taken niet simpel uitgevoerd kan worden. De I/O API is wel krachtig en redelijk netjes ontworpen, en dat verdient alle lof, maar een echt goede library maakt (net als een goede programmeertaal) simpele taken simpel, en ingewikkelde taken mogelijk.

Sommige mensen reageerden hier dat het aanbieden van simpelere mechanismen betekent dat je ingewikkelde taken niet meer zou kunnen uitvoeren. Dat is natuurlijk de bedoeling niet, zoals Alarmnummer ook duidelijk aangeeft in zijn topic start. Feit is alleen dat je in de meeste gevallen simpele dingen wil doen (denk aan: regels tekst lezen uit een bestand) en het zou gewoon heel praktisch zijn als je dat met hele simpele code zou kunnen bereiken.

[Verwijderd]

Ik heb er eigenlijk nooit zoveel problemen mee gehad, maar je kunt ook gewoon de java tutorial induiken en de boel copiëren.
Kijk eens, eerste hit in de Java Tutorial en:

Java:

File inputFile = new File("farrago.txt");
    File outputFile = new File("outagain.txt");

        FileReader in = new FileReader(inputFile);
        FileWriter out = new FileWriter(outputFile);
        int c;

        while ((c = in.read()) != -1)
           out.write(c);

        in.close();
        out.close();

En je vindt er ook nog prachtige plaatjes :
CharacterStreams

Bytestreams

En dan is het ook nog eens platform onafhankelijk

Java roeleert

_{nee, layoutmanagers, die zijn pas mysterieus}

[Soultaker]

Oh ja, het onderscheid tussen Reader/Writer en InputStream/OutputStream maakt de zaken er ook een stuk helderder op.

[Verwijderd]

Ok, nou snap ik het zelf niet meer... Over overdesign gesproken... In het plaatje staat:

Writer -> OutputStreamReader -> FileWriter

Als iemand kan uitleggen wat het betekent ben ik al blij en als je me dan ook nog kunt vertellen waar het goed voor is dan

[TlighT]

Soultaker schreef op donderdag 16 december 2004 @ 17:15:
Oh ja, het onderscheid tussen Reader/Writer en InputStream/OutputStream maakt de zaken er ook een stuk helderder op.

Reader/Writer zijn voor character data (char[]), Inputstream/Outputstream zijn voor binaire data (byte[]). Een duidelijk en logisch onderscheid. Je had ze kunnen combineren maar dan had je allerlei ge-overloade methods gekregen, bijv. een read(byte[]) en een read(char[]) en dat had de boel een stuk complexer gemaakt terwijl je meestal maar 1 soort streams nodig hebt.

Verwijderd schreef op donderdag 16 december 2004 @ 17:23:
Writer -> OutputStreamReader -> FileWriter

Als iemand kan uitleggen wat het betekent ben ik al blij en als je me dan ook nog kunt vertellen waar het goed voor is dan

InputStreamReader en OutputputStreamWriter (bovenstaand plaatje is verkeerd, het is Writer -> OutputStreamWriter) fungeren als een soort brug tussen de character streams en de binairy streams, ze lezen chars in een bytestream en schrijven bytes naar een charstream.

[ Voor 19% gewijzigd door TlighT op 16-12-2004 18:23 ]

[Verwijderd]

Alarmnummer schreef op donderdag 16 december 2004 @ 13:51:
Als je continue moet gaan zoeken naar fragmenten met code om maar iets voor elkaar te krijgen, dan is er toch iets misgegaan met het ontwerp van een api.

Nee dan is er iets mis gegaan bij de programmeur en het klassificeren van objecten. Ik neem aan dat jij als programmeur wel zo handig bent om je code te hergebruiken. Dus je maakt een keer de klasse TextFile en je bent klaar. Dat de heren van Sun niet voor elk bestands type een Object in de standaard API stoppen lijkt me niet meer dan logisch en bovenal wenselijk.

[ Voor 21% gewijzigd door Verwijderd op 16-12-2004 18:08 ]

[Alarmnummer]

Verwijderd schreef op donderdag 16 december 2004 @ 18:08:
[...]
Nee dan is er iets mis gegaan bij de programmeur en het klassificeren van objecten.

Uhhh.. wat heeft klassificeren van objecten hier nou mee te maken? Documentatie is kut en er zijn geen facades. De api is kut om te gebruiken.

Ik neem aan dat jij als programmeur wel zo handig bent om je code te hergebruiken.

Als je copy paste acties moet ondernemen dan is er een probleem. Zie wederom mijn verhaal over facades.

Dus je maakt een keer de klasse TextFile en je bent klaar. Dat de heren van Sun niet voor elk bestands type een Object in de standaard API stoppen lijkt me niet meer dan logisch en bovenal wenselijk.

Fout... je moet zorgen dat je een api aanbied die prettig is om mee te werken ander kan niet iedereen er gebruik van maken. Daarom is het handig dat er een aantal handige methodes worden opgezet zodat 9 van de 10 programmeurs snel aan de slag kunnen zonder te verzanden in uitzoek werk. Sun moet zich beter realiseren dat tijd niet gratis is en dat brakke kut api`s onprettig zijn om mee te werken. Ik heb vaak de indruk dat Sun niet iets schrijft om in de praktijk te gebruiken maar puur om wat leuke specs op papier te krijgen. Sun is zo nu en dan flink out of touch met de praktijk.

[Verwijderd]

Alarmnummer schreef op donderdag 16 december 2004 @ 18:22:
[..]

Het komt mij nu over als de mening van een gefrustreerd persoon. De API van Java is gewoon netjes geklassificeerd en logischerwijs vallen dergelijke methodes/functies buiten de boot. De java API is er nou eenmaal geen een met "mysql_connect", en logisch want dat is niet netjes geklassificeerd. Dus klassificatie heeft alles te maken met jouw "probleem".

edit:
en over copy-pasten heb ik al helemaal niet gesproken. Copy paste heeft helemaal niets te maken met code hergebruiken.

[ Voor 15% gewijzigd door Verwijderd op 16-12-2004 18:29 ]

[TlighT]

Alarmnummer schreef op donderdag 16 december 2004 @ 18:22:
[...]

Fout... je moet zorgen dat je een api aanbied die prettig is om mee te werken ander kan niet iedereen er gebruik van maken. Daarom is het handig dat er een aantal handige methodes worden opgezet zodat 9 van de 10 programmeurs snel aan de slag kunnen zonder te verzanden in uitzoek werk. Sun moet zich beter realiseren dat tijd niet gratis is en dat brakke kut api`s onprettig zijn om mee te werken. Ik heb vaak de indruk dat Sun niet iets schrijft om in de praktijk te gebruiken maar puur om wat leuke specs op papier te krijgen. Sun is zo nu en dan flink out of touch met de praktijk.

Met brakke kut api doe je java.IO toch zeer tekort! Wat jij wilt zijn een stel classes bovenop java.IO die een aantal veelgebruikte taken vereenvoudigen. Dat betekent niet dat je java.IO kunt weggooien want er zijn een heleboel developers die de flexibiliteit van die API nodig hebben en die heb je gewoonweg niet zonder het gebruik van streams.

Dat streams handig zijn, wordt bevestigd doordat ze veel gebruikt worden: C++, Java, .NET, pipes in Unix maken allemaal gebruik van dit patroon.

[ Voor 9% gewijzigd door TlighT op 16-12-2004 18:39 ]

[Alarmnummer]

TlighT schreef op donderdag 16 december 2004 @ 18:28:
[...]
Met brakke kut api doe je java.IO toch zeer tekort!

Ik kijk er toch heel pragmatisch naar. JavaIO is idd heel krachtig en kan heel veel, maar in de praktijk is het vervelend te gebruiken. Oorzaak in dit geval is slechte documentatie en gebrek aan facades. Uiteraard... op object nivo en de achterliggende gedachte zijn allemaal goed.. maar een goeie architectuur moet een algemene guideline zijn om tot een goed eindpunt te komen. Schijnbaar mist er dus iets aan de huidige aanpak (gebrek aan documentatie/facades) waardoor ik niet het gevoel heb dat ik bij dat goeie eindpunt uitkom.

Alleen goed ontworpen software is niet voldoende om een goed te gebruiken stuk software te zijn.

[Alarmnummer]

Verwijderd schreef op donderdag 16 december 2004 @ 18:27:
[...]
Het komt mij nu over als de mening van een gefrustreerd persoon. De API van Java is gewoon netjes geklassificeerd

Het is geen frustratie van een eenmalige ervaring met IO. Het is altijd zo... En dat is dus het probleem. En meestal kom ik er met een copy paste actie wel een heel eind, maar toen ik achter iemand anders zijn bak moest kruipen realiseerde ik me eigelijk hoe onduidelijk het allemaal was.

Verder is het ook niet een klacht van mij alleen. Ik heb meer dan een gemiddelde kennis van Java maar het hele gezever met reader/writers/ in en outputstreams is irritant. Doe simpel.. gebruik streams of writers... of gooi zo in een aparte subpackage als ze conceptueel zo anders zijn.

en logischerwijs vallen dergelijke methodes/functies buiten de boot.

Nog maals.. Dat is niet zo. Facades zijn een onderdeel van een API. Dat IO deze facades mist is een tekortkoming aan de IO API. Facades zijn wel minder elementair want je kan zonder facade wel functies gebruiken, maar je kan zonder functies uiteraard geen facades gebruiken. Maar die facade is een essentieel onderdeel van het geheel.

Check trouwens Collections of SwingUtils eens. ALs je wilt kan ik je nog wel een paar van dat soort facades geven waarmee complexe subsystemen van buiten af veel eenvoudiger toegankelijk zijn.

De java API is er nou eenmaal geen een met "mysql_connect", en logisch want dat is niet netjes geklassificeerd.

Volgens mij snap je het niet helemaal. En ik snap ook eigelijk totaal niet wat je bedoelt met klassificeren.

en over copy-pasten heb ik al helemaal niet gesproken. Copy paste heeft helemaal niets te maken met code hergebruiken.

Nope.. maar het is wel iets dat zonder facades wel vaak gebeurt.

[ Voor 4% gewijzigd door Alarmnummer op 16-12-2004 19:34 ]

[Onno]

Alarmnummer schreef op donderdag 16 december 2004 @ 19:17:
Schijnbaar mist er dus iets aan de huidige aanpak (gebrek aan documentatie/facades) waardoor ik niet het gevoel heb dat ik bij dat goeie eindpunt uitkom.

Of er mist bij jou gewoon wat: een beetje inzicht in hoe het geheel werkt. Een API brak en kut noemen omdat je zelf telkens vergeet hoe het ook alweer in elkaar zit zegt niet per definitie wat over de API. Het kan aan beide kanten liggen.

Van alle dingen zijn er trouwens wel mensen die roepen dat ze onlogisch in elkaar steken; jaren terug heeft iemand (hoi Femme! ) hier bijvoorbeeld geroepen dat regexen onlogisch zijn. Nou kun je van ze roepen wat je wilt, maar je zult het toch wel met me eens zijn dat ze dat niet zijn. Het vereist gewoon een wat andere denkwijze dan je misschien van andere dingen gewend was, dat zegt verder niets over het design zelf.

Alarmnummer schreef op donderdag 16 december 2004 @ 19:24:
Verder is het ook niet een klacht van mij alleen. Ik heb meer dan een gemiddelde kennis van Java maar het hele gezever met reader/writers/ in en outputstreams is irritant. Doe simpel.. gebruik streams of writers... of gooi zo in een aparte subpackage als ze conceptueel zo anders zijn.

Het is niet irritant, het is een goed ontwerp. En het is ook een noodzaak als je met tekensets wilt werken. Ruwe invoer of uitvoer en karakterdata zijn al lang niet meer gelijk, zoals eeuwen geleden.. en je moet met beide overweg kunnen.

[ Voor 26% gewijzigd door Onno op 16-12-2004 19:29 ]

[Verwijderd]

Alarmnummer schreef op donderdag 16 december 2004 @ 19:24:
Volgens mij snap je het niet helemaal.

Jawel hoor Ik denk/vind alleen dat als je netjes klassificeert je het niet achter een facade kunt stoppen, dus daarmee ook vergelijking met Collections onzinnig.

heb je soms een beter idee/klassificatie?

[4VAlien]

De Java api is gewoon een vloek voor de beginner en een zegen voor de gevorderde gebruiker. Ik gebruik zelf zelden Java en daarom vermoed ik dat ik gewoon 90% van de API niet gebruik tenzij het absoluut noodzakelijk is. Ik programmeer een soort C stijl met gebruik van Vectors e.d. maar ik zou best de rest van de API willen gebruiken als ik er vaak mee zou werken. Het is wel zo dat ik de documentatie wat dat betreft wat minder vindt (in vergelijking met MSDN bijvoorbeeld).

[ Voor 5% gewijzigd door 4VAlien op 16-12-2004 19:35 ]

[Alarmnummer]

Onno schreef op donderdag 16 december 2004 @ 19:26:
Of er mist bij jou gewoon wat: een beetje inzicht in hoe het geheel werkt.

Ik begrijp de concepten maar al te goed (de hele architectuur achter pipes/filter/decorators/streams etc ben ik in thuis). Maar in de concrete Java IO minder. En het is ook geen api waar ik wekelijks mee in aanraking kom. Maar als ik er mee in aanraking kom dan is er eerst weer irritatie omdat je moet uitzoeken: hoe zat het ook al weer. Dan heb je het uitgezocht en het werk.. woei cool.. ik snap het. En 1 a 2 maand later kan je weer opnieuw beginnen.. hoe zat het ook al weer.. Welke classes moest in nou maar aan elkaar plakken om van A naar B te komen.

Een API brak en kut noemen omdat je zelf telkens vergeet hoe het ook alweer in elkaar zit zegt niet per definitie wat over de API. Het kan aan beide kanten liggen.

Java is een van de weinig api`s waar ik zoveel problemen mee heb.

Van alle dingen zijn er trouwens wel mensen die roepen dat ze onlogisch in elkaar steken; jaren terug heeft iemand (hoi Femme! ) hier bijvoorbeeld geroepen dat regexen onlogisch zijn. Nou kun je van ze roepen wat je wilt, maar je zult het toch wel met me eens zijn dat ze dat niet zijn. Het vereist gewoon een wat andere denkwijze dan je misschien van andere dingen gewend was, dat zegt verder niets over het design zelf.

De java io kan zeker een heel eind vereenvoudigd worden door bv dat hele Writer/Outputstream Reader/InputStream.

Het zal vast wel een doel hebben.. maar als het zo anders is... plaats het dan in een andere subpackage om mij part.

Het is niet irritant, het is een goed ontwerp. En het is ook een noodzaak als je met tekensets wilt werken. Ruwe invoer of uitvoer en karakterdata zijn al lang niet meer gelijk, zoals eeuwen geleden.. en je moet met beide overweg kunnen.

Ik heb ook geen problemen met de ideeen achter IO. Ik heb alleen problemen met de praktische uitvoering en het praktisch gebruik van de API. Check mijn verhaal over facades nog eens. Een API moet meer zijn dan alleen goed ontworpen classes.

[Onno]

Alarmnummer schreef op donderdag 16 december 2004 @ 19:43:
Ik begrijp de concepten maar al te goed (de hele architectuur achter pipes/filter/decorators/streams etc ben ik in thuis). Maar in de concrete Java IO minder.

Juist in de Java is de concrete API is vrijwel gelijk aan de concepten erachter. Daarom is het zo belangrijk dat je het verschil tussen ruwe data (zoals die bijvoorbeeld in een bestand staat of over een netwerksocket gaat) en karakterdata begrijpt. Als je dat inzicht hebt is er niets moeilijks meer aan en schud je de code met writers/readers en in-/outputstreams zo uit je mouw.

En het is ook geen api waar ik wekelijks mee in aanraking kom. Maar als ik er mee in aanraking kom dan is er eerst weer irritatie omdat je moet uitzoeken: hoe zat het ook al weer.

Dan moet je je het vaker gebruiken of je geheugen upgraden.

De java io kan zeker een heel eind vereenvoudigd worden door bv dat hele Writer/Outputstream Reader/InputStream.

..door dat hele gedoe te ....?

Check mijn verhaal over facades nog eens.

Ja, je vindt het kut omdat je niet zelf op de code kunt komen. Maar dat hoeft dus niets over de kwaliteit van de API te zeggen.

[Soultaker]

Onno schreef op donderdag 16 december 2004 @ 19:26:
Van alle dingen zijn er trouwens wel mensen die roepen dat ze onlogisch in elkaar steken; jaren terug heeft iemand (hoi Femme! ) hier bijvoorbeeld geroepen dat regexen onlogisch zijn. Nou kun je van ze roepen wat je wilt, maar je zult het toch wel met me eens zijn dat ze dat niet zijn. Het vereist gewoon een wat andere denkwijze dan je misschien van andere dingen gewend was, dat zegt verder niets over het design zelf.

Reguliere expressies worden dan ook vaak gebruikt waar ze helemaal niet zinnig/praktisch zijn. Het is vaak veel handiger om een probleem op te splitsen in een aantal simpele operaties (strings splitsen, karakters vervangen, enzovoorts) dan om een monsterlijke reguliere expressie te schrijven waarvan je weliswaar wiskundig kunt bewijzen dat hij hetzelfde doet, maar die niemand zomaar weg kan lezen, en die je alleen met pijn, moeite en door heel veel experimenteren precies goed kan krijgen.

Wat dat betreft gaat de vergelijking die Alarmnummer maakt met de Java I/O wel op: je kunt een beetje reguliere expressie niet in één keer goed schrijven, maar moet er oneindig mee klooien voordat het goed werkt. Dat is helemaal niet handig.

[Verwijderd]

In het verlengde daarvan zou SQL ook onzinnig zijn.

[Soultaker]

Verwijderd schreef op donderdag 16 december 2004 @ 20:39:
In het verlengde daarvan zou SQL ook onzinnig zijn.

Kun je dat even toelichten? Ik snap echt niet hoe dat in deze discussie past.

[Verwijderd]

Soultaker schreef op donderdag 16 december 2004 @ 21:01:
Kun je dat even toelichten? Ik snap echt niet hoe dat in deze discussie past.

Jou argumenten over reguliere expressies zijn ook op SQL statements toe te passen. Dat was het punt.

[Soultaker]

Het is met SQL juist vaak makkelijker om een enkele taak met een enkele query te doen. Je kunt dan veel makkelijker garanderen dat het resultaat klopt en je krijgt atomiciteit kado. Bovendien is een enkele complexe query helderder dan een aantal afzonderlijke queries, waarbij je client-side datastructuren en algoritmen combineert met SQL queries en temporary tables.

Mijn punt met reguliere expressies was dat als je twee reguliere expressie wil combineren, die complexer wordt dan de afzonderelijke expressies. Met SQL is dat bijna nooit zo. Bijvoorbeeld data selecteren, sorteren en groeperen is hardstikke makkelijk in een enkele query.

[Kwistnix]

Ik vind persoonlijk java.io ook niet het toppunt van ideaal om mee te werken.
Ik weet dat streams voor binary data geschikt zijn en readers / writers specifiek voor tekst data bedoeld zijn. Er zijn alleen zo ontzettend veel wrappers in java.io waardoor ik op een gegeven moment door de bomen het bos niet meer zie en dan zit ook alles nog eens bij elkaar / door elkaar in één package.
Vervolgens werkt de een met Strings en de ander met URL's en weer een ander met URI's die je dan allemaal door elkaar kan gaan gebruiken. Daar wordt je dus compleet gestoord van. Het is in ieder geval niet mijn favoriete bezigheid.

[maartenba]

Het is fijn dat je voor zowat alle types IO dezelfde klassen kan gebruiken, juist daarom is die IO in Java zo krachtig.
Maar wie houdt je tegen om, voor veelvuldig gebruik van bv. schrijven van tekstfiles, je eigen Facade op te gaan zetten?

[Verwijderd]

Soultaker schreef op donderdag 16 december 2004 @ 21:37:
Het is met SQL juist vaak makkelijker om een enkele taak met een enkele query te doen. Je kunt dan veel makkelijker garanderen dat het resultaat klopt en je krijgt atomiciteit kado. Bovendien is een enkele complexe query helderder dan een aantal afzonderlijke queries, waarbij je client-side datastructuren en algoritmen combineert met SQL queries en temporary tables.

Mijn punt met reguliere expressies was dat als je twee reguliere expressie wil combineren, die complexer wordt dan de afzonderelijke expressies. Met SQL is dat bijna nooit zo. Bijvoorbeeld data selecteren, sorteren en groeperen is hardstikke makkelijk in een enkele query.

Dat is enkel gebaseerd op je eigen ervaring, niet op argumenten. Jij vindt het immers makkelijker lezen. Neemt niet weg dat het principe hetzelfde blijft. Dan is het eigelijk mooi dat je ongefundeerd vindt dat reguliere expressies wil gesplitst moeten worden en SQL statements niet. Het haalt namelijk je betoog onderuit over de reguliere expressies.

Zo zie je maar dat ook de vergelijking met Alarmnummer zodoende niet op gaat.

En zoals nu al meerdere malen geopperd, wat let je om zelf die specifieke klasses te schrijven?

[Soultaker]

Verwijderd schreef op donderdag 16 december 2004 @ 21:45:
Dat is enkel gebaseerd op je eigen ervaring, niet op argumenten.

Inderdaad. Het gaat namelijk niet over theoretische beperkingen, maar om praktisch, effectief programmeren. De enige manier om praktisch programmeren te toetsen is om ervaringen in de praktijk te evalueren (en niet alleen de mijne, natuurlijk). Ik zie niet in wat er slecht is aan het beoordelen van techniek op basis van je ervaringen ermee.

Dan is het eigelijk mooi dat je ongefundeerd vindt dat reguliere expressies wil gesplitst moeten worden en SQL statements niet. Het haalt namelijk je betoog onderuit over de reguliere expressies.

Als ik een mening baseer op ervaring, is dat niet ongefundeerd. Als je wat topics op GoT nazoekt kom je talloze voorbeelden tegen die mijn punt ondersteunen.

En zoals nu al meerdere malen geopperd, wat let je om zelf die specifieke klasses te schrijven?

Als je zelf klasses moet toevoegen om een werkbare basislibrary te krijgen, dan schiet de standaard library blijkbaar tekort. Dat was ook het punt van Alarmnummer. (Dat geldt natuurlijk niet voor elk klein dingetje dat je maar kunt verzinnen, maar als je jouw argument volgt dan is elke standaard library perfect, omdat je zelf altijd wel wat beters kan schrijven als iets je niet bevalt.)

[Verwijderd]

Sjaaky schreef op donderdag 16 december 2004 @ 13:47:

Ik heb een keer zitten stoeien met java midp op mijn nokia, waar je een connectie op deze manier opent:

Java:

javax.microedition.io.HttpsConnection 
   con = (javax.microedition.io.HttpsConnection)
      javax.microedition.io.Connector.open(https://www.host.com/blah");

Dat had ik ook niet verzonnen na een tijdje door de javadocs te hebben gebrowst. Daar heb je echt een voorbeeldje voor nodig.

Je declareert een variabele en roept de open functie aan. Zo ingewikkeld is dat toch niet? Je moet even weten wat je aan het doen bent (en in het geval van MIDP welke connectietypen ondersteund worden) maar dan is het heel simpel om tussen een http, https, bluetooth, sms of socket connectie te wisselen. Heb je de structuur door, is het heel algemeen toepasbaar. Snap je niet waar je mee bezig bent: Koop een boek waarin het uitgelegd wordt.

Je kan alles wel terugbrengen naar het niveau van visual basic maar dan krijg je vanzelf de problemen dat een hoop zaken opeens niet meer kunnen of onlogisch gebruikt worden. Liever een consequente api dan een simpele api waar niets mee kan.

[Verwijderd]

En inderdaad, niemand houd je tegen zelf een facade te schrijven wat een mooi tussenpositie neemt tussen jouw systeem en de Java.io. Misschien dat wanneer je hem heel algemeen kunt schrijven, Sun hem wel van je wilt overnemen

[Verwijderd]

Helaas deel ik je mening deze keer niet Momenteel werk ik aan een project, hiervoor maken we gebruik van sockets (java.net) en io (java.io) deze combinatie werkt perfect. Het wegschrijven van gehele objecten naar een filestream voor simpele datastorage en het schrijven van stringetjes over sockets werkt perfect.

[Sjaaky]

Tuurlijk is de code niet ingewikkeld als je hem zo ziet staan. Als je het maar een keer gezien hebt. Als ik een datagramconnection wil (ik zocht eigenlijk op udp, maar dan kom je niet ver) en ik ga naar datagramconnection kom ik niet te weten dat ik het ding met een connector moet maken. Bovendien was het een interface. Een interface die read en write methods declareert, maar zonder open method. Dus ging ik op zoek naar een datagramconnection class, die was er niet (niet in mijn documentatie althans). Dus hoe moest ik nu een datagramconnection maken? Alles wat ik tegen was gekomen was een interface.
Na rondgeblader in de docs blijkt dat bij httpconnection wel een redelijk duidelijk verhaal staat over de Connector. Bovendien staat er nergens dat Connector een zogenaamde factory is. Als ze met patterns in het achterhoofd designen, kunnen ze toch ook wel zeggen dat Connector een factory is? Is het meteen herkenbaar voor de programmeurs die weten wat een factory is.

Er is in de documentatie ook niet te vinden welke protocols het ondersteunt (zoals jij ook al zei). Bij Connector staat als enig voorbeeld http, maar ik kon ook nog sms en datagram gebruiken. Dat ik sms kon gebruiken zag ik ergens op internet. Maar in de javadocs stond het niet. Het lijkt me logisch dat de Connector zelf aangeeft welke protocols het ondersteunt.

Een factory zoals Connector is idd heel makkelijk om te gebruiken (als je het eenmaal weet). Ik zie de voordelen er ook wel van in. Maar waarom kan ik dan niet daarnaast ook een datagramconnection met de hand aanmaken? Die concrete class moet bestaan, anders kan de Connector hem ook niet aanmaken. Maar in de documentatie staat hij niet en het had mij een hoop gezoek gescheeld. Als ik later meer flexibiliteit had gewild en de Connector had gekend, had ik de code zonder veel moeite aan kunnen passen.

Dat je een api pas kunt gebruiken na het lezen van een boek is juist het probleem. Ik wil dat boek niet lezen. Ik ken de principes rondom networking en heb dat ook in diverse talen geprogrammeerd, waarom moet ik dan voor dit soort dingen een boek nodig hebben? Ik wil alleen weten hoe ze de classes en methods in deze taal hebben genoemd. En hoe het design in elkaar zit, maar dat volgt niet uit de javadocs.

Wat mij betreft is het manco dus vooral de documentatie. Ik hoop dat dat in nieuwere versies van midp verbeterd is, maar ik heb er al een tijdje niet meer naar gekeken.
Documentatie schrijven (voor mijn eigen code) vind ik ook lastig, want ik weet hoe het design in elkaar zit en beschouw dat meestal als logisch. Ik heb dus geen aanleiding om echt veel uit te leggen. Eigenlijk zou je dus moeten kijken hoe een andere programmeur de documentatie benadert en vanuit daar duwtjes de goede kant op moeten geven. Dat iedereen documentatie anders benadert omdat ze een andere achtergrond hebben maakt het extra lastig.
Het nadeel van een tutorial of een boek is vaak dat ze weer bij het begin beginnen. Je bent veel tijd kwijt met het doorlezen van dingen die je al weet omdat er soms toch net die aanwijzing tussen staat die je nodig hebt.

Tot zover mijn rant op de documentatie van networking in de midp in de nokia 3410 sdk van meer dan een jaar geleden. Was eigenlijk niet mijn tijd waard, maar frustratie moet je ergens kwijt.

[Verwijderd]

Sjaaky schreef op vrijdag 17 december 2004 @ 15:17:
Er is in de documentatie ook niet te vinden welke protocols het ondersteunt (zoals jij ook al zei). Bij Connector staat als enig voorbeeld http, maar ik kon ook nog sms en datagram gebruiken. Dat ik sms kon gebruiken zag ik ergens op internet. Maar in de javadocs stond het niet. Het lijkt me logisch dat de Connector zelf aangeeft welke protocols het ondersteunt.

Midp 1.0 ondersteund alleen http. (PUNT) de rest is optioneel. (Staat in de handleiding )

Dat je een api pas kunt gebruiken na het lezen van een boek is juist het probleem. Ik wil dat boek niet lezen. Ik ken de principes rondom networking en heb dat ook in diverse talen geprogrammeerd, waarom moet ik dan voor dit soort dingen een boek nodig hebben?

Misschien omdat je wilt weten hoe het in een taal werkt? Ik weet vrij goed hoe ik een conversatie in het Nederlands moet voeren, maar de gebruiken in zimbabwe? Geen flauw idee, misschien toch eens een reisgids raadplegen......