[JAVA] Meerdere keren replaceAll?

[dôh]

Ik zit met het volgende issue. Ben zelf een totale programmeer noob, heb een aantal jaar terug wel wat Java gehad, maar ben het meeste kwijt. Eerlijkgezegd wil ik het ook zo houden, maar er is één dingetje wat ik niet op kan lossen.

Het is volgens mij vrij simpel, maar mijn kennis is van een zodanig niveau dat ik het niet voor elkaar krijg.

Ik gebruik een html parser die info van IMDB trekt. Het probleem zit hem in het parsen van de titel. Wanneer daar een 'speciaal' karakter in zit, dan krijg ik vreemde tekens. Zie;

Fast & Furious (2009)

Het stukje code wat hiervoor verantwoordelijk is, is het volgende;

code:

_title = htmlToString(_title);

Nu gaf iemand mij de suggestie om het karakter te vervangen door het stukje code te veranderen door deze;

code:

_title = _title.replaceAll("&", "&");

Dit werkt perfect! Echter bij karakters als " en ' etc. gaat hij weer de mist in. Hoe kan ik nu meerdere "replaceAlls" toevoegen, zodat ook de andere karakters vervangen worden?

Zelfs had ik iets als dit in mijn gedachten;

code:

_title = _title.replaceAll("%", "%");
_title = _title.replaceAll("&", "&");
_title = _title.replaceAll("'", "'");
_title = _title.replaceAll("+", "+");
_title = _title.replaceAll("&#x3c;", "<");
_title = _title.replaceAll("&#x3e;", ">");

Alleen hoe implementeer ik dit in de code? Hoe doe ik meerdere tekens vervangen?

Alvast bedankt!

[_Erikje_]

een map aanmaken met de replacement values en dan een loopje schrijven die de acties uitvoert.

[pedorus]

dôh schreef op woensdag 23 september 2009 @ 18:01:
Ik gebruik een html parser die info van IMDB trekt. Het probleem zit hem in het parsen van de titel. Wanneer daar een 'speciaal' karakter in zit, dan krijg ik vreemde tekens.

Het lijkt me dan toch eigenlijk dat je geen goede html-parser hebt... En geloof me, er zijn vast goede html-parsers voor Java te vinden, dat wiel zou ik niet opnieuw gaan uitvinden..

[ Voor 13% gewijzigd door pedorus op 23-09-2009 18:16 ]

[.oisyn]

dôh schreef op woensdag 23 september 2009 @ 18:01:
Zelfs had ik iets als dit in mijn gedachten;

code:

_title = _title.replaceAll("%", "%");
_title = _title.replaceAll("&", "&");
_title = _title.replaceAll("'", "'");
_title = _title.replaceAll("+", "+");
_title = _title.replaceAll("&#x3c;", "<");
_title = _title.replaceAll("&#x3e;", ">");

Alleen hoe implementeer ik dit in de code? Hoe doe ik meerdere tekens vervangen?

Wat werkt daar niet aan dan? Afgezien van het feit dat dat een compleet verkeerde aanpak is omdat je feitelijk alle unicode codepoints om wilt kunnen zetten en er ook nog eens verschillende manieren zijn om hetzelfde codepoint te representeren met een character reference.

Wat je moet doen, *als* je het zelf wilt implementeren wat je sowieso niet wilt aangezien daar zat libraries voor bestaan (wellicht zelfs standaard functionaliteit in de Java API?), is teken voor teken door de string lopen, en als je een & tegenkomt kijken wat er tussen de & en de ; staat, en controleren of dat een bestaande entity of valide character code is, en zo ja dat ding omzetten.

[ Voor 3% gewijzigd door .oisyn op 23-09-2009 18:27 ]

[Sv3n]

Ik denk dat dit je wel kan helpen

http://commons.apache.org/lang//api/org/apache/commons/lang/StringEscapeUtils.html#unescapeHtml(java.lang.String)

[ Voor 29% gewijzigd door Sv3n op 23-09-2009 18:38 ]

[pedorus]

.oisyn schreef op woensdag 23 september 2009 @ 18:27:
Wat je moet doen, *als* je het zelf wilt implementeren wat je sowieso niet wilt aangezien daar zat libraries voor bestaan (wellicht zelfs standaard functionaliteit in de Java API?), is [...]

Tuurlijk is er standaard-functionaliteit, hoewel die helaas met een callback-achtige structuur werkt en wat andere bugs heeft, en daarnaast het je natuurlijk tal van alternatieven.

[.oisyn]

pedorus schreef op woensdag 23 september 2009 @ 18:38:
[...]

Tuurlijk is er standaard-functionaliteit

Ik had het specifiek over het parsen van HTML character references, waar de TS momenteel meer aan heeft aangezien dat voor hem de kleinste wijziging aan z'n code oplevert, maar goed

[ Voor 15% gewijzigd door .oisyn op 23-09-2009 18:41 ]

[pedorus]

