StringJoiner: detect or fix delimiter collision?
philip.hodges at bluewin.ch
Tue Jul 23 21:57:57 UTC 2013
Nothing against a "simple" joiner that forces users to catch or rule out a
DelimiterCollisionException, and realise that simple is not good enough.
Everything against a stupid joiner that silently assists users in creating
"Seems to work" means not tested thoroughly. People will be tempted into
using this joiner to write csv files, and of course it will break as soon as
a comma or semicolon delimiter turns up in a text field. They will use it to
put br line break elements into HTML files, without checking for HTML syntax
characters in each line. They will use it to separate SQL column values with
commas, instead of binding them, or calling mysql_real_escape_string, which
is a pain to use because it needs a database connection at runtime to find
out exactly which characters need escaping depending on which SQL mode is
By all means use a "proper structured format", so long as the delimiting is
properly specified and the parser and generator are fully tested. That might
well be the case for JSON and XML, but it typically is not for CSV and HTML
or properties files.
Just because other languages may happen to have something similar does not
automatically make it easy to use safely.
The current behaviour encourages SQL injection. How hard is that to
understand? There are some very good features coming in this release, but
this joiner is not one of them; it is actually dangerous.
View this message in context: http://openjdk.5641.n7.nabble.com/RFR-String-join-StringJoiner-additions-tp127375p145058.html
Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com.
More information about the core-libs-dev