.oisyn schreef op woensdag 23 september 2009 @ 18:40:
[...]

Ik had het over het parsen van HTML character references, waar de TS momenteel meer aan heeft aangezien dat voor hem de kleinste wijziging aan z'n code oplevert, maar goed

Als je een string zonder tags maar nog met character references hebt, dan is er in waarschijnlijk daarvoor al iets mis gegaan bij het parsen... Dan ben je bijvoorbeeld met regular expressions aan de gang gegaan ofzo, en die zijn daar niet echt voor bedoelt (en ze werken bijna altijd niet bij allerlei mogelijke randgevallen). En voor je het weet ga je dan de standaardfunctionaliteit voor dit soort dingen alsnog gebruiken en moet je de tags er weer omheen zetten...

Zeker als programmeer-noob zou ik niemand aanraden om zelf een XML/HTML-lezer te gaan maken; je gaat ongetwijfeld tal van randgevallen vergeten.

[.oisyn]

Sorry, maar je overdrijft. Het doel van de TS is niet om HTML te parsen. Het doel van de TS is informatie vergaren. Het is overkill om informatie die op een statisch geformateerde pagina staat door een hele HTML parser heen te halen, als je die informatie ook gewoon met wat string searches eruit kunt trekken. KISS.

[ Voor 17% gewijzigd door .oisyn op 23-09-2009 19:36 ]

[dôh]

.oisyn schreef op woensdag 23 september 2009 @ 19:26:
Sorry, maar je overdrijft. Het doel van de TS is niet om HTML te parsen. Het doel van de TS is informatie vergaren. Het is overkill om informatie die op een statisch geformateerde pagina staat door een hele HTML parser heen te halen, als je die informatie ook gewoon met wat string searches eruit kunt trekken. KISS.

Bedankt voor alle reacties! Inderdaad wil ik alleen informatie. De parser is al geschreven, ik wil alleen dat de vreemde tekens goed worden weergegeven. That's all.

Even een code stukje;

code:

_director = parseData(data, "<h5>Director:</h5>", "</a>");
_title = parseData(data, "<div id=\"tn15title\">", " <span>");

Kan ik daar nou gewoon dit van maken?

code:

_director = parseData(data, "<h5>Director:</h5>", "</a>");
_title = parseData(data, "<div id=\"tn15title\">", " <span>");
_title = _title.replaceAll("&#x25;", "%");
_title = _title.replaceAll("&#x26;", "&");
_title = _title.replaceAll("&#x27;", "'");
_title = _title.replaceAll("&#x2b;", "+");
_title = _title.replaceAll("&#x3c;", "<");
_title = _title.replaceAll("&#x3e;", ">");

Ik wil eigenlijk alleen weten hoe ik de tekens vervang... Voor ééntje weet ik dus hoe, voor meerdere niet.

[_Erikje_]

volgens mij zijn er meerdere oplossingen gegeven. gebruik gewoon Sv3n's oplossing, dat is de beste oplossing IMHO..

[pedorus]

.oisyn schreef op woensdag 23 september 2009 @ 19:26:
Sorry, maar je overdrijft. Het doel van de TS is niet om HTML te parsen. Het doel van de TS is informatie vergaren. Het is overkill om informatie die op een statisch geformateerde pagina staat door een hele HTML parser heen te halen, als je die informatie ook gewoon met wat string searches eruit kunt trekken. KISS.

Na beroerde ervaringen met regular expressions en andere trucs, los ik dit soort dingen nu op door de pagina te parsen en XPath te gebruiken; dat programmeert namelijk het snelst, en werkt gelijk in alle gevallen... Je kan dat 'overkill' noemen (of beter 'far too fancy'), maar snelheid is vaak toch geen issue.

Trouwens, in dit specifieke geval: [google=imdb api].

dôh schreef op woensdag 23 september 2009 @ 21:06:
Kan ik daar nou gewoon dit van maken?

Waarom zou dat niet kunnen

Ik zou het enkel iets anders oplossen, zie dit voorbeeld:

Java:

import javax.swing.text.html.parser.ParserDelegator;
import javax.swing.text.html.HTMLEditorKit.ParserCallback;
import java.io.*;

public class HTMLDecodeTest {

    public static String htmlEntityDecode(String html) {
        final StringBuilder result = new StringBuilder();
        try {
            new ParserDelegator().parse(new StringReader(html.replace("<", "&lt;")),
                new ParserCallback() {
                    public void handleText(final char[] data, final int pos) {
                        result.append(data);
                    }
                }, true);
        } catch (IOException e) {
            throw new OutOfMemoryError("IOException on reading from memory?");
        }
        return result.toString();
    }

    public static void main(String argv[]) {
       String html = "te&amp;s&lt;t<test>qqqq<<&#x26;&#x26;a";
       System.out.println(htmlEntityDecode(html));  // te&s<t<test>qqqq<<&&a
    }
}

En wat is de .NET API toch zoveel beter dan die van Java (HtmlDecode)...

[RedRose]

Mjah, voor het doel van de TS sowieso overkill imho. En waarom gebruik je daar de Swing libs voor?

Die code doet bij sowieso wat alarmbellen rinkelen. Niet alleen KISS, maar ook the law of leaky abstractions en iets met code schrijven die dubbel zo hard te debuggen is.

[pedorus]

RedRose schreef op donderdag 24 september 2009 @ 11:27:
Mjah, voor het doel van de TS sowieso overkill imho. En waarom gebruik je daar de Swing libs voor?

Dat is de enigste standaard JDK-lib die snapt wat de mogelijke entities in html zijn; anders moet je een lijstje hebben zoals die Apache-lib heeft.

Die code doet bij sowieso wat alarmbellen rinkelen. Niet alleen KISS, maar ook the law of leaky abstractions en iets met code schrijven die dubbel zo hard te debuggen is.

Hij voldoet toch aan de law of leaky abstractions? Zonder documentatie zou je bijvoorbeeld kunnen denken dat ie whitespace intact laat..

En of een onvolledige lijst entities of een complete extra library nou zo handig is met debuggen...

[RedRose]

pedorus schreef op donderdag 24 september 2009 @ 12:42:
[...]

Dat is de enigste standaard JDK-lib die snapt wat de mogelijke entities in html zijn; anders moet je een lijstje hebben zoals die Apache-lib heeft.


[...]

Hij voldoet toch aan de law of leaky abstractions? Zonder documentatie zou je bijvoorbeeld kunnen denken dat ie whitespace intact laat..

En of een onvolledige lijst entities of een complete extra library nou zo handig is met debuggen...

In dat artikel staat ook: "learn how to do it manually first, then use the wizzy tool to save time." . Dus dat hij voldoet aan die wet, wil niet zeggen dat dat een goed iets is natuurlijk

In dat opzicht is het denk ik erg belangrijk om te snappen hoe dat precies werkt (dus string scannen, replacen, unicode, html entities etc), om dan inderdaad een bestaande lib te nemen.

Daarnaast vind ik persoonlijk (ieder zn voorkeur natuurlijk) de ParserDelegator onhandig zoals die hierboven staat. Een exceptionhandle om een Delegator die Callback en een StringReader neemt, die ook nog eens de < voor een &lt; vervangt, alvorens de parser in te gaan.

[pedorus]

RedRose schreef op donderdag 24 september 2009 @ 13:55:
Daarnaast vind ik persoonlijk (ieder zn voorkeur natuurlijk) de ParserDelegator onhandig zoals die hierboven staat. Een exceptionhandle om een Delegator die Callback en een StringReader neemt, die ook nog eens de < voor een &lt; vervangt, alvorens de parser in te gaan.

Volgens mij is het ook onhandig.. Java zorgt ervoor dat je een Exception, die niet eens daadwerkelijk plaats kan vinden, perse moet gaan afhandelen. Daarnaast zijn er gezien het aantal public methodes weinig andere mogelijkheden om bij het complete lijstje entities te komen. Het is dus gewoon een workaround voor het ontbreken van standaard-functionaliteit. Maar als iemand een beter methode weet...

[.oisyn]

pedorus schreef op donderdag 24 september 2009 @ 14:43:
Maar als iemand een beter methode weet...

Sv3n in "[JAVA] Meerdere keren replaceAll?"

[pedorus]

.oisyn schreef op donderdag 24 september 2009 @ 14:58:
[...]


Sv3n in "[JAVA] Meerdere keren replaceAll?"

Dan voeg je een extra niet-standaard dependency toe voor zoiets simpels... Java

[ACM]

pedorus schreef op donderdag 24 september 2009 @ 15:02:
Dan voeg je een extra niet-standaard dependency toe voor zoiets simpels... Java

Apache Commons is dan echter weer wel een hele gebruikelijke om als dependency mee te leveren. Sowieso zie ik niet zo goed waarom het een probleem moet zijn om op wat libraries van derden te leunen? Scheelt je weer een hoop van dat soort code zelf schrijven

[pedorus]

ACM schreef op donderdag 24 september 2009 @ 16:08:
[...]

Apache Commons is dan echter weer wel een hele gebruikelijke om als dependency mee te leveren. Sowieso zie ik niet zo goed waarom het een probleem moet zijn om op wat libraries van derden te leunen? Scheelt je weer een hoop van dat soort code zelf schrijven

Dat zal best, maar hij staat hier niet in mijn classpath. Het punt is dat in bijvoorbeeld .NET dit soort functies gewoon handig in het Framework zitten. Dat is gewoon vele malen handiger, omdat:

• Je niet hoeft te zorgen dat de library altijd beschikbaar is in je classpath (geen installatieproblemen).
• Je geen rekening hoeft te houden met de licentievoorwaarden van de library.
• Je niet hoeft te zorgen dat je de library up to date houdt.
• Je applicatie er niet bloated en traag van wordt (denk ook oa aan eventuele static blocks).
• Er geen jar-bestand over hoeft te worden gezonden als je er een applet van maakt.

Kortom, het even toevoegen van zo'n library voor zoiets simpels is wat mij betreft veels te veel werk; meer werk dan met een beetje een hack gewoon JDK-functionaliteit gebruiken die helaas beroerd is ontsloten.

[Standeman]

pedorus schreef op donderdag 24 september 2009 @ 16:34:
[...]

Dat zal best, maar hij staat hier niet in mijn classpath. Het punt is dat in bijvoorbeeld .NET dit soort functies gewoon handig in het Framework zitten. Dat is gewoon vele malen handiger, omdat:

• Je niet hoeft te zorgen dat de library altijd beschikbaar is in je classpath (geen installatieproblemen).
• Je geen rekening hoeft te houden met de licentievoorwaarden van de library.
• Je niet hoeft te zorgen dat je de library up to date houdt.
• Je applicatie er niet bloated en traag van wordt (denk ook oa aan eventuele static blocks).
• Er geen jar-bestand over hoeft te worden gezonden als je er een applet van maakt.

Kortom, het even toevoegen van zo'n library voor zoiets simpels is wat mij betreft veels te veel werk; meer werk dan met een beetje een hack gewoon JDK-functionaliteit gebruiken die helaas beroerd is ontsloten.

Wat heeft het meeleveren van libraries te maken met het feit of het al dan niet in je classpath staat? Dat soort dingen staan gewoon in je manifest.
Verder heb je meestal weinig problemen met de license van een library. De meeste gangbare libraries vallen onder de Apache, GPL of Berkley license en mag je gewoon vrij gebruiken.
En verder update ik mijn libraries zeer zelden.

[ Voor 11% gewijzigd door Standeman op 24-09-2009 16:40 ]

[.oisyn]

pedorus schreef op donderdag 24 september 2009 @ 16:34:

What's your frickin' point? Dat we allemaal maar gewoon .Net moeten gebruiken? Erg constructief is 't niet

[ Voor 7% gewijzigd door .oisyn op 24-09-2009 16:49 ]

[RedRose]

pedorus schreef op donderdag 24 september 2009 @ 16:34:
[...]

Dat zal best, maar hij staat hier niet in mijn classpath. Het punt is dat in bijvoorbeeld .NET dit soort functies gewoon handig in het Framework zitten. Dat is gewoon vele malen handiger, omdat:

• Je niet hoeft te zorgen dat de library altijd beschikbaar is in je classpath (geen installatieproblemen).
• Je geen rekening hoeft te houden met de licentievoorwaarden van de library.
• Je niet hoeft te zorgen dat je de library up to date houdt.
• Je applicatie er niet bloated en traag van wordt (denk ook oa aan eventuele static blocks).
• Er geen jar-bestand over hoeft te worden gezonden als je er een applet van maakt.

Kortom, het even toevoegen van zo'n library voor zoiets simpels is wat mij betreft veels te veel werk; meer werk dan met een beetje een hack gewoon JDK-functionaliteit gebruiken die helaas beroerd is ontsloten.

Het voordeel van java is dan wel weer dat je meer libs kan kiezen die je aanstaan. Bijvoorbeeld Apache Commons vs javax.swing, of JDOM vs javax.xml, die je vrij makkelijk en redelijk leightweight kan meeleveren / in je classpath zetten. Het nadeel van .Net vind ik nog steeds de manier waarop ze met html omgaan (Masterpages, Controls, Code behinds etc)

Maar goed, ik wil er ook geen java vs .Net discussie van maken.

[pedorus]

Standeman schreef op donderdag 24 september 2009 @ 16:36:
[...]

Wat heeft het meeleveren van libraries te maken met het feit of het al dan niet in je classpath staat?

Dat ging over deze specifieke library. Als Apache echt zeer common zou zijn, dan had hij wel in mijn classpath gestaan

.oisyn schreef op donderdag 24 september 2009 @ 16:47:
[...]

What's your frickin' point? Dat we allemaal maar gewoon .Net moeten gebruiken? Erg constructief is 't niet

Het stukje "bijvoorbeeld .NET", wat net zo goed PHP had kunnen zijn in dit verband, werkt blijkbaar als een rode lap Het ging over het toevoegen van een dependency. Volgens mij liggen er nu zo'n 4 oplossingen voor voor het originele probleem:

1. Meerdere keren replaceAll
2. Zoeken naar &, en afhandelen
3. javax.swing.text.html gebruiken
4. org.apache.commons.lang.StringEscapeUtils gebruiken

En ik gaf aan waarom ik niet snel voor de laatste zou kiezen.

[Standeman]

pedorus schreef op donderdag 24 september 2009 @ 17:06:
[...]

Dat ging over deze specifieke library. Als Apache echt zeer common zou zijn, dan had hij wel in mijn classpath gestaan

Ik zie nog steeds niet 3rd party libraries in je classpath zouden moeten staan? Hoe common ze ook zouden zijn.

[Confusion]

pedorus schreef op donderdag 24 september 2009 @ 17:06:
[...]
Dat ging over deze specifieke library. Als Apache echt zeer common zou zijn, dan had hij wel in mijn classpath gestaan

Yup, want jij bent de maatstaf van alles .

Als Sun ze geschreven had en ze bij de JDK meegeleverd werden, dan was het blijkbaar wel goed?

Bij ons is er geen project waar Apache Commons Lang, Apache Commons Configuration, Apache Commons DBCP, etc., etc. niet gebruikt worden. Spring, Hibernate, FreeMarker, JUnit, DbUnit, oh noes, nog meer 'niet standaard dependencies'...

[Standeman]

Confusion schreef op donderdag 24 september 2009 @ 20:40:
[...]

Yup, want jij bent de maatstaf van alles .

Als Sun ze geschreven had en ze bij de JDK meegeleverd werden, dan was het blijkbaar wel goed?

Bij ons is er geen project waar Apache Commons Lang, Apache Commons Configuration, Apache Commons DBCP, etc., etc. niet gebruikt worden. Spring, Hibernate, FreeMarker, JUnit, DbUnit, oh noes, nog meer 'niet standaard dependencies'...

Inderdaad, echt wel rot dat er mensen zijn die denken dat het beter kan en het ook nog implementeren!!

[pedorus]

Confusion schreef op donderdag 24 september 2009 @ 20:40:
[...]

Yup, want jij bent de maatstaf van alles .

Let ook op de smiley

Als Sun ze geschreven had en ze bij de JDK meegeleverd werden, dan was het blijkbaar wel goed?

Tuurlijk, dan hoefde je namelijk niks extras te installeren. Of Sun ze geschreven heeft boeit niet, het gaat erom dat je geen moeite hoef te doen om te zorgen dat ze beschikbaar zijn.

Als het dan om een enkele, vrij simpele functie gaat zou ik niet aanraden om gelijk een niet-standaard library erbij te gaan gebruiken.

[Remus]

RedRose schreef op donderdag 24 september 2009 @ 11:27:
Mjah, voor het doel van de TS sowieso overkill imho. En waarom gebruik je daar de Swing libs voor?

Dat is eigenlijk een historisch misbaksel. Die library met de callback parser was eerst slechts een interne API om HTML (en een aantal andere documenten) te parsen in Swing (bijvoorbeeld voor een sourcecode editor met syntax highlighting, of voor een HTML parser).

Sun heeft vervolgens op veler verzoek die API openbaar gemaakt, maar hem niet uit de javax.swing tree verplaatst (naar bijvoorbeeld java.text) om compatibility issues te voorkomen. Je kan overigens veel zeggen over die callback parser, maar hij werkt prima; al is hij niet optimaal als het enige dat je wilt een HTML naar plain text parser is.

pedorus schreef op donderdag 24 september 2009 @ 14:43:
Volgens mij is het ook onhandig.. Java zorgt ervoor dat je een Exception, die niet eens daadwerkelijk plaats kan vinden, perse moet gaan afhandelen. Daarnaast zijn er gezien het aantal public methodes weinig andere mogelijkheden om bij het complete lijstje entities te komen. Het is dus gewoon een workaround voor het ontbreken van standaard-functionaliteit. Maar als iemand een beter methode weet...

De betreffende Exception in de callback parser kan wel degelijk optreden, dus is het terecht checked exception die je moet afhandelen. Anders hadden ze best voor een unchecked exception (subclass van RuntimeException) kunnen kiezen; dat is deels een design overweging en geen gebrek in Java oid.

[pedorus]

Remus schreef op donderdag 24 september 2009 @ 21:41:
De betreffende Exception in de callback parser kan wel degelijk optreden, dus is het terecht checked exception die je moet afhandelen. Anders hadden ze best voor een unchecked exception (subclass van RuntimeException) kunnen kiezen; dat is deels een design overweging en geen gebrek in Java oid.

In welke situatie precies? Als je eerst de StringReader expres sluit en hem dan meegeeft, of hem zelf gaat gooien, ja, dan kan het. Maar bij het design zijn ze denk ik uitgegaan van een niet-memory stream.

Overigens, mijn manier van opvangen is al iets beter dan die in ParserDelegator zelf:

Java:

        } catch (IOException e) {
        // (PENDING) UGLY!
        System.out.println("Throw an exception: could not get default dtd: " + nm);
        }

[Confusion]

pedorus schreef op donderdag 24 september 2009 @ 21:38:
Tuurlijk, dan hoefde je namelijk niks extras te installeren.

Je hoeft nu ook niks te 'installeren'. Ik 'installeer' in ieder geval geen jars.

het gaat erom dat je geen moeite hoef te doen om te zorgen dat ze beschikbaar zijn.

Ik hoef nooit moeite te doen om te zorgen dat de jars die aanwezig moeten zijn bij de applicatie meegeleverd worden. Niet meer moeite dan jij moet doen om te zorgen dat alle dll's meegeleverd worden aan iemand die het .Net framework niet geinstalleerd heeft staan. Niet meer moeite dan een C++ developer moet doen om alles bij elkaar geraapt te krijgen.

[.oisyn]

pedorus schreef op donderdag 24 september 2009 @ 21:38:
Als het dan om een enkele, vrij simpele functie gaat zou ik niet aanraden om gelijk een niet-standaard library erbij te gaan gebruiken.

Feitelijk komt het erop neer dat je de TS, die één plank wilt zagen, voorstelt om bij gebrek aan een handzaag in huis naar de houtzagerij te gaan, ipv een zaag bij de buurman te lenen. Daar hadden ze een woord voor, god wat was dat ook alweer... oh ja, "overkill"

[ Voor 8% gewijzigd door .oisyn op 24-09-2009 22:41 ]

[pedorus]

.oisyn schreef op donderdag 24 september 2009 @ 22:34:
[...]


Feitelijk komt het erop neer dat je de TS, die een plank wilt zagen, voorstelt om bij gebrek aan een handzaag in huis naar de houtzagerij te gaan, ipv een zaag bij de buurman te lenen. Daar hadden ze een woord voor, god wat was dat ook alweer... oh ja, "overkill"

De TS heeft zeg maar een los zaagblad, en ik draag hem een constructie aan om deze toch te kunnen gebruiken. Anderen zeggen dat je ook even het werkbusje van iemand anders kan lenen, waarin toevallig ook een zaag zit. Gaat nergens over die vergelijkingen, en ik laat het dan ook graag aan TS over om te beslissen of hij zo'n 20 regels sourcecode opneemt, of dat hij een library van 1.9 mb gaat downloaden.

[Confusion]

pedorus schreef op donderdag 24 september 2009 @ 22:47:
[...]
ik laat het dan ook graag aan TS over om te beslissen of hij zo'n 20 regels sourcecode opneemt, of dat hij een library van 1.9 mb gaat downloaden.

Die keuze is makkelijk gemaakt: de library. Daarin zit al grondig geteste code en het houdt mijn code overzichtelijk en beter te begrijpen. Liever 1 library call dan 20 regels waar waarschijnlijk 3 bugs in zitten. Overigens is de .jar in kwestie ~256kB en zitten er gegarandeerd nog meer methoden in waarvan je denkt 'goh, wat handig, dat scheelt mij weer het wiel 15 keer met fouten uitvinden'.

[ Voor 5% gewijzigd door Confusion op 24-09-2009 23:08 ]

[pedorus]

Ik heb het even gedownload; 1.9 mb zit inderdaad ook source en documentatie bij (gezipt). Maar het gaat vast een stuk sneller dan met al die goed gereviewde code. Voorbeeldje (uit org.apache.commons.lang/Entities.java):

Java:

    static {
        HTML32 = new Entities();
        HTML32.addEntities(BASIC_ARRAY);
        HTML32.addEntities(ISO8859_1_ARRAY);
    }

Kost opstarttijd, kan mogelijk zelfs crashende bugs hebben, maar die array wordt nergens meer gebruikt..

Bij de bugs is het maar net de vraag welke aanpak een vervelende bug op zal leveren. En gezien de TS gaan die andere methoden in dezelfde library het ook niet echt meer worden ("ben het meeste kwijt. Eerlijkgezegd wil ik het ook zo houden"). En misschien ging het wel over een Java-applet, of moet whitespace ook gefilterd worden, of etc. Zo blijkt maar weer dat je die beslissing niet voor iemand anders moet gaan nemen.

[user109731]

pedorus schreef op vrijdag 25 september 2009 @ 00:05:
Kost opstarttijd, kan mogelijk zelfs crashende bugs hebben, maar die array wordt nergens meer gebruikt..

static blocks worden niet massaal bij het opstarten uitgevoerd, iirc pas als je de class voor het eerst gebruikt. Dan valt het 'probleem' van bloated en traag toch wel mee?

Ik grijp trouwens in C++ ook vrijwel standaard naar Boost en (soms) Qt. Elke taal heeft denk ik zo z'n top-libraries die in kwaliteit niet onderdoen voor de standaard API's

edit: het grappige is dat Mono's HttpUtility bijna hetzelfde doet: InitEntities initialiseert ook een static array...

[ Voor 19% gewijzigd door user109731 op 25-09-2009 01:27 ]

[pedorus]

JanDM schreef op vrijdag 25 september 2009 @ 01:21:
[...]

static blocks worden niet massaal bij het opstarten uitgevoerd, iirc pas als je de class voor het eerst gebruikt. Dan valt het 'probleem' van bloated en traag toch wel mee?

Klopt, het is zeker niet zo dat ze opeens allemaal worden uitgevoerd bij de start van je programma (behalve als ze elkaar triggerden door steeds naar andere classes te verwijzen), dit gebeurd pas bij het eerste relevante gebruik (dus bijvoorbeeld nog niet bij declaren als null). Het is denk ik ook meer een principezaak, zag zo snel niet wat anders om over te klagen.* Ik weet dat bijvoorbeeld de standaard-jdk de entities pas laadt als ze daadwerkelijk nuttig worden, dat lijkt me de correcte methode.

edit: het grappige is dat Mono's HttpUtility bijna hetzelfde doet: InitEntities initialiseert ook een static array...

Die wordt pas aangeroepen bij het eerste gebruik, precies zoals het hoort. Er worden dus niet gelijk maar eens meerdere tabellen gevuld die misschien later gebruikt gaan worden.

*=Afgezien van de vele methoden om Entities op te slaan, die ook niet lijken te worden gebruikt. Onnodig veel code.

[bigbeng]

pedorus schreef op vrijdag 25 september 2009 @ 01:44:
[...]
*=Afgezien van de vele methoden om Entities op te slaan, die ook niet lijken te worden gebruikt. Onnodig veel code.

Wat een onzin zeg, wat maakt het nou uit dat bij het gebruik van een standaard library dat de internals niet precies aansluiten bij wat jij wil? Pas op het moment dat je tegen performance issues aanloopt kun je eens gaan kijken of je zelf code kan gaan schrijven die performanter is (of een andere 3rd party library gaat opzoeken). Om de zaagmetafoor maar te herbruiken, als je een plank moet zagen, dan maakt het toch niet uit dat de zaag niet precies aansluit bij jouw meest comfortabele armbeweging? Als de zaag maar bruikbaar is. Iets te zwaar of iets te groot/klein zaagblad maakt dan weinig uit.

Het voordeel van het gebruik van een algemeen geaccepteerde library is dat hij i.h.a. goed getest is door vele gebruikers.

Mocht je een betere lib hebben voor de TS, dan is het een ander verhaal, maar het lijkt erop dat je vooral aan het schieten bent tegen het gebruik van een 3rd party lib als je niet voldoende gebruik maakt van de features van de lib.

edit:
Hmm, misschien had ik beter niet de zaagmetafoor herbruikt, maar goed, zo lang als we het er maar over eens zijn dat commons in dit geval de zaag is.

[ Voor 6% gewijzigd door bigbeng op 25-09-2009 06:20 ]

[ACM]

Afhankelijk van de licentie kan je natuurlijk ook nog een - voor Open-Sourcepuristen wat moeilijker te accepteren - optie kiezen om enkel de benodigde utility-class te kopieren naar je eigen tree.
Zolang je bugfixes maar teruggeeft aan de originele ontwikkelaars zullen ze daar zelf niet zo snel moeite mee hebben (of ze hadden wel een licentie gekozen die aangeeft dat ze dat wel hebben).

Anderzijds is de kans natuurlijk groot dat als je eenmaal een bepaalde library gebruikt, dat je dan in een later stadium ook andere functies er van gaat gebruiken. Dan is het weer handiger om hem gewoon in zijn geheel er al in te zetten.

[Confusion]

pedorus schreef op vrijdag 25 september 2009 @ 00:05:
Ik heb het even gedownload; 1.9 mb zit inderdaad ook source en documentatie bij (gezipt). Maar het gaat vast een stuk sneller dan met al die goed gereviewde code.

Yup, het gaat vast wel 15 ms sneller.

Premature optimization enzo...

ACM schreef op vrijdag 25 september 2009 @ 08:05:
Afhankelijk van de licentie kan je natuurlijk ook nog een - voor Open-Sourcepuristen wat moeilijker te accepteren - optie kiezen om enkel de benodigde utility-class te kopieren naar je eigen tree.

De Apache libs worden allemaal onder de Apache License uitgegeven, wat neerkomt op een BSD license, oftewel: doe er mee wat je wilt. Commercieel exploiteren, code kopieren, alles mag.

Voor een library onder de GPL geldt overigens ook dat er geen enkele verplichting is om de oorspronkelijk vorm te behouden: enkel dat de code ook in de nieuwe vorm onder de GPL verspreidt wordt.

[ Voor 51% gewijzigd door Confusion op 25-09-2009 09:54 ]

[pedorus]

Confusion schreef op vrijdag 25 september 2009 @ 09:43:
De Apache libs worden allemaal onder de Apache License uitgegeven, wat neerkomt op een BSD license, oftewel: doe er mee wat je wilt. Commercieel exploiteren, code kopieren, alles mag.

Mits je de relevante stukken onder de Apache-licentie houdt en die mee levert natuurlijk. Tegen de tijd dat je de relevante code hebt gevonden en afgesplitst en dat netjes hebt geregeld ben je zo al weer een uur verder, waarin je je hobbyprojectje al up-and-running hebt als je gewoon wat regels code opneemt. En dat moet misschien later overnieuw als je de boel up to date wilt houden (zeg bij html 6)..

Misschien ligt het aan mij, maar ik neem op een hobbyprojectje van zeg 100 kb niet even 256 kb-1.9 mb aan extra libraries op als het met een paar regels code ook is opgelost. Dat is gewoon mijn eer te na, zeg maar... Een hobbyprojectje is wat anders dan een cover-my-ass-enterprise-oplossing. Misschien is dat ook net de reden dat een viewer als Irfanview zo lekker klein is, in tegenstelling tot alternatieven van commerciële ontwikkelaars. Daar krijg je niet zomaar extra libraries erbij als het niet echt nodig is..

[Confusion]

pedorus schreef op vrijdag 25 september 2009 @ 14:57:
Mits je de relevante stukken onder de Apache-licentie houdt en die mee levert natuurlijk.

Nee, helemaal niet. Lees de Wikipedia entry over de Apache License voor de grap eens.

Misschien ligt het aan mij, maar ik neem op een hobbyprojectje van zeg 100 kb niet even 256 kb-1.9 mb aan extra libraries op als het met een paar regels code ook is opgelost.

Het goed escapen van data is niet 'met een paar regels' opgelost. Methodes als StringEscapeUtils.escapeXml() zijn hun gewicht in goud waard.

Een hobbyprojectje is wat anders dan een cover-my-ass-enterprise-oplossing.

Ik wil in mijn hobbyprojectjes ook niet onnodig xml escape functies zitten perfectioneren en debuggen. Ik wil leuke dingen doen met mijn tijd en sleep daarvoor iedere library naar binnen die een basaal probleem voor me oplost, tenzij het herschrijven van die library mijn doel is. Dit soort puristisch geneuzel is totaal niet pragmatisch en zorgt ervoor dat je maar blijft hangen in het herimplementeren van allerlei totaal oninteressante oplossingen voor suffe problemen. Wie heeft het ook alweer als .sig : "Good programmers write solid code, while great programmers reuse the code of good programmers"?

Waar je die 'enterprise-oplossingen' vandaan sleept weet ik niet.

[ Voor 15% gewijzigd door Confusion op 25-09-2009 15:44 ]

[pedorus]

Confusion schreef op vrijdag 25 september 2009 @ 15:25:
Nee, helemaal niet. Lees de Wikipedia entry over de Apache License voor de grap eens.

Hoezo niet? De relevante code, dus de regels code die je hebt gekopieerd, blijven natuurlijk gewoon onder die license. Het gaat niet ineens naar public domain ofzo als je ze kopieert naar een eigen project. Dat is altijd zo. Omdat je die regels opneemt, zul je dus bijvoorbeeld moeten zorgen dat je kopietjes van de de licentie geeft.

Het goed escapen van data is niet 'met een paar regels' opgelost.

Ik heb dan ook een bestaande routine in de standaard-api hergebruikt die het echte werk opknapt.

Methodes als StringEscapeUtils.escapeXml() zijn hun gewicht in goud waard.

offtopic:
Dat komt neer op exact 0 euro

Klinkt alsof je op een erg laag niveau met XML bezig bent, dan. Overigens is die functie niet echt aan te raden bij buitenlandse (bijv. Chinese) tekst.

[Confusion]

pedorus schreef op vrijdag 25 september 2009 @ 16:41:
Hoezo niet? De relevante code, dus de regels code die je hebt gekopieerd, blijven natuurlijk gewoon onder die license.

The Apache License does not require modified versions of the software to be distributed using the same license nor even that it be distributed as free/open-source software.

Ik heb dan ook een bestaande routine in de standaard-api hergebruikt die het echte werk opknapt.

Apache Commons Lang is de standaard API voor dit soort dingen. De standaard libraries van Java omvatten veel minder dan het hele .Net framework, precies omdat er zoveel goede open source libraries zijn die allerlei functionaliteit allang implementeren. Sun heeft zich die moeite bespaard.

Wikipedia:

Some developers have expressed concerns about the large size and reliability of .NET framework runtime installers for end-users. The size is around 54 MB for .NET 3.0, 197 MB for .NET 3.5, and 250 MB for .NET 3.5 SP1

De JRE is ~20 MB.

Klinkt alsof je op een erg laag niveau met XML bezig bent, dan. Overigens is die functie niet echt aan te raden bij buitenlandse (bijv. Chinese) tekst.

Waarom niet? Ik zie geen enkel probleem. Ook Chinese karakters worden gewoon ge-escaped.

[pedorus]

Confusion schreef op vrijdag 25 september 2009 @ 17:06:
"The Apache License does not require modified versions of the software to be distributed using the same license nor even that it be distributed as free/open-source software."

offtopic:
Ik heb het over de ongemodificeerde delen, niet over de modificaties zelf of de toevoegingen of het resultaat van alle drie samen..

Waarom niet? Ik zie geen enkel probleem. Ook Chinese karakters worden gewoon ge-escaped.

offtopic:
... wat de grootte onnodig veel laat toenemen...